On The Soft Aspects Of Technical Interviews

There are many tools and content available to help prepare and solve the problems used in technical interviews. However, I am yet to stumble upon a good summary of the non-technical aspects of those interviews. I call them “soft” because they relate more to behaviours, including communication, listening, and less on hard technical knowledge. I see candidates often missing the opportunity to showcase them, reducing their chances of progressing to the next stage. I hope this post can help those candidates understand how those mistakes look and how to avoid them.

Before we jump into it, let me say: interviewing is hard for both parties. There is always pressure for the candidate to perform, and sometimes a minor error can throw them off balance and ruin an interview. I have failed to solve problems, and I have had brain freeze, where I could not answer simple questions or even write code(!). It happened not early in my career but just last year, when I was interviewing. I have worked as a professional software engineer for sixteen years and have been programming for 22. If you are starting your career, I hope this paragraph can encourage you to persevere.

The interviewer has their own set of pressures too. They have about an hour to simultaneously lead the interview and evaluate the candidate. The time is short, and a decision has to be made. This requires preparation, experience, and skill, and mistakes still happen.

However, pair programming and system design are entrenched parts of the technical interview process. So it is worthwhile familiarizing yourself with the non-technical aspects too. Here are four common soft mistakes candidates make, including how they look, why they impact the outcome, and how to avoid them.

1. No Questions

The candidate jumps straight into code or diagram drawing almost immediately after hearing the problem statement, without stopping to plan, consider or ask further questions.

The problem statement is usually optimised to give the minimal required information to get started, but not necessarily everything. Part of the exercise is to find out what other important details were not presented, e.g. edge cases. System design interviews are all about scoping functional and non-functional requirements. Also, just like in real software development, the cost of a question not-asked increases throughout the interview. At some point it becomes too late to correct, the candidate ends up solving a different problem, and fails the interview.

There should always be at least a couple of questions, e.g., about the input size, throughput, constraints, expectations, or further requirements. Of course, those questions will be evaluated too, but the mere fact that a candidate stops to consider something beyond the basic problem description is a positive sign for the interviewer.

2. Answering the Wrong Question

This mistake manifests itself when the candidate’s answer unintentionally misses the point of the interviewer’s question. It requires very sharp listening skills on both sides of the table. I find this mistake to be one of the harder ones to keep track of. When a candidate is very eloquent (a good skill otherwise!), it is possible to get lulled by a vaguely relevant narrative.

A typical example, using the probe-dig-differentiate framework, the candidate would be probed for more context about a recent project. They would be asked about aspects such as the team size, their role in the team, who made the decisions, any alternative solutions, etc. This probing stage enables further “digging” into how the candidate thinks about trade-offs, how they work in a team, etc. It adds more signal to help differentiate the best candidates.

But some candidates answer the wrong question. Instead, they retell the project requirements and the solution, emphasizing the technologies in use or the complexity of the problem. An interviewer may stop the candidate and rephrase the question. If this happens repeatedly an interviewer could start doubting whether the candidate has good enough communication skills. Reading, listening, comprehension, and the ability to answer the right questions are crucial day-to-day competencies.

I think I know why this happens at least some of the time. Silence can be intimidating, but it should not be. It should be leveraged to your advantage, by saying “let me think” and giving yourself 5-15 seconds to internalize the question. The last time I was going through the interview processes, I scribbled down the questions while the interviewer spoke and used those “let me think” seconds to re-read the question. This pause shows consideration, helps prepare a more coherent answer, and most importantly, boosts confidence in presenting that answer. Short and concise answers score more points than long rambles.

3. Failure to Admit a Lack of Knowledge

Candidates will deliberately try to slide through an answer, either by shifting the subject, answering indirectly, glossing over essential parts, or outright talking nonsense with confidence. Instead of acknowledging - “I don’t know.”

There are some questions where an improvised answer is good, but if the candidate is given a direct question, and proceeds to evade it - it is obvious to an interviewer. Most interview questions are deliberate, and the interviewer knows how good answers (plural) look. By trying to swindle it like a test in the school, a candidate loses a chance to show humility, self-awareness, and honesty. For an interviewer, it raises a question of trust. If this person is hired and given a task, can they be trusted to know when to seek help?

I think candidates succumb to the pressure of having to present themselves in the best possible light. However, there is a massive upside to being open about knowledge gaps. “I don’t know how to do this, but I think I know how to find all the required information in the documentation” is humble and disarming. The interviewer will provide a hint, and the candidate can proceed to the next step, and then focus on what they know instead of clumsily weaselling out of what they don’t.

If the interview is for a senior role and a candidate requires many hints to get through, maybe they are not ready for that role yet. Ultimately, at work, we never know everything, sometimes not even most of it. When a candidate shows that they can ask for help it is a positive signal. Dishonesty, on the other hand, disqualifies a candidate rapidly.

4. Inability to Accept Help

Sometimes candidates get stuck. It is pretty regular, helps evaluate potential knowledge gaps, and is not a negative sign. What matters is how they deal with getting stuck, because the behavior translates to many daily work situations.

A specific example: a candidate wasn’t sure what data structure to use for storing some values and got stuck and/or missed a subtle hint. When a list was suggested as a valid option to move the process forward, the candidate objected. In their view, it was not an efficient use of a list. Fair, but they also could not unblock themselves using any other data structure.

An outright objection to a hint while stuck is a gambit that can backfire. It is standard for a candidate to propose something better or point out mistakes, thus showcasing their specialized knowledge. However, when done while stuck and without a good alternative, it will raise a red flag.

Such behavior raises a question whether a person, if hired, could gracefully handle suggestions for improvements to their work. Or if every piece of feedback given would turn into bickering about minutiae.


Both interviewer and candidate come to the interview hoping for success. Think of the interview as a rollercoaster of small wins (positive emotions) and losses (negative emotions). Not the same negative emotions one may get from an outrageous tweet, but it is there. We are human, we want to succeed, and we want others to be successful too. A failed interview can feel sad even for interviewer. Now think of this quote by Maya Angelou:

“I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.”

I can bet that no interviewer remembers absolutely everything the candidate said or did, save for a few notes. However, they will remember those small wins (positives) and failures (negatives). Therefore I propose my own quote:

If you can maximize the positives and minimize the negative moments that the interviewer percieves - your chances of success will significantly increase.

How do you do that? You still have to be knowledgeable in the technical aspects, but thoughtful questions, active listening, honesty, and humility will get you past the negative dips so smoothly that the interviewer might not notice them.

Good luck with your interviews!

A special thank you to Adomas for substantial feedback on the original draft, and Helen for proofreading.

Recent articles

What Can 75,000 Pull Requests Tell?

I recreated Google engineering research about code reviews in a company with 10 years of pull request data, and defined some new interesting metrics.

On Fundamentals

I make a case why you should learn computer science fundamentals, after taking first steps in programming.