Technical interviews

In the last couple of years I somehow managed to participate in many interviews from both sides. I had lost a job due to some financial issues company had, so I had to look for something else. Couple of month later I was recruiting developers for my team and couple more month later I was looking for someone to replace me, because I was leaving that company. I also attend interviews once in a while even if I am not really looking for a job. In such cases I wouldn’t probably send my CV anywhere, but if I get a phone call and an interesting offer to have a chat — why not? This has helped me to form some useful connections. I also managed to find a job for some of my friends this way. This post is an attempt to share some of the things I have seen and done regarding technical interviews

When it comes to finding the right people, there is no better way to evaluate their skills than by actually looking at their code. I know this is kind of a controversial topic. Some developers even feel offended if they are asked to do a homework. One of the reasons might be, that companies, who ask for the homework don’t handle it properly. Yes, it is an unpaid work, but if both sides get something out of it, situation becomes a bit different. Developers are mostly interviewed by other more senior developers, which means, that an interviewee should be able to learn a thing or two from them. And there is no better way to do that than by code review and pair programming.

Another reason for not doing the homework might be an ego thing. As developers we tend to get many offers each month. And somehow we tend to think, that we are special. Truth is — there is a shortage of developers and some companies desperately need anyone, who can write code. Besides most of the times we just say no to the initial call, tap ourselves on the back and move on. But we shouldn’t — that call doesn’t mean anything. Company just called you because you had written something in your CV / LinkedIn profile, that their HR thought was trendy. What they actually want to say is — we want to see if you can prove your skills. And if you are just invited for a conversation, where the most difficult question is “tell us about your experience”, you don’t feel threatened, your authority is not questioned. If you have to show someone your code, that’s a completely different thing and many are afraid of it. I know — I am. Every time someone I don’t know is looking at my code, it makes me a bit nervous, but I’ve learned to overcome it and actually learn from it.

If I ask someone to do the homework, I definitely take it seriously. For the last couple of interviews what I did was following:

• Meet with the potential candidate, explain what we are doing, what would be his responsibilities, what we can offer, answer any of his questions
• I send a link to the homework description
• Candidate completes the assignment and sends me a link to github, bitbucket or any other public repository
• I spend at least 3–4 hours reviewing his code, writing down any comments and questions
• We meet, discuss the homework, improve it a bit doing some pair programming
• I send him a full list of comments, suggestions and questions I had regarding his homework. I also include a brief description about what I think are candidate’s strengths and weaknesses. Might also list some books and articles I think would be valuable for him to read. And I do this regardless if I plan to offer a job to this developer — he has done his part and deserves to be treated with respect.

One of the last candidates, who went through this process sent me a very nice email saying, that this was a really great interview and that he has learned a lot. That is a good indicator to me, that I am on the right track.

The homework itself is usually not too difficult. But there is a reason for that. I don’t really care much how complex issues you can solve and how many sorting algorithms you know — most of the companies don’t invent new algorithms or do anything similar. I want to see candidate’s attitude. Do they write tests (by the way I’ve noticed, that Java developers tend to write tests way more often than C++ programmers — no idea why), Do they perform common sense data validation, do they think about quality or are they saying “yes, but this is not for production”. Any code you write IS for production — in this case gained or lost business value is your new job.

The second part of the process (code review and pair programming) will show you how it will feel like to work with this person. What is his reaction to suggestions, is he willing to explain something if you don’t understand it. Many companies ignore this factor and hire exclusively for technical skills. I think this is a mistake. You can always learn new language or framework. It is way more difficult to stop being a person, who doesn’t treat others with respect. If you hire someone like this, you can easily lose good people, who will not tolerate such behavior.

Even if we agree, that homework is bad, what are the alternatives? On several occasions, when I was interviewed by other companies, they asked me to find syntax errors in the code written on the paper or do a paper programming. I like a comment by Sandro Mnacuso from DevTernity conference, that when asked to write code on paper, he also asks scissors and glue to do the refactoring. Ok, so I know how to write strlen() function in C. What does that mean? How often would I do that if i join your company? Don’t you want to evaluate how I structure my projects, how clean is my code, how I write tests, do I leave meaningful comments in commit messages, how regularly do I keep by code clean by refactoring, how I can explain my decisions behind choosing frameworks for my project?

I like to be challenged during the interviews — regardless if I am hiring or looking for job. If I don’t get it, if I don’t feel like I had to prove my skills to the company, I most likely won’t accept an offer if it comes. I like to work with smart people and if your interviewing process is strong, it means I will have smart colleagues. If I am hiring and the candidate asks a thing or two about our technology or architecture choice it is also a good thing. When bringing a new team member in, I want a new perspective on what we are doing. I want someone to look from the distance and ask questions, that we should have, but didn’t ask ourselves, when we made those decisions.

Stay polite. I have seen both interviewers and interviewees becoming defensive or plain rude by trashing the opponent. About a year ago during the interview my CV was criticized, because as they said, it was so bad, tat they couldn’t come up with the questions to ask (it was they who found me and offered to talk in the first place). Couple of months ago a technical guru in the company went in, asked to explain couple of pieces of code printed on a paper, stood up and left — no “thank you”, no “good bye”. He didn’t even say if in his opinion the answers were right. In both cases I was offered to continue the interview process in the next round. Needless to say, that I politely refused the offer.

Overall I think, that finding the right people is extremely difficult task. And finding the right company to work for is not much easier. I have made my mistakes in both cases, but each time I learned from them and thought about what I should do differently next time. I hope some of this information was useful. I would like to get some opinions about this topic, so if you have something to say, please leave a comment or let me know via LinkedIn or Email

Originally published at blog.andrisbriedis.com on June 18, 2018.