Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

181–190 of 289 posts

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

#181

Post by conbandit »

Etheryte wrote: post #129
james_s_tayler wrote: post #110

An interview is designed to answer three questions. 1) can you write software? 2) can we tolerate writing software with you? 3) can you tolerate writing our software?

This is a great brief summary. Currently, most interviews put very heavy emphasis on 1, slightly touch 2 and often forget 3 altogether.

I think the idea about skipping 3 is that the applicant is choosing to apply to a particular company. That's implicitly saying that they're willing to work on that company's code. I don't know how valid this is nowadays with the common practice of throwing applications at the wall and seeing what sticks.

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

#182

Post by gortok »

raygelogic wrote: post #168
PurpleBoxDragon wrote: post #155

Earlier quoted context omitted.

If the project only takes an hour for a junior it shouldn't be a problem. I would be worried that their senior position problems might not be as quick to solve (which is similar to the real world), but then this interview technique might just be best for junior positions and they do something different for senior positions given the different in skill sets and what problems they are expected to solve.

this comment misses the point and is why we don't give take-home work to senior developer candidates. they are in high demand and will not spend their free time on homework, when many other companies will gladly hire them without making them jump through hoops.

I only see two possibilities:

1. Require developers to code on demand during an interview (personally, I have a hard time with this; the pressure of an interview is not a normal working situation).

2. Allow someone to do it on their own time, under no time pressure. (I advocate paying them for their time at a fair market rate).

Do you see another way of a senior developer demonstrating their abilities without hitting either of the two above?

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

#183

Post by zimpenfish »

ldite wrote: post #169
scarejunba wrote: post #153

Earlier quoted context omitted.

Interesting. Would you mind sharing in which country you work (or if America, which state), what your field of interest is, and how long you've been in the business? My team has full-day interviews and I'm curious to see who has been self-selecting out of this.

I'm the UK, 15-20 years experience, depending how you count it, and my skill-set is diverse :)

Same and I would point-blank refuse any full day interviews (unless they were going to pay my going contract rate, I suppose.)

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

#184

Post by scarejunba »

sandos wrote: post #178
scarejunba wrote: post #153

Earlier quoted context omitted.

Interesting. Would you mind sharing in which country you work (or if America, which state), what your field of interest is, and how long you've been in the business? My team has full-day interviews and I'm curious to see who has been self-selecting out of this.

Wow. I live in Sweden, and I have the same expectations: I would not really want to spend much time on an interview process, and I have never, ever heard of day-long interviews either! We have had a perpetual shortage of developers though, it sounds much harder to land a job in the US.

To clarify, full day means 4 sessions of an hour each bridged by lunch (1 hr). The hope is to give the candidate sufficient information about the team while the team gathers info about the candidate.

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

#185

Post by ghaff »

raygelogic wrote: post #168
PurpleBoxDragon wrote: post #155

Earlier quoted context omitted.

If the project only takes an hour for a junior it shouldn't be a problem. I would be worried that their senior position problems might not be as quick to solve (which is similar to the real world), but then this interview technique might just be best for junior positions and they do something different for senior positions given the different in skill sets and what problems they are expected to solve.

this comment misses the point and is why we don't give take-home work to senior developer candidates. they are in high demand and will not spend their free time on homework, when many other companies will gladly hire them without making them jump through hoops.

Furthermore, just because you can bang out something in an hour or two doesn't mean that you will spend only an hour or two when you know you'll be competing against people who put a lot of effort into the task.

In my case, I do a lot of writing these days and, if someone were to ask me to write a thousand word analysis on some topic I was familiar with, I certainly could knock that off in a few hours. But, assuming I agreed to do it at all as part of the interview process--I'd be far more inclined to just give them a bunch of links to my work--I'm going to put the effort in to come up with a tight, polished product.

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

#186

Post by inertiatic »

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 proccess thus is:

1) Talk to me for 30 minutes (not your HR, an engineer that is trained for this task). Fizzbuzz me if you have to, but preferably at this point in my career, don't. 2) One or two onsites that last a maximum of 2 hours and are early or late in the day, so that I don't have to waste a day of leave. Don't fizzbuzz me or ask me edge cases on your language of choice in this. Don't come with a checkbox of things you want to hear. Have a discussion with me and actually pay attention to the things I have to say that aren't strictly part of the answer to your question.

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

#187

Post by azangru »

weliketocode wrote: post #177

Many people here will disagree with what I'm about to say, but if you're going to give a coding challenge... I like hackerrank/codility style coding challenges. gasp They're timed. They're run against a standardized test suite. And they have support for many languages. It's really unfortunate the number of companies that give custom take home coding challenges that run the gamut. The problems with which are manifold:…

When we were looking for a developer for our team, we created a set of small coding challenges testing the candidate's knowledge of the most relevant aspects of the language. We wrote automated tests for these challenges, and the main bulk of our interview was having the candidate solve them.

The advantages to that approach, as I see it, are:

- the developer is tested for knowledge that is most relevant for their current job (as opposed to writing general-purpose algorithms)

- the developer is showing their familiarity with a testing environment

- writing working code in a code editor seems to me more practical than writing (pseudo)code on paper or on a whiteboard

There are, of course, disadvantages to this approach as well. The developer may have hard time working on an unfamiliar machine and not in their favorite code editor (though what we had was quite standard). This might be a tad stressful (although I don't know how this compares with solving a general coding problem on a whiteboard, or with a task asking you to think not just of a way to solve a problem, but of a performant way too). And it made us focus on the candidate's coding skills too much (which some hiring managers might find objectionable).

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

#188

Post by sandoze »

Don’t wait for the candidate to show up and then start a conversation about an algorithm (or technology or mathematics) that they may not be familiar with haven’t used in some time. Offer of some topics for discussion before the interview (e.g. Quadtrees, tries, infinity) that they can study, or read a white paper about and have some increasingly in-depth questions, applications and conversations about one or more of these topics.

No one is ever expected to solve an unfamiliar problem in a 60 minute meeting. Generally a story/feature with technological unknowns are pointed for several days and are in the developers current wheel house, yet we expect a candidate to use most of their energy and facilities in a social situation with people they’re unfamiliar with and solve whatever random algorithm, riddle or puzzle that you Googled the answer to before the interview.

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

#189

Post by mcv »

weliketocode wrote: post #177

Many people here will disagree with what I'm about to say, but if you're going to give a coding challenge... I like hackerrank/codility style coding challenges. gasp They're timed. They're run against a standardized test suite. And they have support for many languages. It's really unfortunate the number of companies that give custom take home coding challenges that run the gamut. The problems with which are manifold:…

I recently did some codility tests, and they were totally fine.

I'm also fine with take-home challenges, though. But you're absolutely right that they're often vastly underestimated, and you shouldn't give someone a take-home assignment when there's only a small change they'll get hired. It should only be done once you're sure you want to hire this candidate if they're as good as they seem to be. A take-home assignment is too big to sift the chaff from the wheat in a large group of candidates. But once you're sure you'll hire them if they do well on it, a take-home test is totally fine.

Though such a take-home programming assignment should also involve presenting the result to a group of developers to explain their choices. If you're not willing to commit to that, you can't expect them to commit to putting in the time to do the assignment.

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

#190

Post by ummonk »

weliketocode wrote: post #177

Many people here will disagree with what I'm about to say, but if you're going to give a coding challenge... I like hackerrank/codility style coding challenges. gasp They're timed. They're run against a standardized test suite. And they have support for many languages. It's really unfortunate the number of companies that give custom take home coding challenges that run the gamut. The problems with which are manifold:…

Yeah, those challenges are explicitly timeboxed, and I know there is a relatively objective grading criteria (which is often as simple as “passes enough of the hidden test cases”).

I refuse to do other types of take home challenges, but am fine with these.

Post reply on HN