Skills that Programmers must master before an Interview

Technical interviews require programmers to demonstrate a number of skills to land a lucrative job—but luckily, most can be practiced and honed over time.

The skills needed are going to vary wildly based on the type of role, industry, and the company you’re interviewing at“.

At the bare minimum, we would recommend having a working understanding of Data Structures and common algorithms. Along with that, we’d recommend being as comfortable as possible in at least one major Programming Language.

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

To master a technical interview, programmers should demonstrate the following skills:

1. Be enthusiastic

Enthusiasm has a huge impact on interview results. About 50% of the candidates who fail interviews at companies fail for non-technical reasons. This is usually described by the company as a “poor culture fit”. Nine times out of ten, however, culture fit just means enthusiasm for what a company does. Companies want candidates who are excited about their mission. This carries as much weight at many companies as technical skill. This makes sense. Excited employees will be happier and work harder.

The problem is that this can be faked. Some candidates manage to convince every company they talk to that it’s their dream job, while others (who are genuinely excited) fail to convince anyone. We’ve seen this again and again. The solution is for everyone to get better at showing their enthusiasm. This is not permitted to lie. But interviewing is like dating. No one wants to be told on a first date that they are one option among many, even though this is usually the case. Similarly, most programmers just want a good job with a good paycheck. But stating this in an interview is a mistake. The best approach is to prepare notes before an interview about what you find exciting about the company, and bring this up with each interviewer when they ask if you have any questions.

2. Problem-solving abilities

The ability to demonstrate problem-solving skills is often more important than proving technical expertise in other areas.

What Interviewer look for is how does a programmer think about solving a problem. And then they look for action they are taking in learning how to improve their skills. They don’t care as much if you are an expert in a specific language because any competent programmer can learn a new language in a week. But if you don’t have good problem-solving skills and are not constantly trying to improve, then they will end up hurting your project.

3. Study common interview concepts

A large percentage of interview questions feature data structures and algorithms. For better or worse, this is the truth. You do not need to be an expert, but knowing the following list of algorithms and data structures will help at most companies.

  • Hash tables
  • Linked lists
  • Breadth-first search, depth-first search
  • Quicksort, merge sort
  • Binary search
  • 2D arrays
  • Dynamic arrays
  • Binary search trees
  • Dynamic programming
  • Big-O analysis

Depending on your background, this list may look trivial or may look totally intimidating. That’s exactly the point. These are concepts that are far more common in interviews than they are in production web programming. If you’re self-taught or years out of school and these concepts are not familiar to you, you will do better in interviews if you study them. Even if you do know these things, refreshing your knowledge will help. A startlingly high percentage of interview questions reduce to breadth-first search or the use of a hash table to count uniques. You need to be able to write a BFS cold, and you need to understand how a hash table is implemented.

4. Basic Database Knowledge

Even though the landscape of databases has changed quite a bit in the last few years, You don’t see databases going away any time soon, so we think you probably should know a thing or two about them, don’t you?

We would say that a developer today should at least be familiar with relational databases and probably should have some understanding of document databases as well. Some teams will, of course, have dedicated database developers or database administrators (DBAs), but that doesn’t really excuse you from not knowing at least the Basics of Databases.


At the very least, you should know:

  • How databases work
  • How to perform basic queries to get data
  • How to insert, update, and delete data
  • How to join datasets together

5. Get help from your interviewer

Interviewers help candidates. They give hints, they respond to ideas, and they generally guide the process. But they don’t help all candidates equally. Some programmers are able to extract significant help, without the interviewer holding it against them. Others are judged harshly for any hints they are given. You want to be helped.

This comes down to process and communication. If the interviewer likes your process and you communicate well with them, they will not mind helping. You can make this more likely by following a careful process. The steps we would recommend are:

  1. Ask questions
  2. Talk through a brute-force solution
  3. Talk through an optimized solution
  4. Write code

After you are asked an interview question, start by clarifying what was asked. This is the time to be pedantic. Clarify every ambiguity you can think of. Ask about edge cases. Bring up specific examples of input, and make sure you are correct about the expected output. Ask questions even if you’re almost sure you know the answers.

Next, you should talk through the simplest brute-force solution to the problem that you can think of. You should talk, rather than jump right into coding because you can move faster when talking, and it’s more engaging for the interviewer. If the interviewer is engaged, they will step in and offer pointers.

The process for the more efficient solution is the same as for the brute force. Again talk, don’t write code, and bounce ideas off of the interviewer. Hopefully, the question will be similar to something you’ve seen, and you’ll know the answer. If that is not the case, it’s useful to think of what problems you’ve seen that are most similar and bring these up with the interviewer.

Finally, after both you and your interviewer agree that you have a good solution, you should write your code. Depending on the company, this may be on a computer or a whiteboard. But because you’ve already come up with the solution, this should be fairly straightforward. For extra points, ask your interviewer if they would like you to write tests.

6. Mastering a Development Platform

You should have some experience and mastery of at least one development platform and the related technologies or frameworks that go with it. Again, this is another one of those things where We don’t think it’s so important what you choose, so much as it is that you choose something.

Companies usually hire developers to develop for a specific platform or technology.

This means being familiar with the platform itself, as well as what development tools, idiomatic patterns, and common frameworks programmers typically use when developing for that platform.

7. Highlight results

The third type of question you may encounter is the experience question. This is where the interviewer asks you to talk about a programming project that you completed in the past. The mistake that many engineers make on this question is to talk about a technically interesting side-project. Many programmers choose to talk about implementing a neural network classifier or writing a Twitter grammar bot. These are bad choices because it’s very hard for the interviewer to judge their scope.

The solution is to choose a project that produced results and highlight the results. This often involves picking a less technically interesting project, but it’s worth it. Think (ahead of time) of the programming you’ve done that had the largest real-world impact.

8. Knowledge about Dynamic languages but mention C

We recommend that you use a dynamic language like Python, Ruby or JavaScript during interviews. Of course, you should use whatever language you know best. Several classic books on interviewing recommend that programmers choose Java or C++. At startups at least, we’ve found that this is bad advice. Candidates do better when using dynamic languages. This is true, because of dynamic languages’ compact syntax, flexible typing, and list and hash literals. They are permissive languages.

No matter what language you use, it’s helpful to mention work in other languages. An anti-pattern that companies screen against is people who only know one language. If you do only know one language, you have to rely on your strength in that language. But if you’ve done work or side-projects in multiple languages, be sure to bring this up when talking to your interviewers.

9. Practice, practice, practice

You can get much better at interviewing by practicing answering questions. This is true because interviews are stressful, but stress harms performance. The solution is practice. Interviewing becomes less stressful with exposure. This happens naturally with experience. Even within a single job search, we find that candidates often fail their initial interviews, and then pass more as their confidence builds. If stress is something you struggle with, we recommend that you jumpstart this process by practicing interview stress. Get a list of interview questions (the book Cracking the Coding Interview is one good source) and solve them. Set a 20-minute timer on each question, and race to answer. Practice writing the answers on a whiteboard (not all companies require this, but it’s the worst case, so you should practice it). A pen on paper is a pretty good simulation of a whiteboard. Reading a lot of interview questions has the added benefit of providing you ideas to use when in actual interviews.

Even experienced candidates will benefit from this. Interviewing is a fundamentally different skill from working as a programmer, and it can atrophy. But experienced programmers often (reasonably) feel that they should not have to prepare for interviews. They study less. This is why junior candidates often actually do better on interview questions than experienced candidates.

Conclusion

Passing interviews is a skill. Being a great programmer helps, but it’s only part of the picture. Everyone fails some of their interviews, and preparing properly can help everyone pass more. Enthusiasm is paramount, and research helps with this. As many programmers fail for lacking enthusiasm as fail for technical reasons. Interviewers help candidates during interviews, and if you follow a good process and communicate clearly, they will help you. Practice always helps. Reading lots of interview questions and relieving yourself from interview stress will lead to more offers.