Live data from Hacker News

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

news.ycombinator.com

151–160 of 289 posts

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

#151
post #71
post #36

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 improv…

Is the candidate pool really so poor that you actually need to test that are they able to perform these basic tasks?

Yes. It is awful out there from a hiring manager's perspective

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

#152
My favorite coding interview ever is still from many years ago when I interviewed at Pivotal labs.

It was an in person pair programming session, with the interviewer driving.

Most importantly, it was collaborative, whereas many interviews often feel adversarial.

It also tested how you communicate, since you weren't the one typing.

However, it still tested your coding skills, but because the interviewer was "on your side" with respect to the desired output code, it wasn't a dealbreaker or stressful situation if you forgot the signature of an important method or function.

But it also touched on actual coding skills, while not requiring you

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

#153
post #121

Earlier quoted context omitted.

> With this approach you'll miss good senior people Aren't you already spending many hours researching a job as the part of the process? Aren't you already taking a full day off work for the interviews? Why is that time all fine to spend, but not fine to spend a couple of hours on doing an assignment?

Not really. I've never needed to research a job beyond a bit of Linkedin/glassdoor stalking and reading of corporate guff. I've never had a full day interview for a company I'd actually want to work for (based on what I've learned while grinding through the interviews) so I'm beginning to take requests for those (along with requests for advance coding exercises) as a recruiting smell.

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.

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

#154

I find the move to take home tests extremely unfair. Anyone with dependents will typically need to block out most of a day of a weekend, or risk doing it in intervals through their week. Got a decent CV? Good luck trying to juggle applying for more than 2 interesting opportunities at once. We mostly hire full stack web devs. IMO It's impossible to really test the abilities of each candidate across the changing landsc…

I’m never dropping the Fizzbuzz style problem. It has absolutely blown me away the number of people who market themselves as senior people who can’t perform the most simple or basic coding tasks. No fancy algorithms. No obscure data structures. Just simple loops and conditionals in any language. It has been the most effective (and most depressing tool) I’ve seen in eliminating the myriad of fakers and unqualified peo…

In the dozens of interviews I have conducted so far, I have run into exactly one person who fit this description.

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

#155
post #85
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…

With this approach you'll miss good senior people; I have dependants and very little free time outside work. Last time I was looking for a job I skipped everyone who wanted me to do prep/homework. If the other interviews hadn't worked out I'd have gone back to them, but I didn't need to.

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.

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

#156

I find the move to take home tests extremely unfair. Anyone with dependents will typically need to block out most of a day of a weekend, or risk doing it in intervals through their week. Got a decent CV? Good luck trying to juggle applying for more than 2 interesting opportunities at once. We mostly hire full stack web devs. IMO It's impossible to really test the abilities of each candidate across the changing landsc…

I’m never dropping the Fizzbuzz style problem. It has absolutely blown me away the number of people who market themselves as senior people who can’t perform the most simple or basic coding tasks. No fancy algorithms. No obscure data structures. Just simple loops and conditionals in any language. It has been the most effective (and most depressing tool) I’ve seen in eliminating the myriad of fakers and unqualified peo…

I think it’s more that people get really nervous in interviews. And they’re trying to use the social part of their brain and the coding part at the same time. It’s not normal.

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

#157

Earlier quoted context omitted.

So what interview process tasks are acceptable to you in order to gauge your ability?

Resume review, Phone screen (30 min), on-site (less than 2 hours), probationary period. Everything else is simply busy work for all parties because it doesn’t tell you anything you don’t already know, plus it scares away quality candidates.

Hmm, interesting. I don't know if it's legal for me to run different interview tracks for immigrant and domestic workers. If I'm hiring away an H-1B from somewhere else, probationary isn't going to work. They will not join since their residency depends on employment. But it appears that some domestic engineers prefer the shorter test series with a bigger opportunity to prove themselves.

Does anyone know if having different tracks is legal?

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

#158
post #86

Earlier quoted context omitted.

> Version control. Given a terminal (or Explorer with TortoiseSomething) and an existing project, make some simple changes and commit. Does this really tell you anything about a candidate? If you sat me down in front of a terminal and said "here's a git shell, make a change and commit it" I'd fail the test immediately. I've used perforce for the last 9 years, and the terms are not the same, and the commands are _not_…

I also balked at it, but for the opposite reason. Everyone should be able to sit down to a terminal, make a change to a repository, and commit it. I mean even if you don't know the command (or they are using a different version control system then you are used to) you can always check the help or man page. It's still a trivial task.

I've encountered people who didn't know the concept of a man page exists, or that -h / -? / --help is a semi-standard construct.

Yet they carried mid/senior-level titles.

You should absolutely test for the things that you think are annoyingly trivial if this person is to be a close peer or a direct report, because your level of disappointment will be so much greater after that person becomes an employee.

I define "annoyingly trivial" as the things that you feel everyone should know "at this stage", and you would be annoyed at having a conversation about said topic for more than 5 minutes.

My personal opinion is Git definitely falls into that category.

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

#159
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…

>you don't over-engineer but you keep it as simple as possible

It should also mean you don't under engineer, but that is extremely hard to test for because that involves knowing the business and your customers and having a reasonable estimate of where future needs will be. I'm not sure how you would test for lack of under engineering, especially since any interview task would be a perfect case where you practically can't under engineer since it is guaranteed throw away work. Maybe asking during code review for how you would've done the solution different if you knew that in the next quarter you would likely have to implement either feature A and B or C and D (but you didn't know which yet).

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

#160
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…

Contributions to a new OSS project that show significant programming ability are very time-intensive. Do you know anyone who has successfully implemented this scheme?

I could set up one of our OSS projects with first-contribution issues and help walk someone through but I suspect most people would rather not spend the time. If it takes 4 hours with back-and-forth in the PR (simply because I may be asleep when you commit and you when I comment) that's a big request of any person.

Post reply on HN