More Than Coding

Because machines still need humans

The must-ask question for your software engineering interview

If you’re interviewing for a software engineering position, there are plenty of articles and books out there to help you get ready to answer questions from your prospective employer. There are far fewer resources to help you learn which questions you should ask if you’re the one being interviewed. Having interviewed hundreds of software engineering candidates over the years, I can tell you that the questions a candidate asks are often extremely revealing. And, because they’re usually among the final questions in the interview, they often leave behind an important impression in the interviewer’s mind.

If you’re like most software engineering candidates, you are probably prepared to ask at least some questions of your potential employer during an interview. Standard questions usually probe into things like technology stack choices, benefits, or the amount of autonomy afforded if you get hired. While those are all important questions to ask, they don’t reveal the level of sophistication of the engineering organization you’re about to join. That’s harder to determine, especially if you’re only given a couple of minutes at the end of the interview to ask a couple of questions, having been grilled for hours already.

Given that you’ll likely also only work at a small number of jobs in your career, you want to choose teams that truly help you to grow, and to do that, you need to surround yourself with high-quality engineering talent. During any interview process, I suggest that you use this valuable opportunity to get a deeper sense of the quality of the team you’re looking to join.

If you want to quickly vet the quality of the team that’s interviewing you, one question can get to the heart of the matter with immediate effect:

“Why did you choose your current software development methodology?”

The interviewer’s answer to this deceptively simple question will reveal a lot about the engineering team, but also about the company’s organizational health.

The answer to this question tells you if the engineering group is aligned with the business needs of the company by building software in a way that matches those needs. It also tells you if the engineering managers are sophisticated enough to truly understand how software should be built at their company, or if they’re just run-of-the-mill folk who just apply the latest and greatest buzzword technique to make the team look modern.

Here are some not-so-great answers, along with what they’re revealing:

  • “We use waterfall because, well, that’s what we’ve used for years.”

The phrase “that’s just how we do things here” will probably be heard regularly at a company like this. There might be nobody willing to challenge the orthodoxy or rock the boat because people there are comfortable, and change is generally resisted. In large companies, more modern development methods might be difficult to implement, or are perhaps isolated to only certain teams. In smaller companies, it’s often a sign of a lifestyle business culture, which generally won’t lead to massive growth in either top-line revenue or development careers.

  • “We are a Scrum shop because the CTO used it in his previous company, and he’s super passionate about it. He’s even a certified Scrum Master.”

This answer tells us that Scrum might be getting applied religiously rather than rationally. Just because Scrum worked for the CTO when he was at a different company doesn’t mean it’s the most appropriate methodology in his current one. A candidate hearing this kind of answer should dig deeper into their decision criteria for using Scrum now, and find out if it’s being regularly evaluated as still being appropriate. Also, given the passion of the CTO for Scrum, he might be unwilling to consider other approaches that might be more suitable. In general, answers that lead back to a single person’s decision can also be indicative of a hierarchical and rigid culture.

Some encouraging answers might be:

  • “We use Kanban because we’re an early-stage startup and we have limited financial runway. We need to find product/market fit as quickly as possible, so we need to maximize the flow of features, prevent blockers, and build a strong feedback loop around things that we ship. We’re planning to re-evaluate our choice once we get real paying customers.”

This answer shows how the business goal – reaching product/market fit before running out of money – matches the methodology chosen, and hints at a good amount of introspection on the part of the management team. Those are all very good signs. Also, the fact that they plan to re-evaluate is another good sign that they are open to feedback, and most importantly, to change.

  • “We use something of our own invention that is probably closest to Scrumban. We run pretty disciplined sprints, and we love the data we get from doing them. But, we are always looking for improvements in everything we do. In fact, our process looks very different now compared to last year, and that’s mostly because of some great suggestions that the engineers made to how we do things.”

This company sounds healthy in numerous ways: they are introspective, they use data to inform their decisions, they have a culture of continuous improvement, and opinions from the team members are both encouraged and implemented. They’re also showing humility, another important thing to look for – beware of companies that arrogantly think their development process has no room for improvement.

In summary, a great answer to the question will:

  • Show that the team builds software in the most appropriate way to meet the company’s needs
  • Make the interviewer open up enthusiastically as they proudly describe more about how they have chosen to work
  • Be an identical answer to what each of the interviewers give (beware of teams with managers who say everything is rosy when their engineers say it’s anything but!)
  • Reveal how open the managers are to engineer-driven ideas
  • Show how introspective the company is, and whether they have a culture of continuous improvement
  • Get the candidate the most value out of their very limited “ask the interviewer something” time, allowing them to better evaluate the job opportunity

Remember, asking a really good question or two of an interviewer can help your chances of actually getting the job. A good interviewer will be thinking not just about your ability to write code, but about your ability to contribute to team culture and growth. But most importantly, the answer to this question will give you a strong sense of how much you really want the job. In an environment where engineering talent is at a premium and candidates are often vetting many opportunities at a time, companies that truly know how to build great teams will seek to “sell you” just as much as you want to “sell them.” Even if you don’t use this specific question, use this valuable opportunity to ask questions about topics that will shed real light on what your career would look like with the company — not on questions that can easily be answered with a one-line email later on.  


How to write software that is ready for the world

The conventional wisdom in software development has always been that internationalization (i18n) is a very expensive and time-consuming effort, and that it’s always better to target just one language first, adding support for more languages later, when the market demands it. Because of that perception, multilingual support is not often considered during the early days of new software projects, and many products end up being constructed in such a way that makes localizing them more difficult than it should be.

In fact, writing software that can easily be localized at a later stage isn’t terribly hard, as long as you start with the end in mind. Use the following techniques to greatly minimize the amount of work required when you eventually take your software product global.

Maintain user-visible strings separately

By far the most important (and most often ignored) guideline in i18n preparation is to ensure that all user-visible strings are separated from the code that uses them.

The typical approach used to achieve this separation is to store the product’s textual content in resource files for that platform or language. For example, Java programmers should maintain their displayable strings inside ResourceBundles.

Text in applications should never be structurally tied to the application’s logic. User-visible strings should always be modifiable without breaking application flow or other functionality.

Interestingly, this task is becoming less and less important for web applications, thanks to innovations in technology that can automatically extract text content from web-delivered software, send those strings to humans for translation, and even deliver the finished localized content online – all without requiring a single change be made to the original source application. This approach can significantly reduce the effort and time required to take a web application global.

Expect user-visible strings to grow or shrink

English phrases may double in size when translated to other languages, and with other target languages they may also shrink by a sizable amount. It is crucial that product code and graphical interface components must not depend on the length of user-visible strings remaining the same.

This obviously presents a challenge when presenting graphical representations of text to the user, but there are plenty of ways to do that correctly.

Keep images free of embedded text

For everything except company or product logos, images that contain text rendered directly within them should be avoided, because it is more difficult to have that text content translated. Instead of having someone quickly translate the contents of a text file, graphic designers would have to be hired to convert the images and put the translated text on them too, one language at a time.

Plan for different calendar, time, phone and currency systems

Developers writing code should always remember that other countries:

Build a checklist into your existing review process that watches for these kinds of issues in code to prevent any “hard wiring” that will limit your software’s eventual global usage.

Always use established, globally-focused standards when storing data. For example, use E.164 for phone numbers, ISO-8601 for timestamps, ISO 639.2 for languages, ISO 3166 for countries and the Olson database for time zones.

Avoid ASCII, use Unicode

In the past, engineers building software for English-only markets felt safe to do tricks in their code that only worked when the encoding in use was always ASCII. For example, the flip of a single bit of an ASCII-encoded alphabetical character switches it between lowercase and uppercase. However, the world’s needs have long since moved beyond what ASCII provides and has now embraced Unicode as the correct way to encode text data and support international characters.

Even though Unicode is somewhat compatible with ASCII, the best way to avoid string encoding issues is to:

  • never assume that characters are encoded in ASCII
  • never assume that that one byte equals one character
  • always use Unicode-capable types and libraries

Thankfully, some of the most popular programming languages like Java, C# and Objective-C have native Unicode support in their string types. Using them can make dealing with international characters a trivial effort.

Even if an application supports Unicode throughout, it will likely store data in a database, and a bad database schema can easily ruin all of the good work done in the code to make it compatible with international character sets. For example, in a SQL Server database, user-visible strings should be stored within nvarchar types, and in MySQL it would be best to use utf8mb4.

For more information on Unicode, this introductory article from Joel “On Software” Spolsky is a good introduction.

Don’t assume that text always flows from left to right

The most common difference in text layout that may be encountered is a right-to-left flow, such as that used in Arabic and Hebrew.


In a web application, simply changing the CSS direction property across your entire system would weed out most major layout issues that would be encountered with a future translation into a right-to-left language.

It is also possible to have text flow from top-to-bottom as well, although that’s far less common.

Keep all user-visible language plain and simple

When application messages get localized for other markets, the job of the translators will be much easier if the language used is plain and simple.

Language that is highly technical and reads like technical jargon will not translate well. Prefer common phrases and terms to niche or less frequently used ones.

Test for basic multilingual support

Good developers instinctively write automated tests for product features that they build. The addition of a few more tests to a product verification suite that verify that the product supports international characters would be a hugely valuable task, and not much effort to create.

For example, imagine a web application that allows people to book concert tickets. Let’s assume that a test already exists that verifies that a fake user called “John Doe” can book a seat at a show and verify that his name shows up correctly on the ticket that he receives after paying. Adding a similar test that changes the user’s name to “John- Doe-批” and verifies that those same characters show up on the ticket received after paying would verify that the application supports international characters all the way through the application and the database. This simple technique (sometimes termed “pseudo-internationalization“) allows developers to verify that their applications support the transmission and storage of international strings but without having to do a full professional translation of the product, or without the developers having to be fluent in a foreign language.

Automated tests can go even further. Tests can be built to verify that right-to-left fields operate correctly, or that international plurals are supported without having to rework the basis of the product’s code.

Embrace the global opportunity

Developing software in such a way that it can be ready for a global release is not as difficult as it may seem, or as it once might have been. By following these simple guidelines and doing a little bit of work up front, you can create software products that can later be made available to a much larger market than you might first address, making your product, and its usefulness, have far greater reach as a result.

What Your Resume Says About Your Programming Skills

If you’re looking to get a new programming job, there is a very important fact to know about hiring managers. Since they are very busy and receive lots of resumes for open positions, they will build a mental profile of a candidate’s skills by scanning their resume in just a few seconds. Much like when you meet someone in person, first impressions count.

Hiring managers hone their speedy scanning skills through years of experience on the job. Knowing how they interpret your resume’s content is often the difference between moving to that crucial phone screen stage and being ignored. Here are a few hints about what messages your resume is sending to potential new employers about your programming skills.


If you haven’t bothered to run an automated spellchecker over your resume, you won’t be expected to take care when writing code on a daily basis. Typos on a resume are typically viewed as a sign of laziness and disinterest, and can easily lead to them being dropped right into the employer’s trashcan.

Experienced technical hiring managers will quickly evaluate the precision with which a programmer uses language in their resume, and they will extend that impression to the candidate’s programming skills. When the hiring manager sees your typos, they have unpleasant visions of the many bugs you would create in their applications.

Excessive Length

Engineering candidates frequently send resumes that are more than 10 pages long, describing in complete and exhaustive detail every single project the candidate ever worked on. There will be a careful mention of the exact compiler version used on a 3-month contract for IBM back in 1994, along with cryptic company-specific project names like “EDT/BTS” that would only make sense to a handful of people on the planet.

The immediate thought that jumps to mind for the hiring manager upon receiving such tomes? That the candidate probably never revisits existing code to refactor it. The idea of editing a complex routine to break it up into simpler constituent parts for better maintainability and readability is apparently not something that they naturally want to do. After all, they’ve been adding to their resume’s content for years without revisiting it, so why would anyone expect them to do the same with their code? Also, excessive length can also imply that the candidate has a problem prioritizing. In today’s world, where engineers frequently have to juggle numerous projects, prioritization skills are necessary.

Acronym Overload

Technical acronyms are understandably commonplace in software engineering. However, when a quick visual scan of a resume makes a manager feel like they are swimming in alphabet soup, they often build an image of the candidate as being someone who only knows tools and frameworks and has little ability to design software at an architectural level. On the other hand, if the position being filled needs someone who can quickly create “mash-up” prototypes using a diverse set of existing frameworks and tools, having an acronym-heavy resume might be exactly what the employer is looking for.

Lack of Creativity

If an employer were looking for an engineer to build a sexy new web UI, a boring, unimaginative resume created using a Microsoft Word template would be the last thing they’d want to see. Using a dull, expected resume format usually indicates a lack of visual creativity and curiosity, and the employer will often question the candidate’s ability to build aesthetically pleasing web interfaces.

Granted, plenty of engineers whose expertise is in building services that don’t contain graphical interfaces (such as server-side libraries or SDKs) have resumes that don’t push any creative boundaries, and could easily make fine candidates for positions responsible for working in those kinds of areas. However, a decent eye for design is becoming increasingly important for many engineering positions.

Complex Language

Resumes filled with pompous, overly complex language can be a sign of a programmer who prefers to look smart rather than communicate effectively. While this kind of candidate may have written some very dense code that works, nobody on their team probably understands it, and everyone is afraid to touch it in case they break it.

Programmers who have recently left a long stint in academia to enter private industry often produce resumes full of lofty language. In those cases, it’s probably a symptom of them having to write peer-reviewed papers for years rather than a desire of theirs to show off how many grandiose words they know. Still, an overly verbose, high-register writing style can be a red flag that the candidate may not naturally write code that is simple for others to understand.

Job Jumping

Candidates who have a history of jumping from position to position every year ring the alarm bells for many employers – they are the last people a company would expect to think about the readability and maintainability of their code. They will be considered as the kind of engineer that gets excited about working on new challenges but gets easily bored when asked to work on fixing bugs in existing features. Engineers quickly develop expertise in niche areas in any company, so having people leave after a short initial investment is not only costly for the employer, but can be detrimental to overall team morale.

A job jumper might be wonderful for a position that needs someone to build features quickly with the intention of handing their work off to a dedicated maintenance team, or as someone who can migrate from project to project, but they would probably need to be paired with others to oversee their work and ensure that their code is good enough to be allowed to go into production for years into the future. After all, the chances that they’ll still be in the same company when changes need to be made to their work are pretty slim.

What You Can Do

Your resume is a window into your programming skills and your personality. Make a special effort to overhaul yours to be viewed as a more desirable candidate to potential employers. For example, if you’re worried about your writing skills, have a professional proofreader check your resume for typos or stylistic mistakes.

If you are friends with a technical hiring manager, ask if they’ll help you by having them spend just a couple of minutes scanning your resume and then telling you what kind of programmer you appear to be, and in what kind of roles they believe you would fit. You might be surprised at the feedback, but at least you’ll be able to take some action to change how you appear to potential employers in order to make sure you increase your chances of not only getting a job, but of earning a position that is truly a great fit.

Understanding Software Engineering Job Titles

The world of professional software engineering is full of titles and grades. Employers use job titles as a means to help them build new teams with the right mix of talent, attract the right caliber of candidates when hiring, create attractive career paths and assist with compensation planning. However, many companies assign titles differently, making their systems difficult to understand, especially for younger engineers.

Sometimes employers will be very precise and define an engineering career track that might look like this:


Experience Required


Sphere of Influence

Associate Engineer / Junior Engineer / Intern 0 years Bug fixes, minor feature Self
Software Engineer 1-4 years Features Team
Senior Engineer 4-8 years Modules Development Group
Principal Engineer 8-12 years Product, Architecture Company
Fellow 12+ years Products, Technical Strategy Industry

This model is most often used by companies with large and well-established engineering teams.

Other employers use grades that sound more like movie sequels than job titles:

  • Software Engineer I
  • Software Engineer II
  • Software Engineer III
  • Software Engineer IV
  • Software Engineer V

It probably won’t come as a surprise that the above bureaucratic-sounding titles are very similar to the definitions used by the US Department of Labor.

While it’s less common, some companies even drop the concept of job title progression completely and have everyone be just a plain old “Software Engineer,” regardless of their experience or talent. This can work wonders by preventing the formation of ivory towers and by empowering younger engineers to participate at the same level as their older peers. However it can be more difficult to implement because it goes against most people’s traditional (or even cultural) expectations, and it can cause unease for those engineers who strongly equate title changes with career advancement.

Given that there’s no standard structure for engineer progression, a Principal Engineer moving to a new company could be offered the less impressive-sounding title of Software Engineer, even though they may be taking on far more responsibility and increasing their sphere of influence.

Mature engineers tend to focus more on the opportunities and challenges available in a new position than they do about what they’ll be putting on their LinkedIn Profile. They know that any technical hiring manager worth their salt understands that every company uses different scales, and those managers won’t blindly assume that the candidate had been demoted mid-career if they see a title progression that looks somewhat backwards. They correctly focus on the engineer themselves and their innate talents, not on the details of their old business cards.

Should you worry about changing your title when making a move from one company to the next? No, you shouldn’t. At the end of the day, hiring managers for engineering positions are far more concerned about your technical chops than your title. Understanding your responsibilities and sphere of influence will be things that come out in the job interview. So, if you’re on the hunt for a new position, look for companies with a solid business model with a healthy and functioning team that will be taking on interesting challenges. Put minimal emphasis on the title you’ll bear once you work there, and focus more on how the position will allow you to develop your skills and knowledge. Those are the most valuable assets prized by any engineer, and by the managers who hire them.

UX, Then Architecture, Then Tools

Imagine you are building your dream house. Would you trust a general contractor who talks like this?

First, we’re going to pick out the material for the kitchen counter and the glass for the windows. Let’s just guess the amounts of each to buy for now.

Then we’ve got to buy some of that new concrete everyone’s been talking about. I suppose a truckload will do it for now, but we could always order more later. I just can’t wait to try it out!

After putting the beams in place we should decide how many floors the house should have. And right at the end we should decide what style the house will be. Sometime before you move in we should get planning permission, and I’ll probably contact an architect for some drawings after you’ve settled in.

It sounds ludicrous because there’s a well-established method for building houses, and it’s based on common sense. You start with a vision, get a set of plans, pour a foundation, build the framework, fill in the internal stuff, and finally finish all the little details.

Putting any step out of order would cause complete chaos. Finishing the walls before the electrical would mean you’d have to punch holes in all your walls in order to run wires around the house. Cleaning it before it is completely finished would be a wasted effort given the amount of dust builders cause while they work.

However many coders build their systems backwards. They become enamored with the latest whizz-bang framework or charmed by the reportedly speedy performance of the newest database. And they lead their thinking with those choices as they build new features, whether those technologies are appropriate or not.

More importantly, using a technology-first design typically means that the user experience (UX) will be left until last. And if you put your users last in your order of priorities, it will unfortunately be very evident in your system’s lack of usability.

UX First

The first order of business in application design is deciding what its users will experience. This should be a high-level vision sketched out on paper or in simple digital mockups, and it should express the flow of the system from the user’s perspective.

It doesn’t matter if you’re building a web application for senior citizens or a system-level tool for serious computing nerds. The UX must be designed first.

Type of System

Your First Thought Should NOT Be…

Your First Thought SHOULD Be…

Online music player “I’m going to design the database schema!” “Let’s design the UX”
Social media plugin “Let me start hacking around with some online social media APIs!” “Let’s design the UX”
Multiplayer Game “SuperFastDB is apparently really scalable, I’ll start testing it today!” “Let’s design the UX”
Virus Checker “I’ve been dying to write a new virus scanning algorithm, so I’m jumping right into that!” “Let’s design the UX”
GPS Device “I’m going to research the latest in OLED technology right away!” “Let’s design the UX”

Then Comes The Architecture

Once the UX has been designed and the vision of the system has been defined, an architecture should be laid out to make sure that the code that eventually gets written will actually meet the needs of the users. The choices made in the UX design radically shape and inform a system’s architecture.

A good UX design will cater for less obvious things that might be part of the overall user experience. A well-written specification might include requirements such as “the overall load time for page loads must be less than 200 msec” because the designers know the consequences of slow page load speeds. It might also call for close-to-zero downtime, so the architecture might end up requiring a multi-datacenter deployment.

Last But Not Least, The Tools

Now it’s finally playtime! Once the UX has been defined and the architecture has been laid out, the process of picking the right technologies, frameworks and libraries can begin. The crucial point is that now the tools are being chosen with the UX and architecture in mind, so any tool that doesn’t fulfill the needs of either can be quickly disregarded.

This Does Not Mean “Waterfall”

If you think that this design sequence requires an outdated Waterfall-like approach to accommodate it, think again! This is completely appropriate for Agile development. The implementation of a whole new product, an epic or even a single user story should follow the UX -> architecture -> tools sequence. When beginning the development of a product or epic, spikes should be used to design the UX and the architecture. And individual user stories should include enough details for the engineer to know what the UX for that story should be once it is fully implemented, and the engineer should also estimate enough points to cater for architectural planning to be done once work on that story begins.

Tools are great fun to research and to experiment with. Programmers love discovering new ones and finding “The Next Big Thing” in the framework jungle, and having lots of tools at your disposal is wonderful when the time comes to build a system that satisfies the UX and the architecture. Just don’t begin the entire design process with them. So remember: UX first, then architecture, then tools.

%d bloggers like this: