4 ms·
In interviews I like to try and get a reaction, and the best way to do that is to sit down with a coffee or two (or three) and just chat about their experience
by EnderMB 8y ago
In interviews I like to try and get a reaction, and the best way to do that is to sit down with a coffee or two (or three) and just chat about their experience over the last few years, in a judgement-free zone - dev to dev.
In terms of an actual question, the only useful ones are ones that come from this chat, because it's where we have a back-and-forth conversation about tech decisions, what issues they had, what they had to overcome, and what decisions that particular dev made. My goal is to get a reaction, negative or positive, and dig into why that situation happened, what they did to overcome it, and what they'd do with hindsight.
Not only does it make an interview more interesting for all involved, it tells you more about the candidate than a quiz would. You learn what they do under pressure, what pisses them off, and what experience they have for the kind of work you do, because you've been using your experience against theirs in conversation. Sometimes, to make it fair, I tell them (without dropping client names) issues I've had recently, and I see if any of the solutions were raised by the team, or are ultimately the solution we went for.
I've had enough success with this approach that (when I did interviews) this was my approach:
1. A really basic take home test, probably in a language they don't use, just to see if they can write any code. Literally something that takes an hour to do. A favourite of mine was to get them to write an application in a given language to hit an endpoint, with a given code and their email address. When done correctly, an email is sent to our HR team, who then set up an interview. Based on our logs, you'd be surprised at how many candidates couldn't do this - by which I mean had clearly worked on the test, submitted something, and had failed to send a PUT request with the correct data.
2. A relaxed interview, like above, in neutral ground like a coffee shop. I use the walk from office to coffee shop to handle company questios, and the standard interview stuff,
- kstenerud 8y agoI would have failed your test. I'd have assumed that you didn't want your server inundated by requests, set up my own server to verify what my client was doing, and then submitted the code. Even if you specifically told me that I must actually hit your server, I'd still test on my own server, and then possibly forget to change the endpoint before submitting (no way to unit test that). Shit happens, and you lose someone on a technicality. Also, what if your server stops working? Now you're wasting people's time. Don't rely on magic; it eventually bites you in the ass.
- insomniacity 8y agoNot GP, but I would say that lack of attention to detail is a negative mark. Depending on GP's industry or team, that could be a dealbreaker. If you can't connect to the server, or it returns a fatal HTTP error, a reasonable candidate would reach out via other means (assuming they aren't deliberately hidden or unavailable).
- EnderMB 8y agoWe had covered all of these eventualities. We had an uptime badge on the repo to say whether it worked or not, and we encouraged developers to tag us on a GitHub issue or email us directly if something seemed wrong. We were also keen to stress that this should take far less than an hour of their time. We didn't want to see dependency injection, metaprogramming, or anything overboard that showcased a developers knowledge - this is purely just to see if they can deliver code that matches a requirement in the time provided. In the case where we had downtime (once in 18 months), I just forwarded their email to HR and we spent some extra time going over code in the sit-down interview.
- ManlyBread 8y agoIf I would see that the server is unreachable I wouldn't contact anyone, I would interpret that as a red flag. The company would have no problem with deeming me unfit to work for them if I fail to complete the task - why should I consider working for that company when it's their fault that I'm unable to complete the task? What if this situation illustrates how the company works on the inside (no one takes care of the environments, things are constantly broken)? Is it worth it to find out?
- Maert 8y agoThat's a lot of jumping to conclusions. A simple "Hey guys, the server seems to be down, not sure if you're aware. Can you let me know when it's back up so I can submit my request, as intended?" Shows understanding, shows willingness to reach out and solve problems, shows ability to delegate responsibility.
- _mrmnmly 8y agoSame here. I've recently been put on the 'other side of the table', first time as a recruiter, and tried to be someone like you've mentioned in your comment. If someone would like to learn more, here's my brief blog post about the whole process: https://lukaszkups.net/notes/on-the-other-side/ https://lukaszkups.net/notes/on-the-other-side/
- bjourne 8y ago> 2. A relaxed interview, like above, in neutral ground like a coffee shop. I use the walk from office to coffee shop to handle company questios, and the standard interview stuff, Perhaps that is relaxing to you and most people but not everyone. Coffee shops can be very distracting because you hear other people talking and walking by and some even play music. Perhaps you want to screen out such candidates anyway so it doesn't matter much. But you are also screening out a lot of skilled developers who don't function well in distracting environments.
- world32 8y ago> and some even play music Sorry to be harsh but if you are unable to have a conversation in a coffee shop its unlikely you will make a good developer, regardless of how well you can code. You don't have to be a loud-mouthed extrovert or "heart-and-soul-of-the-party" type but social skills are necessary for most dev jobs.
- EnderMB 8y agoI agree completely, and this is actually the main reason why I moved it to a coffee shop, because my office was lucky enough to be directly underneath a quiet coffee shop with comfortable seats, lots of table room, and most importantly a relaxed and quiet atmosphere.
- world32 8y agoIts interesting to see how many people seem genuinely annoyed at this interview technique. I think that shows the value of it - this test does not seem aimed at testing how much of a "leet" coder you are but whether or not you can get a job done.