For the past 2+ years, I've interviewed more than 150 people for different Java positions, from junior to senior levels. During these technical discussions, I've observed a number of strange patterns repeating over and over again. Some of these are really counter-intuitive, maybe I'll talk about these in a different post.
All these interviews were really, really different, but one thing is constant: people get scared once they have to solve a programming puzzle at the whiteboard. I remember how I hated these kinds of tests when I applied to my current company. My reaction was not any different from most of the candidates' I talk with. The whole thing went like this: I told the interviewer how I hated these exercises, I mentioned how the problems were not realistic and finally, at the end of the exercise I complained about how I missed good old JUnit. As I mentioned, nowadays' candidates are not very different and I usually understand them. I really thought the puzzle part had to be done to torture people, who already happen to be freaked out as hell, with their pulse above 180, and can't even stop sweating.
And then the day came when all these (mis)conceptions went away. It was a face to face discussion with a guy from a different continent, with more than 8 years experience. During the first 40 minutes of the interview, he really aced it. He knew the answers to all my questions, he even predicted my upcoming questions. I was really impressed. I thought the coding puzzle would only be a formality, and I presented him a very easy task. And then, the guy melted down. At least I thought he had. He couldn't even write a single line of code. He was not sure about basic syntax and he failed the interview in a really bad way. It turned out he was a seasoned interviewee, who had looked up the best answers to common (and even less common) interview questions so he really managed to seem awesomely good.
That discussion made me realize two things; firstly, my questions were bad and predictable (from that point on, I try to ask scenario based questions, that do not have an exact answer but require thinking and reasoning). Secondly whiteboard exercises can be great. They offer a way to distinguish a person who is able to think logically from one who cannot.
From that point on, I've almost always given the same whiteboard exercise to the candidates (and one more, depending on their level of theoretical knowledge). Today I'm sharing this puzzle with anyone interested (which also means I'm retiring the problem and have to come up with another favorite one), maybe it will help a fellow software engineer be better armored for an upcoming interview. It goes like this:
"Given a list of integers, reverse the list. You are not allowed to use Collections.reverse(), any kind of loop or Java 8 streams. (Please write a single method)."
Aaaand that's it. If you feel like, stop reading (as I am about to share some hints) and try to solve it using your favorite programming language. In Java, this is no longer than 5 lines of code.
In their first shock, the candidates start talking about the task being not realistic, just like I did. According to my colleague, this is the worst kind of excuse, as realistic tasks would be really painful to solve in a job interview. Just imagine if you were told to write a REST web service and save the JSON request body in some MongoDB collection. You've got 15 minutes...
But back to the challenge. Many candidates cannot come up with any idea on how to start this. I have had too many interviews when at this point, right after facing the challenge, the interviewee gave up and told me they are not willing to think about it anymore, as they "are not able to solve it" anyways. Of course, we rejected all of them; not even trying is worse than anything else.
Usually my first hint is this: the List interface defines a method called subList(x, y). X is an inclusive, y is an exclusive index. This rarely helps, so time for the second hint: What could we use instead of loops? Something that behaves like a loop but is not one. In the next hint, I say out loud "recursion".
Sadly, many times this does not help either. People, all university graduates, cannot solve this problem knowing that they have to use recursion and being aware how they can partition the incoming list of integers. Sometimes the candidates realize it's recursion on their own, but they are unable to solve it. The two neuralgic points are stop conditions and the merging of sub-results. Truth to be told, I've seen some really good solutions with minimal help, but that does not happen often.
My advice would be: before going to an interview, take a few hours and practice. Solve a few exercises (take a look here) and watch out for the following topics:
Recursion (take care about stop condition and data partitioning/merging)
Arrays (take care about overindexing)
Collections framework (select the most populous city from a collection, select the most repeated word from a text)
You can many times see a suggestion about writing code on paper at home. It is, indeed, beneficial, but I think that's a pretty slow process. You can also try using your IDE, and forget about code completion. Just disable that feature, write your solution, then step through it in debug mode.Of course during an interview you have no debugger, but this way you can spot your mistakes very easily and can avoid them starting with the next exercise.
Oh, and of course, do not start complaining about the interview process. You cannot convince the interviewer not to make you write code on the whiteboard, and you will lose face. Don't give up too early, let the interviewer help you figure it out. Finally, try to stay positive, as a positive image can help you get that job.