#### 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.

#### 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.

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:

1. Take a deep breath.
2. Explain what you were trying to do.
3. Explain why your initial solution would never work.