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

31–40 of 289 posts

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

#31

Post by asark »

lazerwalker wrote: post #15
rococode wrote: post #5

I've often thought about this, and based on my own experiences this is the process I would like: 1. Test language-specific knowledge - it's not a bad thing to not know all the small quirks or details of a language since they're generally not too useful, but when someone does know them it tends to be a good sign that they really enjoy coding and learning. And of course there is a certain minimum amount of knowledge th…

The only thing I'd caution (particularly about #1) is that being able to parrot facts — even ones you know cold — on-demand in a high-intensity interview setting can be very different from using those same facts day-to-day. If someone can't describe the difference between abstract classes and interfaces, how confident are you it's because they don't understand it and not just because they're horrible at being put on…

Hell, I can barely "hello world" in languages I've been actively and productively writing for months or even years, without context (i.e. existing code) to draw on and/or tool assistance. I've got a better than 50% offer rate on interviews in an over 15 year long career but in one of the ones I flubbed I blanked on the syntax for invoking methods on an object in the language I knew best, at the time, and wrote some other (more common) invocation syntax instead, which can't have helped. Ask me JS scoping trivia and I guarantee I'll screw it up, despite having written JS and TS as my main language(s) for 3ish years now. Look, I stick to a subset of that language precisely so that I can ignore that shit. We can just skip the interview and go straight to the rejection if you're gonna do that. Doubly so if you don't tell me you're gonna do that so I can drill on it before hand.

Coworker and manager feedback, and my compensation over the years, say I'm pretty damn good at adding value despite this. I've been considered the "smart one" and the go-to guy for hard or weird problems. But I will struggle to produce something that will even come close to compiling on your whiteboard, in a language I wrote 300 useful lines of yesterday, unless I spend a couple days basically flash-card drilling for your test. Go figure.

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

#32

Post by nostrebored »

lazerwalker wrote: post #15
rococode wrote: post #5

I've often thought about this, and based on my own experiences this is the process I would like: 1. Test language-specific knowledge - it's not a bad thing to not know all the small quirks or details of a language since they're generally not too useful, but when someone does know them it tends to be a good sign that they really enjoy coding and learning. And of course there is a certain minimum amount of knowledge th…

The only thing I'd caution (particularly about #1) is that being able to parrot facts — even ones you know cold — on-demand in a high-intensity interview setting can be very different from using those same facts day-to-day. If someone can't describe the difference between abstract classes and interfaces, how confident are you it's because they don't understand it and not just because they're horrible at being put on…

Not being able to describe the difference between abstract classes and interfaces is a huge red flag for anyone working in OO Software Development. You can't be serious?

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

#33

Post by alasdair_ »

gnarcoregrizz wrote: post #23
new299 wrote: post #10

Most interviews have asymmetric costs. There’s a potential payoff for both parties, but costs are higher for the interviewee (time off, prep, work done). I recommend trying to make the cost/benefit more symmetric. One way of doing this, is offering compensation for real work. Essentially, hire interviewees to do a small amount of useful (a day?) and evaluate them based on that. This isn’t going to work for all interv…

Not going to happen - I think the supply of software developers has started to outweigh the demand, so there's no way that companies are going to offer compensation to interviewees. If anything, the difficulty bar is just going to continue to go up. If there were a shortage there wouldn't be so many of these silly hoops to jump through. It's not really worth it to interview nowadays. Practicing leetcode for months, f…

>Not going to happen - I think the supply of software developers has started to outweigh the demand, so there's no way that companies are going to offer compensation to interviewees.

I was thinking the opposite - that no employed engineer is going to bother with a multi-day paid contract for a new position, so the only engineers you will attract are those without a job and no pending interviews.

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

#34

Post by jarsin »

passivepinetree wrote: post #25
lawnchair_larry wrote: post #20

No whiteboard code, no algorithms questions. If you want them to code, let them do it on their own time in a comfortable environment. The industry needs to stop the bullshit leetcode meme that millenials are propagating.

I’m a little confused — can you explain how this is a generation’s fault? It certainly seems that millennials are subjugated to this type of process, and it’s possible that millennials are the ones giving these types of interviews more often than not, but as far as I can tell these interviews propagated because large, well-regarded, highly successful companies (Google etc.) started performing them and then smaller co…

Ya like millennials can leetcode. They can't even tie their shoes without complaining on facebook.

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

#35

Post by lawnchair_larry »

mav3rick wrote: post #11
rococode wrote: post #5

I've often thought about this, and based on my own experiences this is the process I would like: 1. Test language-specific knowledge - it's not a bad thing to not know all the small quirks or details of a language since they're generally not too useful, but when someone does know them it tends to be a good sign that they really enjoy coding and learning. And of course there is a certain minimum amount of knowledge th…

Language quirks are the worst thing to ask in an interview. Please don't do it, it's barely a step above memorization.

I think it depends how you do it. When I interview, part of what I do is try to find quirks that they know about, but not count the ones they don’t know about against them.

I think you can quickly get a sense of depth, potential, curiosity, and passion if you can get them talking about quirks and their opinions on those quirks.

For example, if someone says that they once attached a debugger to the JVM to confirm a pathological issue arising from benign looking Java code and found that the JIT compiler falls apart when a certain construct is used, I’m probably going to hire that person, even if we have no Java code in the company - assuming I can also confirm that they are productive and don’t just waste time going down deep rabbit holes.

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

#36

Post by l0b0 »

I would give them opportunities to show their skills at real-world tasks:

- Version control. Given a terminal (or Explorer with TortoiseSomething) and an existing project, make some simple changes and commit.

- Testing. Given a simple piece of code, its tests and either a bug report or feature request, explain at least in high level terms how to move forward.

- Code review. Give constructive feedback on how to improve any aspect of a diff.

These tasks indicate an understanding of code and facility with communication beyond the very basics, and you'll never finish learning them, so I believe they are appropriate for any non-entry level position. They are also sufficiently open ended that the candidate has to prioritize getting at least something done on all of them.

After that, unless they are completely hopeless I'd arrange coffee or lunch (on company money of course) with at least part of the team they'd be working with, so they can tell if they are at all compatible.

Needless to say, give the candidate plenty of options for a suitable time, let them know exactly how long it'll take, coordinate the time with the team, show up on time with a computer—which the admin team has wiped and you've just had to copy a few files onto—and find somewhere quiet and comfortable for them to work.

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

#37

Post by 11thEarlOfMar »

Puer wrote: post #13

My most enjoyable interview was for an internship in college. I had a take home coding challenge where I had to write some simple code to fetch information from an API using whatever language I liked. I was given a week to do it, but it only took me an hour or so to meet all of their explicit requirements. I liked that there was no time pressure in that regard. After the week was up I went into the onsite and in the…

This is exactly how we do it at my company. The first interview is mainly for the candidate to get to know the company, products, tech. If we think there is a fit, we send them home with a coding task, choose 1 of 5, not expecting more than 100 lines of code, or more than a couple of hours (though all candidates have submitted more and spent more time). There is no time expectation, but they usually finish in a week or less.

They then come back for a code review, walk the team through their code and explain it. This tells us a lot about their ability, but also their communication style and clarity, how they approach problem solving in general and even in which problem they chose.

I chose this approach because 'coding under duress' during an interview does not offer a valid sample of what the candidate can do. Taking the time they need and working in a comfortable environment will give a much more realistic result. Coupling the take-home with an in-person code review weeds out those who may just Google up or borrow code from elsewhere.

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

#38

Post by wonderwonder »

camjohnson26 wrote: post #22
eli wrote: post #14

Earlier quoted context omitted.

I've considered this approach, but I worry that it consumes too much of the candidate's time. That it ends up favoring people who have the time and the financial freedom to do a full day of unpaid work.

I have been interviewing recently and started turning down any coding assignment that will take more than a couple of hours. To get a reasonable number of offers to enable you to negotiate requires going through the interview process for several companies since some percentage of them will turn you down. After a phone screen I don’t have enough information about the role to be able to potentially waste 10-20 hours on…

Negotiating a salary is a situation I have never been in as I have always told them up front before interviewing how much I want to get paid after finding out the salary range. Whenever a recruiter calls, I ask the salary first and tell them where I want to be on that range before even sending a recent resume. Not that negotiating for more if I have several offers would not be great, just not something I have experienced. I interview, they already know my number as I have already asked the hiring salary range and told them what I want. If I pass the interview they offer me my original request and we move forward. I could see how if one was interviewing with multiple companies and had multiple offers how one could seek to play them against one another for a potentially higher amount. Just hasn't happened to me.

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

#39

Post by the_jeremy »

dragonwriter wrote: post #26
camjohnson26 wrote: post #22

Earlier quoted context omitted.

I have been interviewing recently and started turning down any coding assignment that will take more than a couple of hours. To get a reasonable number of offers to enable you to negotiate requires going through the interview process for several companies since some percentage of them will turn you down. After a phone screen I don’t have enough information about the role to be able to potentially waste 10-20 hours on…

> To get a reasonable number of offers to enable you to negotiate You only need 1 offer to negotiate.

While technically correct, I think most people agree that it is better to field several offers simultaneously so you can choose the best culture fit for yourself as well as being able to provide a concrete example of someone offering you a higher salary to most easily justify your counter-offer.
Post reply on HN