Live data from Hacker News

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

news.ycombinator.com

71–80 of 289 posts

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

#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?

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

#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.

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

#73
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...

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

#74
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 sounds exactly like one of the best interviews I had when I was searching for my first dev job, and I've tried to emulate it whenever I've been involved in hiring new people.

A good template is:

- Simple yet relevant take home coding test with a relaxed timeframe

- Technical portion of the interview where the candidate is asked to add a simple feature to their existing tech test.

- This is followed by a more general interview.

None of these sections should take more than 1-2 hours.

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

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

That's great to hear – my previous company did something pretty similar to this, except the onsite "technical" portion involved actually pairing with one of the team for an hour to add one of those features, then discussing that process with a second engineer to describe what we'd done together and why.

I generally think this works well for a few reasons:

1. The take-home task lets us see if candidates meet a minimum standard of competency and generally follows good practice – do they test the solution, document it, write clear… of course, I think it's important that the size of this task is limited to avoid wasting candidates' time.

2. The on-site interview helps to make sure the candidate is able to discuss the work they're doing, collaborate with other technical staff, and communicate technical ideas well.

It feels like the overall goal of an interview process is to ensure that the candidate is at the skill level they have communicated, and that they can work with others.

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

#76
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.

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

That excludes anyone with a no moonlighting agreement in their current contract, though.

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

#77

Earlier quoted context omitted.

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?

Only dipshits working on shitty OO projects care about the difference between an abstract class and an interface. Let me guess - you also think algorithmic complexity analysis is overrated.

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

#78
Respectful of my time. Think of dating - if after 3 dates, you still are not sure if you like somebody, maybe it is better to call it quits. I had companies call me in for more than 4 interviews, distributed over several days. Not respectful.

Coding: I actually like coding tests in interviews. Then I know my potential future colleagues will also have had a coding test. The company cares at least a little that my colleagues can code.

Just don't take the coding test too seriously. Don't expect me to write correct syntax on a whiteboard, for example. It should be more about having the right ideas, or even be able to discuss possible approaches if a solution isn't obvious immediately.

Also, make it a little challenging - no computing of Fibonacci numbers or FizzBuzz.

I liked one where I was asked to implement Quicksort (not that original, but OK), but they also gave me a definition of Quicksort along with it. That seemed fair.

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

#79

Earlier quoted context omitted.

So instead of giving you a 6 month trial run followed by employment they should give you a permanently temporary gig? Because a job where they hire and fire freely sounds a lot like how companies treat contractors.

That's already the way almost all jobs are. Being "hired" isn't a protection for your job. It just means you're getting automatic tax withholding. I was a formal full-time employee at NCC Group until just a month ago, when they fired me with no warning, no explanation, and no severance.

You can't fire people for no reason in the UK and probably the rest of Europe as well or you'll end up being taken to court for unfair dismissal. Roles can be made redundant, but it's a lengthy process.

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

#80
The interview should not focus on assessing basic competence, it should look at relevant experience and understanding of the business in question as well as communication and teamwork style.

Of course in order to get there would require a working certification system. Requiring candidates to write fizzbuzz in person over and over is a waste of your time and theirs, but it exists because nobody's managed to crack a "fizzbuzz certified" system that employers actually trust for this. The fraud pressure is quite high and nobody wants to pay for it if there is a possibility that someone might benefit - 1000 candidates applying to 100 employers results in a huge amount of waste, but requiring the candidates to pay for certification cuts out a lot of good candidates, and paying on their behalf and allowing someone else to use that result is seen as unacceptable.

Post reply on HN