Some job interviews have coding tests in the interview. Some have "take home" tests. Some have several rounds of interviews. Some just have one.
If you were the one designing the developer hiring/interview process, what would it look like and why?
- Would you do multiple rounds of interviews?
- Would you have a coding test in the interview? What would that look like?
- What are some of the maybe less obvious questions you might ask?
- Would it be a short interview (< 30 minutes) or a longer and more thorough interview?
- Would you meet & greet with the team / show them around the office?
The idea with this is to take your experience as a developer and think about what you would want to know from a candidate and factoring what you did/didn't like through your own job interviews.
I've been interviewed a few times and conducted interviews a few times (I'll put my full thoughts as a comment below) and found that my own experiences changed what/how the interviews I ran went. I'm curious what other people would do it if they had the same opportunity.
Top comments (18)
I like a lot the process in the company I'm currently working on which was about the same I went through when I first interviewed with them.
After a screening call we send an offline coding challenge which is not that big at all, it's a ready made REST API and we ask from the candidate to add a feature to it. After we review the code and we pass them to the next stage, we are getting them to the office for almost a full day interview which consists of:
I went through a lot of interviews and I have to say that this one must at least be the most fun one, which is really something I value in a working environment.
I work for Trouva and here are our current open positions in our offices in Lisbon and London.
Interesting Kostas!
With the full day interview, at that stage, is that with the short list of say 3 candidates? I'm just thinking while it is very thorough, it also seems to be fairly time intensive. I mean, if you find the perfect person from doing that process it is great but otherwise, it might feel a little exhausting going to that level multiple times for a single position.
That is a good way to handle the offline testing. I didn't perform that in the positions I hired for however with the probation time for employees, it wouldn't take long to spot the liar. I think in the future, I probably would do the same as what your company does.
I am a fan of that part as I see it helping work out how well people will gel together. It is as much for the company as it is for the candidate.
I think you both have valid points.
I think there is a lot to get out of spending a whole day with a candidate. But, as James said, the time commitment is such a big thing. Especially if the candidate is already employed.
I recently had a lot of interviews and I really struggled just balancing my normal workload with finding time to fit in an hour interview here and there. I guess I could have taken time off but maybe other's have used up there allotted holiday time and therefore could not attend a day-long interview.
Multiple interview rounds on the other hand kind of get around this situation but can also be annoying due to travelling to the companies office and the wait of wondering what is happening between each round.
Basically, I think what I have said. Is that everything is good and also bad.
Interviewers: Hello Mr. Interviewee. We have seen your portfolio and we are very impressed. Could you start on Monday?
Me: Let's talk money...
I once had an interview where I was given a research paper to read for about 30 minutes after which I was asked to explain the content and then a few follow-up questions. This paper was related to the job I would be doing. It was a straight-forward, no-bullshiting interview. I like interviews that ask relevant questions not a "balance this red-black-tree" gotcha questions. Needless to say, I got the job.
Interesting approach!
Yeah I agree. That is definitely part of why I dislike coding questions in interviews: relevance.
I also think it is an unrealisticly stressful situation. Sure some might say the pressure is good but normally you don't lose an opportunity like a job for doing one coding aspect poorly while in a room with strangers who are judging every line. Maybe if the software you are working on is life or death, maybe then it is appropriate...
The perfect interview process in my opinion:
1) home code challenge (a small/easy project that can be created in 30 to 60min)
why?
2) three to five minutes of a video presentation
why?
It avoids an interview with false positives candidates.
3) Technical interview (45min to 1:30h)
why?
Now you can go deeper and check if the candidate is a good fit for the position.
4) Short CTO interview, and offer if applied.
Interesting! Hadn't thought about #2 and I guess with the ubiquity of smartphones, many people have cameras to record a short video. Probably also good at the first stage to avoid those that are already employed needing to travel to a number of interviews.
I'm not a fan of having to go in during business hours multiple times to interview but multiple stages (phone call, in-person interview, etc) is fine.
I'm the only person I know who actually likes whiteboarding but I don't think it's the best indicator of programming skill. It just gives an opportunity to discuss your approach to problem solving and code.
Ideal interview would probably be meeting the team and then peer programming with one of them on a basic feature.
Absolutely hate take-home tests.
What types of problems do you think work best when whiteboarding during an interview? Are you thinking things like FizzBuzz, sorting algorithms or something else?
I am curious, as a fan of take-home tests, what part don't you like about it? One of the things I like about it is that you don't need to be there in person to do it saving time, potentially making it easier to do a normal interview doing the day. You also are arguably in your most comfortable environment to program without stress. There are definitely potential downsides though like when they handball a feature for their product for you to implement (so you're basically free labour), the length of the test is way too long or the fact that you can potentially get someone else to do it.
I’d say it depends on the role. Nothing crazy complicated. Everyone is going to have access to Google on the job. I just like it because it gives me an opportunity to discuss a problem with the interviewer. Code tests in a text editor are totally valid too. If you just want to know if they know conditionals and loops then fizzBuzz is fine. If you think SQL is key to the job ask them to write a SELECT statement that requires a JOIN or something.
I don’t like take home tests because I want my time at home to be for me. And they almost always take longer than they tell you it will take because they can’t do it themselves without an advantage and most people wouldn’t say that it took them longer. If you have a time limit then it is even worse because I focus on how much time I have left like it’s a race.
At least in a one-on-one conversation you know the code test is going fine as long as you’re still talking to them and they are giving you good feedback. And you can ask clarifying questions which is almost as important as showing you know whatever they’re asking.
I'm not a fan of multiple rounds of interviews and I don't think I would ever be comfortable with a coding test during an interview.
In terms of questions I would ask, I like asking about something the person has made that they really enjoyed making. Ideally, that is something they programmed but I'm actually not that fussed if it isn't. There is no right or wrong way to answer (well, I guess not answering the question at all is "wrong") but really I just want to see how technical they can get into anything they are passionate about, trying to tap into their enthusiasm about any subject.
I do ask other questions like if they have any open source work but not to "grade" a person against someone that doesn't, purely just to see any code they have already written in the wild.
I do like the idea of "take home" tests and while I know people could 100% cheat, I do throw in a wide variety of problems. Basically, I build something the way we would for the company, rip out a bunch of things all over the place and see how someone else puts it back together. I give them relatively detailed information on what the functionality needs to be and off they go. I try and aim for this to be relatively short because time is valuable for both them and myself but I do find it a good insight into problem solving in a specific domain. I also don't require for it to be complete either, you focus on your strengths and that is all I am really wanting to see. If you can do it all though, great!
Would you do multiple rounds of interviews?
Only a couple, after a while it feels like you're getting led on -- or that it only takes one person along a complex chain to decide against me. Interviews and first impressions are hard enough, it's another thing to do 4-5 in a row with different people. Unless it's some government gig, there's no reason to screen someone so thoroughly.
Would you have a coding test in the interview? What would that look like?
Code comprehension, reading code and breaking it down. Rather than having them code on the spot, require docs, etc -- let them show you how they break down apps (cause that's what they'll do day one on your app).
Not a fan of writing actual code on the spot, or taking home "homework". I get paid to write apps, so even writing a small menial one is time spent without compensation. I'd rather keep working whatever gig I have, or find someone who'll value my time. Maybe if the "homework" were open source work, I'd feel more inclined, rather than doing code for a private, profit-driven company.
What are some of the maybe less obvious questions you might ask?
This one's hard cause the more random a question I ask, I can say that it's not exactly uncommon to hear it. I'd maybe paint some scenarios and see how the person works it out, like "how would you handle a project if the client didn't provide XYZ assets?".
Would it be a short interview (< 30 minutes) or a longer and more thorough interview?
Keep it short. I don't think anyone's interview skills are that great that I want to spend an hour with them.
Would you meet & greet with the team / show them around the office?
Of course. Helps someone understand the office better, know who to turn to, know where the bathroom is, etc.
Yeah I agree. Personally, the most rounds that seem good to me is 2 but I would much rather 1 round simply because time is valuable: theirs and yours.
Yeah, that is a good point. Rather than testing programming, you're testing understanding and problem solving.
I agree with not writing code on the spot as an interview environment really isn't going to bring out the best in a programmer.
I am a fan of a take home test though I would never have that be building a piece of functionality for the eventual application they may work on. I agree, that is doing work without compensation. I view the take home test as trying to allow the developer to be in their most comfortable development environment working on some small problems, custom made for testing. I aim for the test to be short (again, time is valuable) and encourage the developer to play to their strengths (especially if they don't/can't complete it all).
Yeah, you have all those project/client/colleague situational questions which are variations of each other like handling conflicts etc. I prefer asking a question about something/anything they made. Ideally this is something they have programmed but it really can be anything as I'm trying to tap into their enthusiasm about a subject and want them to get into the nitty gritty. I think it shows a few things like what parts of making they like and how well they can explain technical details.
Would you do that at the interview stage or when they are hired? I see the first (greeting the team) being important early on in the hiring process with the latter (showing around the office) being less important till they are hired.
I would run interviews like this:
surevine.com/a-day-in-the-life/
We honed that process while I worked at Surevine, and it's still truly excellent.
Interesting process! It does seem like a lot of time to spend on an interview and possibly inconvenient for the interviewee but if people are saying it is a positive experience and Surevine are getting good people onboard, you can't argue with the results. 🙂
Well, Surevine are 100% remote, and work with Government, so interviewing has to be done fairly carefully - it's a worthwhile tradeoff to them.
Also this is the second (or even third) interview - there's video tests and a phone call before then.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.