Preparing for a TDD Interview

I recently recieved an email on my Java interview website from a candidate:

“I have a Java pair programming interview coming up with a firm with a strong focus on TDD. Any tips on how I should approach this? What are some key things you tend to look out for in these kinds of interview?”

This got me really excited as that’s a perfect description of the interviews I run. I love TDD and pair programming, so the main part of my interview process when hiring is a TDD pair programming exercise. Now, in the grand scheme of hiring dev teams, this is pretty rare. A suprising number of companies are happy to hire developers having not seen their code, akin to hiring an artist without seeing his work beforehand. I find this crazy, but I digress.

This can make the pair programming interview really intimidating. We’re not used to people watching us code, particularly not in a high pressure situation.

We can take the TDD and pairing elements as relatively seperate entities to preparing for.

TDD Interview

The main piece of advice I would give is "don’t lie about your experience". If you claim to love TDD and use it in your projects, but you fall flat on your face in the interview, it’s not going to look good.

TDD is absolutely a skill that can be taught and learned quite quickly (although it can take time to get used to it). If the role is TDD and you haven’t got the experience just make it clear that you are keen and eager to learn. I can happily take someone through the basics as part of the interview, and in fact their ability to pick it up and learn through instruction becomes part of the criteria. The ability to listen and adapt quickly is important.

Do not be afraid to ask the interviewer what TDD looks like to them and their team. It varies from team to team, developer to developer. Explain how you do TDD and then see if it tallies with how they do it. This can often lead to an interesting discussion on the merits of each way and earn you some easy brownie points.

As far as preperation for the day goes, the best advice is to practice, practice, practice. Even if you’re already doing it day in, day out, the fact is the interview question on the day will be something isolated that can be completed in an hour or so, which is very different to your normal code. Places like hackerrank and codeeval are full of these bite sized challenges. Pick one up, and build it up from the start using TDD.

For me, the TDD process is simple — write a test for the most minimum functionality (usually it’s a do nothing; e.g. “search returns no results if there are no items in the system” type affair. This helps you to create all the main objects and players in the system without any functionality). Make the test pass (for a nothing-test, make sure the default implementation throws an exception so the test initially fails), then refactor if required. Then write the next smallest test and continue expanding out from there.

As an interviewer, there are a few key things I’m looking out for. The obvious one is that you’re comfortable writing tests, you know how to use JUnit properly. When it comes to the implementation, I want to see that you avoid eager initialization. For example: one of the pairing interviews that I used to run involved creating a bookstore. We’d put books in the store and then create searches on them based on various attributes. Now, if this was a real system like Amazon then we’d build an amazingly resilient database. However, we’re in a one hour pairing interview and I’m asking you to search a list of 5 or 6 books. This can be achieved by storing them in a LinkedList (or ArrayList or whatever collection you care about).

Even when we’re on the second test (find all books with partial title matching) I’ve seen candidates start talking about databases, or even the peformance of different list implementations. We have 6 books. It doesn’t matter. Remember, TDD is about writing a test then doing the absolute minimum to make it pass. If you can make a test pass by returning a hardcoded value then do it! It shows you need a better test.

The third part of TDD, and specifically RGR, is Refactor. After each test look back and see if you need to refactor either your test or production code. Only do one at once though! If you refactor tests AND production code at the same time you can’t guarantee you’ve not fundamentally broken everything. Refactor the test, make sure all is green, then refactor the prod code if it’s needed.

The obvious one that came up in our tests was initialization. If you’re creating initialization code in every test you can probably pull it out into a @before setup method.

Paired Programming

As mentioned before, this can be highly intimidating, particularly if you’ve never paired before. I’ve seen people leave with their shirt soaked through with sweat. The interviewer knows it’s stressful too and will take this into consideration, but if you are nervous just take a breath and slow down. Don’t panic, and don’t waffle. Just try to stay calm.

It’s important to know that your pair is not your adversary — quite the opposite. He’s on your side. You’re working together on the solution. It’s ok to talk ideas through (although favor code over chat where possible) and to ask for help. When your pair is coding it’s good to make suggestions and try and help too.

Talk as you code. If you go silent the interviewers won’t know what you’re thinking, and a good pairing session involves lots of sharing. However, be sensible and try to stay focused. They don’t need you to talk through how you’re creating a List as they can see the code. Talk about your design and solution.

One of the main things we’re looking for is your ability to handle the IDE. You’re spending something around 4-6 hours a day in your dev environment and we expect you to be able to use it properly. Specifically, know your shortcuts. Simple things like knowing how to create variables, insert new parameters and extract fields should be part of your toolbox already but if not then now is the time to learn. There is no way to get to a "no" faster than manually copying and pasting a new parameter around the codebase.

That said, if you don’t know a shortcut but think there may be one then ask. It shows you’re keen to learn and want to be efficient, and that’s good.

In my interviews, both partners code. Specifically, one developer will write a failing test, the other will implement, get it to pass, refactor, then write a failing test and pass it back. If you’ve never done this, ask a friend or colleague to come and pair with you for a bit before the interview so you can get used to the flow. Again, if you’ve not paired before then tell the interviewer as they can help guide you through it.

The main things to concentrate on in your interview:

• Relax and try and enjoy it. Genuinely, some candidates leave having enjoyed it and learned something new, and as an interviewer we value that.

• Know your IDE.

• Write the minimum viable test. Do the absolute minimum to make it pass. Refactor when relevant.

• Don’t eagerly optimize. Remember: the minimum to make it work, and if you’re concerned about performance, explain to your partner after you’ve got a green test.

• Talk through your design decisions.