Practical Software Interviews

A medium article about Google interviews sparked an interesting debate about technical interview methods and questions. I realized that the vast majority of developers have never been the interviewer. Many developers may misunderstand the goals of a technical interview and the vantage point of the technical interviewer. Furthermore, influencers make Leetcode style interviews seem like they’re common outside of FAANG; they’re not. Here I’ll go over how typical software engineer interviews are run as well as debunking some common myths about software interviews.

Rule of Thumb

No, most SWEs aren’t making $500,000 after 10 years of experience, or 20. The average developer has 5 years of experience and makes around $110,000. A USA software engineer will make about $50,000 to $70,000 per year PLUS $10,000 per year of experience. This means it takes the typical developer 3-5 years to reach a salary of $100,000 USD. Again, this is outside of startups, FAANG or big cities where $120,000 qualifies a family of 4 for government benefits.

The Question Doesn’t Matter

I think most say this out of frustration. “I’ll NEVER need to reverse a linked list on the job!”.

While that may be true, the question isn’t the point. The goal of an interview is to assess the skills of the candidate. Outside of FAANG, senior software engineers are rarely asked to code in technical interviews. If a senior is asked to code, it is usually an easy task just to do a “gut check” to make sure they’re not a fraud.

While reversing a linked list may not be a common task as a developer; I’ve never done it. It DOES test if the developer understands basic data-structures and how to traverse them. In my humble opinion, there are much better questions to ask. Again, the question doesn’t matter too much. Furthermore, this would only be one of MANY questions asked in a 1 hour technical interview.

I do NOT have a bank of questions. Neither do most of the other lead developers. Why? Because we do software engineering daily. Why would we have to prep to talk about what we are masters of? Furthermore, my questions depend on YOUR RESUME. If you list Java, then I’ll ask about Java. If you list REST then we’ll talk about HTTP and REST. This isn’t rocket science. The interview isn’t about asking “how many balloons could you fit in Wrigley Field?”. I want to test the candidate on the subjects that they are best at. That shows me they can learn.

*side note. I realized after coding for 17 years that I had never reversed a linked list so I finally did. . . yeah that was boring.

Why doesn’t the question matter that much? Let’s use an analogy.

I don’t care about the question that much.

Imagine a chef is being interviewed for a position at a Michelin star restaurant. The interviewer asks the chef to make a simple dish.

The chef says “This is stupid! I’ll never make such a simple dish helper at such a fancy restaurant. This is beneath me! This doesn’t test practical kitchen skills.”

This tells the interviewer they have a poor attitude and a large ego. The interviewer calmly replies “Correct. BUT you will have to follow a recipe, measure ingredients, use a stove, taste the food making adjustments as needed while maintaining a clean workspace. WHAT you make doesn’t really matter, HOW you make it does”.

This brings me to a quote from the latest and final John Wick movie, “How you do anything is how you do everything.”. That is the point. How a candidate approaches a new problem, even an impractical one, is the same way they’ll approach most other problems.

This brings me to another comment that said something like “I should be able to use any and all tools available to me in the interview”. The interviewer isn’t evaluating CHAT GPT or one’s skills at copy pasting from Stack-overflow. The interviewer wants to know if the candidate has the fundamental skills to solve problems. This is why whiteboards, Google docs etc are used without IDEs, AI, Google etc.

Again, the goal of the interview for the chef isn’t about getting a free meal anymore then a software interview is about getting free software developed.

The Answer Doesn’t Matter

I blame schools. Students think the answer is more important than the method used to reach the answer. This is especially true when I’m conducting interviews of Interns or Junior developers. Again, seniors I don’t really ask to code. An Intern or SWE I isn’t going to have much practical or depth of knowledge on any one subject.

So if a human still needs to understand how to read, write and evaluate code to use CHAT GPT, then why wouldn’t I test that skill in an interview? Should I ask complex problems to

The Code Doesn’t Matter

When I’ve been the interviewer and the candidate, the code doesn’t matter that much. Many interviews have the interviewer share their screen and the candidate tells them where and what to code. This of course is less efficient than real life. One’s fingers can move faster, use IDE shortcuts, search, use AI etc. Nerves are involved as well. I like this approach because the candidate must explain what to do instead of just doing it.

If the interview is on the whiteboard then the code doesn’t need to compile or be perfect. For all intents and purposes pseudo-code to show the correct steps.

I think candidates are too focused on the code and solving the problem. I blame school for putting too much focus on grades and test scores; results. Software interviews are more like my high school math homework. On the very first day of class my math teacher gave us the answer key to all the homework problems. He cared more about us knowing how to use the correct method to obtain the correct answer, using the answer key to verify we had, instead of just giving the answers without comprehension. This is much like software where we start with the answers, unit tests, and then work backwards to verify our code produces the correct answers.

The article talked about how most candidates fail Google’s technical interview because they don’t show their work. I’ve interview candidate that had all the right answers memorized but once I asked open-ended critical thinking questions, they failed. They couldn’t ask clarifying questions. They couldn’t explain how to break the problem down into steps.

Even if a candidate can’t 100% complete a test, that doesn’t mean they failed. The test is just to see the candidate’s ability to solve problems, communicate possible solutions, explain possible side-effects etc. Very little of it is about code, especially at the senior level. It has been several years since I’ve been ask to actually write code during an interview. Usually it is higher level systems design questions, discussing the HTTP spec etc.

I sporadically write code at work. Some months I write a lot of code, others I spend doing dev lead tasks such as architecture, DevOps, helping my developers, working with BAs to create user stories and helping QA understand how to test upcoming features.

Your Approach Does Matter

“So you can figure out anything during the stress of the interview even if you haven’t done it before?” – Robert

Yes, that is the job of software engineers. We solve problems that we haven’t seem before. Otherwise, why would companies pay well into the 6 figures for me to copy paste solutions from CHAT GPT or Stack overflow? Anyone can write code, even AI, but few can write the correct code in the correct place that is efficient and performant.

Again to my Chef analogy. If the interviewer asks the chef to make Beef Wellington, something they have never done before. They should be able to do it. They may not be an expert at Beef Wellington but they should understand how to make a puff pastry, prep the ingredients, good meat etc. If they can’t then the interview would be concerned the Chef has used rote memorization to only mimic deeper comprehension.

(I made Beef Wellington for the first time last Christmas. Hence the analogy. I use a hybrid of two recipes. Oh so good. I’m not so good at keeping a clean workspace though.)