1) Know the basic math concepts
Do you know what a Palindrome is? Have you used Prime Numbers since university? You will definitely feel more confident if you skim through these concepts before your coding interview.
I am repeating myself as I have written a full post about this topic here.
2) Recursion
As with basic math concepts, recursion is rarely used in mainstream software development. It’s even considered a bad practice in most situations, as the resulting code is hard to read and debug. However, some companies use it in their technical interview. Be prepared:
Factorial
Fibonacci Number
Even Fibonacci Sum
3) Understand the problem
Sounds obvious, but a significant number of candidates start coding before they fully understand what they are asked for.
4) Ask questions
Some companies deliberately ask-open ended questions. Being able to ask pertinent questions is probably more important than coming up with a perfect answer. Even when the interviewer asks direct questions, don’t shy away from asking questions. Do I have to consider negative numbers as input? Is the date given as String or as an epoch?
5) Think out loud (and then listen)
After you have understood the problem and have a rough idea of the algorithm steps, you definitely should describe them out loud. There are numerous advantages to this approach. First, you have a chance to demonstrate your analytical skills. Second, it works as some sort of self-validation - if you can explain it, you can translate it into code. But most importantly, if your approach is wrong or if there’s a corner case that you haven’t though of, your interviewer is very likely to give you good printers in the right direction. Listen!
6) TDD it !
One caveat here: if you are not very keen on Test Driven Development, that’s really easy to spot, so it’s much better to admit that you don’t do it. I personally like it, I do it 80% of the time, but I think it would be silly to reject a candidate because he/she doesn’t.
7) TDD it… but don’t overdo it!
Most likely, your interviewer is also a software developer. Developers are among the most impatient people you can find. Why is this relevant? Well, don’t spend the first 15 minutes of the coding question setting up your “TDD framework”. Particularly when there’s a laptop involved, it’s common to see developers bringing in JUnit, Mockito, Hamcrest as dependencies, and then write tests for every happy path and error scenarios you can imagine. One time one candidate spent 5 minutes describing the virtues of the Red Green Refactor method (here for reference). Of course, he wrote the first useful line of code 20 minutes after the interview started.
8) Don’t be afraid of restarting from scratch
Sometimes you just get on the wrong track. When that happens:
- Take a deep breath.
- Explain what you were trying to do.
- Explain why your initial solution would never work.
- Explain your revised algorithm.
- Move on …
9) Bring your laptop with you
Even if your interviewer uses the same IDE as you do, chances are that keyboard shortcuts, menus, etc. will be different. In most situation using your own laptop is completely acceptable, feel free to ask for it.
10) Finish on a good note
The vast majority of candidates (even the successful ones) do not finish their code task. That’s OK! However, when the time is up, you should have a good idea of the steps to finish it. Make sure that you succinctly describe them to your interviewer.
Another aspect you should mention is refactoring. It’s very likely that your code will be a bit of a mess. Describe what you’d do to make it more organised and readable.