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…
Ask HN: What should an ideal developer interview process look like?
71–80 of 289 posts
Re: Ask HN: What should an ideal developer interview process look like?
#72Re: Ask HN: What should an ideal developer interview process look like?
#73I'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.
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?
#74My 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…
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?
#75My 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 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?
#76My 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.
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?
#77Earlier 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?
Re: Ask HN: What should an ideal developer interview process look like?
#78Coding: 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?
#79Earlier 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.
Re: Ask HN: What should an ideal developer interview process look like?
#80Of 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.