Many of my interview candidates do poorly as they don’t understand how I evaluate them. While other interviewers’ criteria vary, there are common themes. Knowing the basics helps you judge yourself and improve your technique.

At interviewing.io, I evaluate people on three categories. I think this fairly represents how various companies will rate you. Even if not explicitly considered, they’ll play a role in your overall evaluation.

• problem solving
• technical skills
• communication

I’m asked to give a rating to each one, but they are intimately linked together. A candidate who lacks one ability will also appear to lack the others. Let’s take a look at each point here, trying to isolate its specifics.

Problem Solving

Problem solving is the part abstract from writing code. I want to understand your process, and not just the result. This requires that you know what the problem is, and what I’ll accept as a valid solution. Problem solving is a lot about defining constraints and finding ambiguities, or uncertainties, and resolving them.

The challenge varies depending on the question. My card game question requires you to write a small game simulation. I want to see how you approach this problem. I want you to ask questions. What exactly is a “card”, and how will you represent it? What does “deal” concretely mean?

Problem solving is about taking high-level requirements and translating them into concrete steps. If you’re working on a project, this would be the phase where you write user stories and user journeys. You don’t have to be this formal in an interview, but I want to see that you’ve understood the requirements. Tell me what you’re thinking and write the key points.

Show the inputs and outputs to the problem you’re solving. State whether you’re transforming data, or implementing a process. Describe how to break down the large problem into smaller ones. For an algorithm, mention related algorithms, and tell me how you’d adapt them to this new situation.

Identify what parts you recognize and how it’s analogous to something you’ve done before. If there’s a whiteboard, sketch out flow, data sets, and anything else in your head. Especially if you’re stuck, I want to know how you’re solving the problem. Never fall into a blank silent stare. I’m there to help you, but I can’t do that if I can’t follow your process.

And definitely don’t treat problem solving as a phase. I don’t expect you to come up with the perfect solution at the start of an interview. I want to see you take an idea and run with it. It’ll likely have problems and require corrections. I’ll even change the requirements on you, or criticize your approach. I want you to accept change and adapt.

💭 Your ability to solve problems depends on your technical skills. While problem solving is not a tangible skill, your designs are based on the real-world limitations of computers. It’s not possible to completely separate problem solving and technical ability.

Technical Skills

There are two major aspects of technical skills that I consider. The first is your experience in coding idioms and wisdom. Do you know what is possible and how to go about coding it? The second is specific language ability. Once you’ve said what you want to do, how well can you implement that in the language you’re using.

The first point is about your general coding knowledge. Are you aware of data structures, program flow, and all the things programming languages are capable of doing? This knowledge influences your problem solving ability, as this is your toolbox. Whether your design will work depends on whether the tools are available.

I evaluate the candidate here on how much they hesitate, or how quickly they work. I’m not judging the speed itself, but as an indicator of one’s proficiency with the tools. I’m also listening to how you speak, whether your voice carries confidence or is it an inquisitive tone seeking affirmation.

The second aspect, knowing the syntax and semantics of a particular language, is vitally linked to the first. How you express yourself in code is my primary window into understanding your general coding knowledge. If you’re struggling to write a loop, I have to decide whether it’s because you don’t know the language, or you’re uncertain of how a loop applies to the problem.

I’m looking at how smoothly you translate your ideas into code. For example, from my card game question, there is a phase of dealing the cards. You must split the deck into two stacks, one for each player. Whether you’ve chosen a loop, or a high-level splitting function, you should be able to write the code. Writing the wrong code, forgetting how a loop works, using the wrong splitting syntax, all reflect negatively on the candidate.

I don’t punish people for making mistakes. They happen. However, a pattern of similar mistakes, or outright repetition of previous errors, shows a lack of knowledge. If I spot a mistake I may ignore it, or I may ask you about the code. Being able to recognize mistakes reflects positively on your abilities.

Languages have a lot of features and I’m looking for how well you use them. Are you using enumerations and constants? Can you create a structure to encapsulate values? Are you correctly passing variables by value or reference? Do you use the standard error mechanisms?

I don’t expect you to know everything, but I expect you to know all the basics. For individuals claiming to be experienced in the language I’ll be looking for common idioms. For example, in Python I look at the use of list comprehensions and dictionaries. In C++ I’ll look for smart pointers and possibly lambdas. If the code is absent all the common language idioms, then it looks like the candidate is inexperienced in that language.

💭 When I conduct general interviews I don’t put a strong emphasis on language knowledge. Your code is one way that helps me evaluate you. However, if you’re interviewing for a specific position, that requires specific language knowledge, your language skills will be weighted more heavily.

Communication

Voicing your thoughts correctly is the best way to ensure I properly evaluate you. Candidates that cannot do this perform worse than others. Not only does speaking well improve my evaluation of your communication skills, it also ensures the interview goes smoother and you finish the code on time.

Talking is your buffer to mistakes in your code. If you just write code, then my only view on your abilities is through that code. If you tell me why you are writing the code, then I can understand your approach even if the code turns out to be wrong.

Which also means it’s pointless to read the code aloud. I can see the code and read it myself. Your words should express thoughts that aren’t explicit in the code. Many candidates recognize the need to talk, but I feel are unaware of what they should talk about. Thus they end up reading the code. Sharing your thoughts is something you can learn, but it takes practice.

Pay attention to programming vocabulary. You should know how to talk about software in industry terms. This reveals a lot about your experience and your attention to detail. I want to hear about concrete things, like instance variables, constant values, and calling functions with arguments. I want to hear you talk about popping items off a stack and enumerating the elements of a map. I don’t want to hear about “doing something with this thing here”.

I also don’t want to hear buzzwords. Don’t use terms you don’t know and don’t claim to know words that you don’t. Dishonesty is a major red flag in an interview. Don’t think you can get away with it. I’m good at spotting bullshitters, as are most people working in HR and many programmers who have done a lot of hiring.

Don’t worry about not knowing everything. I tailor my expectations based on your level of experience. Junior programmers have not been exposed to many concepts. Be open, honest, and inquisitive. However, I expect a lot from somebody with ten or more years of experience.

Interviews are interactive and communication ensures we’re both on the same track. A failure to communicate generally results in a misrepresentation of your problem solving abilities, and general programming knowledge. And the more I know what you are thinking the more I can help you towards solving the problem.

Conclusion

Generally it’s a lack of communication skills or problem solving that sinks a candidate. I can’t imagine a company that wants to hire somebody with either skill lacking. Okay, sure there are some cases where specific, and uncommon, technical knowledge is required. But even then, you’ll be competing with other candidates.

There are also individuals who can write basic code, but not apply their knowledge to new situations. They appear to have learned one particular approach without understanding any of the concepts behind it. I can’t always say how correct my impression is, as I go on what I see in the interview. This makes it imperative to show all these abilities.

You may be wondering how to demonstrate these skills. Obviously, to improve any one of them requires practice and study. But to show them all in an interview requires balance. Don’t keep your head stuck in the code. Be vocal about what your are thinking, this is the key way to reveal your knowledge and show how you’re solving problems. Don’t be afraid to show limitations in your knowledge, instead be open and show how you’re working around it. Talk to the interviewer. Sketch things on the whiteboard.

Be aware you are being evaluated, and on three primary things: problem solving, technical skills, and communication.