Imperfect Job Interview: How Can a Software Developer Show Their Best Side?

In their quest to hire the best specialist, companies select 6-10 candidates for one vacancy. However, not every one of them passes even a telephone interview, and only 2-4 people receive an invitation to an interview in the office/zoom. Only 2-3% of applicants reach the final round and can count on a lucrative offer.

In this article, I will dive into 3 problems that prevent developers from presenting the best sides of themselves passing an interview perfectly, and recruiters/employers from identifying the best candidate by conducting the perfect interview. I will try to take into account both points of view, based on my 11 years of experience in IT and management and more than a thousand conducted interviews.

1. Confused, inconsistent speech and “demi thoughts”

The first and most common problem is related to the presentation of thoughts. Short and incoherent speech does not make the best impression. In addition, this is an occasion for the interviewer to think: what if the developer makes the same mistakes at work? 

By the way, you can trace the pattern between how a specialist expresses thoughts and writes code. The fact is that during the work of the programmer, the same parts of the brain are active as during the perception and formation of speech. Edsger Dijkstra, an adherent of conscious programming, spoke about this back in the 80s.

“Demi thoughts” is one of the manifestations of inconsistent thinking. The candidate jumps from topic to topic, avoids the question and does not finish the sentence. This is often reflected in the work, in particular – in decision-making.

Case study: how spontaneity plays against the candidate 

During the interview, the candidate started talking, stopped, finished the sentence “to himself / in mind” – and changed something in the code. It sounded like this: “Perhaps I could … but no, it’s better like this.” He made changes spontaneously and without explanation of his actions.

I have a lot of questions after this test. What is the purpose of the action? Perhaps a bug in the code? What does it consist of? I did not receive information that would help to understand whether the specialist is good at making decisions.

A problem with the presentation of thoughts may be a sign that the candidate:

• Writes code that lacks valuable qualities such as conciseness, capacity, and consistency.
• Has difficulty communicating information to the team, management, and clients.
• Makes decisions spontaneously or, on the contrary, thinks over each issue for too much/long.
  

How to act in this case:

• If you are a candidate, watch what and how you say. Imagine that the specialist from the example above would finish the thought and ask for the opinion of the interviewer in a such way: “It seems to me that depth-first search can be applied here, but given ___, I think ___ would be better. What do you think?”. It’s only 2-3 seconds, but it’s a completely different experience, right?
• If you are an interviewer, also watch what the candidate says and… and control your speech too. If you see that the candidate is just worried – ask questions, and do not interrupt or change the subject due to pauses. Remember that for you this is just another interview, but for the applicant, it can be the first and very exhilarating and disturbing experience. 

2. Rushing to coding (and vice versa)

The lack of a plan is a problem for developers of any level and specialization, but most often for middle-s with 2–5 years of experience. They listen to the issue, talk about the high-level structure of the code for 30 seconds, and immediately start writing it. As if they want to get to the finish line faster and smugly leave to drink coffee.

The principle “First come, first served” does not work in programming. Moreover, it greatly complicates life. The one who initiates development right away and designs on the go subsequently spends a lot of time refactoring.

Code planning does not guarantee success, but it saves time in the long run. Thinking through the structure at the middle level – through pseudocode or using notes – minimizes errors. But do not forget that everything is good in moderation.

Case study: how “under planning” fails a programmer 

We hired a developer, and after onboarding, I gave him a number of tasks. He didn’t share his implementation details with us, he didn’t think about the structure, and he didn’t communicate a high-level code design idea (he didn’t even put it in notes!). Instead, he immediately went directly to programming.

After a while, he was distracted – and it completely flew out of his head what and how he wanted to do next. Neither I nor the team could help because they weren’t aware of his idea. The developer lost several hours rethinking the problem and started writing code from scratch.

The Downside: How Overplanning Fails the Programmer

During testing, the programmer shared his thoughts on the architecture, took notes, and disassembled everything into details, making sure that the solution was correct. He was so carried away by planning that he did not have time to complete the task – a worthy idea remained unrealized.

Of course, the candidate can receive bonus points for developed thinking and communication skills. But if such a programmer works in sprints and tight deadlines, this may cast doubt on the success of the project.

A plan scheduling problem could be a sign that the candidate:

• Avoids the plan – relies on speed, without delving into the nuances of the implementation of the idea and without discussing them with anyone.
• Overzealous with the plan – has a developed mindset and comprehensive knowledge, but forgets about deadlines.

How to act in this case:

• If you are a candidate, work out your approach. Let’s say there are 20 minutes. This is not so little! So: 5 minutes creating a high-level design + 5 minutes planning a mid-level architecture + 10 minutes writing code and a brief double-check. Practice more to keep up and plan and solve problems. 
• If you are an interviewer, just ask. If you see an error in the structure, ask leading questions. This will help you understand what the problem is and fix the code at an early stage. If the candidate has already written 100 lines of code, one can only ask if he always works without a plan.

3. Reluctance to ask questions and ask for help

Another problem is that the developer avoids contacting the interviewer. Answers questions, but does not ask them. And even having difficulties with the task, he silently suffers – but does not ask for help! Often this behavior is the result of self-confidence.

Strange as it may seem, self-confidence is inherent in specialists at the beginning of their career path. According to the iCIMS study, 35% of graduates are very confident in their interviewing skills. On the one hand, this is good, but on the other …

Inexperienced specialists can make erroneous decisions without realizing it due to limited knowledge (Dunning-Kruger effect). Such a candidate rushes to complete the task without delving into the requirements and without asking clarifying questions. The result is often the invention of the wheel.

Case Study: Reinvent the Wheel and Fail

During the interview, the developer silently listened to the essence of the task and immediately began to implement it. In the process, he had difficulties – and it was noticeable. But the candidate didn’t ask a single question or ask for a clue. The result, alas, was far from the original requirements.

An unwillingness to ask questions may be a sign that the candidate:

• Categorical in their work, do not need advice, and prefer to act independently.
• Overestimate their knowledge and skills, because of which they make deliberately wrong decisions.
• Adhere to a specific strong opinion on any issues and avoid the new experience.

How to act in this case:

• If you are a candidate, don’t be afraid to say “I don’t know”. Tell to the interviewer what problems you encountered. Listen carefully to the answer – perhaps you will be given a hint or advice on what to do next. For example, ask if there is an alternative data set that can be used as test cases. So you show flexibility and interest in the best result.
• If you are an interviewer, do not refuse help. Your task is to direct in the right direction, but not to give the whole solution. For example, subtract one item from a category and see if the candidate is up to the task. But don’t give advice unless you’re asked to, even if you see obvious mistakes.

The points are obvious, but only a few are serious about all of them.

1. First impression. Be sure to come to the interview neat, healthy, and … sober. Yeah, in no case do not drink, even “for courage” and “good mood” – this “slightly” is always very noticeable! Applies to both sides. If this is an online interview – take care of the quality of communication and sound – you don’t need to conduct it in a car or near a construction site.
2. The atmosphere of the meeting. Many mistakes are due to the fact that the candidate is nervous. And if the interviewer also radiates hostility with all his appearance … Important: the one who wants and knows how to do this should interview! Quiet, peaceful, and smiling.
3. Specificity. To a direct question – a direct answer, and nothing else. Without “and you know, I had a case …” and “I swear, I understand this framework!”. Of course, given that the interviewer does not ask to “tell me at least something”.