Live data from Hacker News

Ask HN: What should an ideal developer interview process look like?

news.ycombinator.com

241–250 of 289 posts

Re: Ask HN: What should an ideal developer interview process look like?

#241
1) A test that tries to mimic what the developer would be doing in the actual job as closely as possible. This is what most interviewers fail at - they seek out stupid proxies like whiteboarding rather than simply trying to mimic real life.

2) > 45 min 3) Minimal setting up development environments, frameworks or test environments. No boilerplate should be required during the test.

4) The test is improved iteratively. Catch bugs during each interview process and fix them in subsequent interviews.

Re: Ask HN: What should an ideal developer interview process look like?

#242
I will answer short and complex technical questions but I will not do technical tests anymore. Managers who are too lazy or not technical enough to know my skill level based on a conversation with me are not the kinds of people I want to work for. I've worked for a lot of companies and the most successful ones didn't make me do any tests. There's definitely a correlation.

Re: Ask HN: What should an ideal developer interview process look like?

#243
post #92

Earlier quoted context omitted.

Senior people will be able to do the two hour coding homework in way less than two hours. If someone can't manage this as part of an interview process, it might be a sign of their time management abilities.

Senior does not mean you type faster. It means you don't do unnecessary work, you avoid pitfalls and traps you have seen before, you don't over-engineer but you keep it as simple as possible. It also means that you push back against non-constructive requests from business and management and focus your time and effort on what matters. I also avoid anyone who wants me to do a coding exercise for a few hours over the we…

A slightly extended thought

The main antagonism here is that the hiring company wants to minimise its effort in getting great devs, and the devs want to minimise their effort in getting great jobs.

The first point to note is that constant marketing is the first, best solution to this. I would definitely put more effort into joining a well-marketed company (StackOverflow?) than J.Random Inc. So both me and J.Random Inc had better put some effort into standing out from the crowd.

OSS is one seemingly good way to do this - and having a reasonable Github account is something I would say should get you through most interview filters (ie if you are looking for a Python dev, and they have commits to say a flask extension or bits of salt-stack, then you can blip over the Fizzbuzz and whiteboards.)

But marketing is simply a way to get past other people's filters. "Networking" is good, whatever that might mean, and being a good citizen works. but these are as always, long term, constant application efforts. And of course, costly.

Secondly get over the "we only hire the best of the best of the best". If that's true then like the SEALs you clearly have a six month training programme that takes the best and shapes them into effective teams, fully paid while they learn - yes? And the training staff for this programme are pulled off current fee-paying projects to keep up the standards yes? Otherwise your best-of-the-best is so much auto-trumpet blowing. So please leave that at home. Focus on process not heroes.

The interview by takehome project is a big problem.

Yes it clearly weeds out candidates - mostly by making the ones with options elsewhere go elsewhere. (Even Google, with its firehose of applicants, seemed to realise this was a dumb idea and instead used the MIT graduate program as a filter instead).

My main issue with interviews-by-homework is it is usually a hole-dig-and-fill session as the problem has been done by dozens of people before (often you can find their solutions on github). My time is then valued at less than zero. As a filter before we get to interview, it really is just an artifical hurdle. All you are saying is that "we have soooo much choice we can make you dance before talking to you" - if it works for you great. Your marketing is working (see above)

IMO a better approach is to find different existing properties that you can filter to get applicants to the interview.

Sometimes these are "Alpha Male" filters like 1st class honours at MIT. Other people on HN stand by different filters - I seem to remember someone saying one of their best hires had taught themselves coding whilst getting off drugs in a Glasgow slum. How you filter for that is harder than the MIT problem but I bet its a less tapped seam than MIT.

Overall, a good interview process is probably focusing on the wrong end of the problem. If you have a new open position and then you start looking its too late. Be a good OSS citizen, be involved in the community of developers (OSS and elsewhere), find ways to reach out to unusual developers, or people not marketing themselves, and keep the process going constantly, with suitable investment. The general Big Co idea of "you cannot put out job ads before you have a signed off budget and position" tends to make this a problem. A solution would be to take the expected Agency percentages for each new hire (between 5-20%) and put it into a centralised "developer evangelist" team that just gets people through the door.

This way when you need to open a new position, you will have four people in mind you already want to hire, and you can just go to Starbucks for an interview.

Re: Ask HN: What should an ideal developer interview process look like?

#244

After getting burned a few times too many, wasting days of work building entire applications (at worst) or even simply a few hours (at best), I won't be doing anything longer than a 20-30 minute fizzbuzz take home exercise. I will also never waste a day of leave on a company, unless it's the opportunity of a lifetime and I feel I have an almost guaranteed job offer if I jump through that hoop. My ideal interview proc…

What’s your rate?

Are you trying to find out how that sort of attitude correlates with pay?

I make what Glassdoor tells me is an average salary for my area and seniority, but I believe I could do better if I could muster up the courage to interview heavily and change jobs.

Re: Ask HN: What should an ideal developer interview process look like?

#245

1) A test that tries to mimic what the developer would be doing in the actual job as closely as possible. This is what most interviewers fail at - they seek out stupid proxies like whiteboarding rather than simply trying to mimic real life. 2) > 45 min 3) Minimal setting up development environments, frameworks or test environments. No boilerplate should be required during the test. 4) The test is improved iteratively…

> Exercises that try to mimic what the developer would be doing in the actual job as closely as possible. This one is critical.

(the following is just inspired by your bullet)

The job of a developer consists of problem solving something they have never encountered before (under some pressure), communicating to other developers, and demonstrating knowledge in various combinations and amounts over time. Startup developers are the hardest spots to fill and most delicate, so I tend to always think as if I'm hiring for a startup.

Talking through a few whiteboard problems and talking about tools they have used (why and how) are sufficient. 30-45 minutes. I don't subscribe to adding more elements (environments, tools, test frameworks, etc). 3 people, 1 from the destination team, 1 from another team (if possible) and the immediate manager.

Startups to multinational corporations, I'm still convinced this is the best way over the last 20 years.

Interviews with higher management is just a redundant filter and another reason for the management to justify their existence. It's a job smell that every company has and is obviously prejudicial in every regard (trying to tease personal details or redundant workflow experience and opinions). It's a bad practice.

Re: Ask HN: What should an ideal developer interview process look like?

#246
post #72

I'll tell you what really improved our successrate. We implemented a small IQ test and a small relevant coding challenge. Failure in one of these got you disqualified immediately. We started weeding out sub-optimal candidates real quick and were able to focus on the star talent.

I believe your process is on treacherous legal grounds in the United States, at least if you literally conduct an IQ test with a score and a cut-off value. See this article for some amount of information: https://www.hiresuccess.com/resources/guide-to-employment-te...

We're based in the Nordics and there's no conflict here. But if there was I would just change the test enough to scrape by. Its wildly beneficial and the best predictor of future success known to man.

Re: Ask HN: What should an ideal developer interview process look like?

#247
post #237
post #232

Earlier quoted context omitted.

I don't know if people are getting hung up on the term "full day" but I'm not sure I've ever heard of people being hired for senior (or even not so senior) professional roles without having multiple in-person interviews. I suppose there are distributed companies that just do things over video link these days (and I've interviewed people over a video link when necessitated by travel schedules or people being in differ…

I'm a freelancer, so that's a bit different, but I admit I'm surprised at how brief and superficial the intake to hire me usually is. For permanent jobs, it's usually an hour long interview followed by a programming assessment; either take-home and then presenting to their developers, or codility. But for freelance work, none of that. Just a talk and they hire me. But of course if I turn out to be useless, a freelanc…

Video interviews are definitely less good than in-person from my perspective. But between the fact that the teams asking me to interview candidates are pretty distributed and have people who travel a lot as I do, it's pretty hard to get all the "right" people into an office on the same day.

As for hiring freelancers, I'm not involved in hiring programmers but we use external people for various other things. We've try to use people we have experience with but it's mostly not a big deal. If we don't like the work they do, maybe we're out a few bucks but we just don't hire them again.

Re: Ask HN: What should an ideal developer interview process look like?

#248

Earlier quoted context omitted.

Wait, what is the difference between taking the time for an interview (no matter if via phone or in-person) and one for a gate-filter task?

In theory there shouldn’t be any, assuming it’s limited to an hour, both in description and in reality. In practice there’s a pervasive phenomenon called asymmetry of effort. The hiring manager may crib a task set either from a perfunctory google search or their own body part. The sum total of time spent on their part is often five minutes, including coming up with the problem and their review of your code. This foll…

Seems like you have a problem with the implementation of the idea, not the idea itself.

At my current employer, our recruiting manager has a preliminary talk with the candidate and if there seems to be mutual interest in continuing in the process, she sends a simple task. The task was defined by the technical team, it should be short (no more than an hour) and it has nothing to do with our work.

Once she receives the submitted task, we ask everyone in the tech team to make a review. We do have a "gold standard implementation", but we know that no one will get it and we don't care. We had cases of candidates that misunderstood the task and we had no issue with giving them a second chance or simply asking what was unclear and what would they do differently had they had got the intended requirements.

We just want to filter the obvious "no hires" from the ones with potential. The recruiting manager communicates this even before the task is submitted to them. I am yet to hear any story of any candidate that was interested in the position but walked away due to the way that the process is conducted.

Re: Ask HN: What should an ideal developer interview process look like?

#249
post #238

Earlier quoted context omitted.

That's only at a later stage when you get an interview - with a company that looks good. Coding tests are just an early stage filter for experienced people - so those companies get dropped early on.

I have the exact opposite opinion: a coding test is for a candidate you already want to hire and introduce to your development team, to have a look at their coding style. You don't want to get your developers together for any random loser who'd never want in your team anyway. So the coding is a late stage filter. At least for me it's always been.

But if experienced candidates go "meh" life's to short you might have missed a better candidate.

And Martin any professional should adapt to the systems in place - and I wouldn't use terms like "random luser" might have some blowback.

Re: Ask HN: What should an ideal developer interview process look like?

#250

Earlier quoted context omitted.

In theory there shouldn’t be any, assuming it’s limited to an hour, both in description and in reality. In practice there’s a pervasive phenomenon called asymmetry of effort. The hiring manager may crib a task set either from a perfunctory google search or their own body part. The sum total of time spent on their part is often five minutes, including coming up with the problem and their review of your code. This foll…

Or when they ask a seriously difficult np hard problem (probably looking for an algorithmic solution to their real world problem) and never reply whatsoever when you send them a solution for a slightly simplified version.

I am big defender of take home tasks as part of the interview process, but if someone asks me some incredibly hard problem to be solved or anything that seems like could be part of their actual work, I would ask compensation for the time. Take home tasks are not supposed to be real work...
Post reply on HN