Coding Interview Questions I would Ask

I have thought long and hard about interview questions I might ask if I was on the opposite side of the table; specific questions are problematic: “What does X thing do” as it suggests every programmer should know any feature of any language or technology you might be hiring for, which is just not the reality of the programming world right now.

Interview Questions

I would ask the standard questions to establish their experience and familiar technologies, and I would also ask questions about what they were looking for in the job and get a sense of their character from an HR perspective, but as far as technical questions go, the fewer the interview questions the better in my opinion. It is better to spend more time on a few useful interview questions than less time on many useless ones. I would ask only these 5 questions outside of the generic ones mentioned. I would also give them ample time to answer them and press them if their answers are too brief.

• What is the biggest annoyance you have run across in programming?
• What is the hardest programming problem you tried to solve?
• What is a programming language, tool or technology stack you love and why?
• What is something you learned (related to programming) in the last year? (at work or on your own).
• What is a programming topic, feature, or technology you really hope to learn or improve upon in the next year, and why are you interested in it?

The first two questions give a lot of information about whether they have had experience or not in the industry. “The hardest problem” question I stole from a question Elon Musk asks, which is not an easy one to answer in a split-second but should give interesting results if you let the candidate think it over.

The last three are to make sure they have some continuing knowledge and love for code, which for me might be the most important asset to have.

Coding Challenge

I am not a fan of giving a specific challenges, as it tells you very little, and it often wastes the candidates time, particularly if they have already written some code for interviews. Instead, I think an example of someone’s work is much better. I would simply ask:

Give us something you already made, or create something new using any language/technology (it does not have to be a technology we are hiring you for), and about any subject matter you want. However, the bulk of the code you write should be between 150–500 lines total (if additional configurations or build/setup files are needed, that is fine)

In the interview I would print out some of their code and ask them questions about it, just to make sure they have a clear understanding of how it works (and that they wrote it).

Pay close attention to:

• Why did they choose this program? Was it clever, deep, mathematical, etc.? Or was it a phone-in Console.Write app that barely did anything. Obviously expectations can’t be high for a sample of work, but it definitely doesn’t hurt if a candidate shows something clever. It also might be worth asking the candidate directly why they decided to code the program they did.
• What technology stack did they use? Did it align with the position’s requirements? (obviously not a bad thing). Was it something a little different, perhaps something new? (this might be a good sign they want to learn). A worse sign might be something older that you aren’t hiring for, but of course it is hard to go off these facts alone.
• How did you like the code? Code quality is obviously highly subjective, but it is safe to say that if your team hates it, they might not be a good fit. This to me is the most obvious thing to look for.

Conclusion

At the end of the day, it is impossible to conduct the perfect interview (or be the recipient of the perfect interview). These questions are not the end-all-be-all either, I would far rather have someone who knew little about code but was easy to work with and willing to learn, than someone who was horrible to work with and was an expert in coding.