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

21–30 of 289 posts

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

#21

Post by automatoney »

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…

I would love to be interviewed like this. Even though the candidate does end up spending time doing work outside of work, they'd end up doing that anyway if prepping for an algorithms interview. At least with an assignment you can be finished instead of doing endless leetcode prep. Plus it gives you a chance to practice relevant software engineering skills in a different environment.

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

#22

Post by camjohnson26 »

eli wrote: post #14
wonderwonder wrote: post #12

In my current role I had what I consider the best interview I have had to date. I had a brief non technical video interview with the software director. Then I was assigned a programming task, essentially to create a site focused on a specific task using a given set of technologies. Once done, I sent the interviewer the url to the site and a link to the code on git. The next day I had a code review and video interview…

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 a toy problem.

A few companies gave a simple api project or a timed hacker rank and those feel reasonable. An entire web app with database, rest api, front end and CI pipeline following production code best practices does not.

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

#23

Post by gnarcoregrizz »

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, flying, doing all day onsites, when all the company has to do is interview you for a few hours.

We've been issuing take-homes lately, and we ask that candidates spend no more than 3 hours on them. Well, it turns out almost no one spends only 4 hours on them... The most recent candidate we interviewed spent about 3 days on theirs judging from the commit logs. It was a fully fleshed out application with unit tests and everything. After all that they still have to pass the all day on-site, lol. Anyway I spend all of 2 minutes looking at each submission

I really wish there were a better signal.

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

#24

Post by marcell »

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.

That’s not true. If you have ten years experience with Python, but don’t know about, say, @property decorators or how variable scoping works, that raises some red flags.

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

#25

Post by passivepinetree »

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 companies just copied their formula. I’m not quite sure where the generational connection is.

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

#26

Post by dragonwriter »

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…

> To get a reasonable number of offers to enable you to negotiate

You only need 1 offer to negotiate.

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

#27

Post by camjohnson26 »

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.

On the other hand if a candidate has been coding a language for a long time and doesn’t know the quirks that could be a red flag

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

#28

Post by sifoobar »

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…

My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans.

I don't do challenges any more, life is too short to waste solving problems that don't exist for someone else without getting paid.

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

#29

Post by badlucklottery »

mbesto wrote: post #17

The ideal process is having one that actually exists. Most startups basically try to wing this without any definition of how they want the interview process to work. IMHO this is about 50% of the problem. On the flip side, large companies appear to be overburdened by process (anecdote example - I've heard from several people that getting into Google takes 6 months on average, along with the notorious b-tree whiteboar…

>that getting into Google takes 6 months on average

I can only speak to my relatively recent experience, but it was <5 weeks from application to offer for me. No idea if that's typical.

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

#30

Post by lawnchair_larry »

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…

For #3, it’s not really a red flag. I am guessing you are a fairly recent grad?

Most people who learn algos & DS never have to implement them on the job, and often haven’t actually written their own since their CS classes. If the question is any deeper than “what are some good and bad choices of algorithms for this problem”, you’re selecting more for who has just graduated or has been grinding leetcode and doesn’t have performance anxiety than you are for competence, expertise, and productivity.

I know folks who got rejected from the leetcode companies and went on to build major products from scratch. The 0.5% of work that requires them to have to implement something like this manually, they’ll just grab their CLRS book and refresh their memory long enough to solve the problem and probably forget it again a week later.

I also know folks at these companies who started fresh out of college, passed that style of interview, worked there for 7-10 years, moved up to senior or higher in the engineering track, and openly admit that they would be a deer in the headlights if they got any of the interview questions. Without going back to study and practice those, they know wouldn’t pass an interview for a junior dev, let alone one for their current job (where they are currently considered high performers).

The big problem is that this style of interview filters for people who pass this style of interview, and then those new hires are asked to interview others, so they interviewed in the style that they were given and passed.

Post reply on HN