Ask HN: What should an ideal developer interview process look like? • Hacker News Board

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

#281

Post by erkanerol » Tue, Dec 04, 2018, 9:17 PM UTC

I read many of the comments. There are lots of good suggestions. I believe these skills should be checked as well.

- to be able to explain something (whatever the candidate knows) by drawing boxes+arrows on white board

- to be able to write short and clear messages especially emails in corporates

- to be able to learn something new in a limited time

- to be able to document something clearly

- to be able to hack arhitecture/framework/existing mechanisms when necessary

- to be able to design something so that it will require minimum hack in the future (similar to O of SOLID)

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

#282

Post by Hansi » Tue, Dec 04, 2018, 9:21 PM UTC

ldite wrote: post #85

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…

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.

Might be location specific but out of 300+ candidates for 15 positions mid to senior level over 8 years in London recruited using this technique I've only ever had one person turn it down. We ask for fairly simpler requirements and for people to limit themselves to 4-6 hours over the course of a week with a focus on comments and recording their thoughts in a readme to suggest how they'd scale things if it was a real project. We don't really bother with many technical questions outside of the project anymore. It really is the single most important thing to get a glimpse into a persons ability to deliver, let them code at their own time in a setting they are comfortable with and then do a peer review with them on location and discuss the implementation and potential enhancements. The rest after that is generally just team fit and culture alignment checks.

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

#283

Post by ldite » Tue, Dec 04, 2018, 9:30 PM UTC

Hansi wrote: post #282

ldite wrote: post #85

Earlier quoted context omitted.

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.

Might be location specific but out of 300+ candidates for 15 positions mid to senior level over 8 years in London recruited using this technique I've only ever had one person turn it down. We ask for fairly simpler requirements and for people to limit themselves to 4-6 hours over the course of a week with a focus on comments and recording their thoughts in a readme to suggest how they'd scale things if it was a real…

I don't turn them down - bridge burning is for pyromaniacs - I just make non-committal noises and don't usually get back to them.

I should clarify that I was thinking more of outfits that respond to my enquiry with "Hi $candidate, please do this generic exercise after which we'll deign to look at your CV". Bonus points awarded/deducted if the requested exercise is for something already available on my github profile.

And 4-6 hours is typically my free time (not free computer time, total free time) for a week.

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

#284

Post by mcv » Tue, Dec 04, 2018, 11:29 PM UTC

C1sc0cat wrote: post #276

mcv wrote: post #271

Earlier quoted context omitted.

I guess it's also an issue of what you want. Are you fine with just any job, or do you want something specific, or something challenging? Do you want to be the smartest person in the room or do you want competent co-workers? In my experience, these sort of tests do often seem to be used by the more interesting, more competent kind of companies. The first company where I encountered this (14 years ago), had only highl…

Really? do CERN, JPL NASA the various "interesting TLAs" do this for non New grads. I certainly didn't get asked coding Questions when I went to BHRA (ranked 1 or 2 in its field) research organisation. I was told in my first week "oh there is a book on Fortran in the library" teach yourself it

Yes, really. This is exactly my experience. I don't know whether CERN, JPL or NASA do this; they are not part of my experience.

But it's very likely different for research institutes. I'm talking about companies.

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

#285

Post by flukus » Wed, Dec 05, 2018, 3:35 AM UTC

maccard wrote: post #272

flukus wrote: post #266

Earlier quoted context omitted.

> I type in "git", and I get: "usage: git" - If you're used to using shell tools, then sure you can make sense of it, If you're not, then you're done. That's part of the test, to see if they're familiar with the command line and if they know how to open the man page. It's trying to weed out the people that can only work in the confines of an IDE and gui tools. That said I wouldn't expect anyone to know git from the m…

> That's part of the test, to see if they're familiar with the command line and if they know how to open the man page. That doesn't tell you anything about how good a programmer they are. I don't need to use a command line or man pages for 99.999% of my work, so I'm not going to waste time learning to use more tools. > It's trying to weed out the people that can only work in the confines of an IDE and gui tools Ah, s…

> That doesn't tell you anything about how good a programmer they are. I don't need to use a command line or man pages for 99.999% of my work, so I'm not going to waste time learning to use more tools.

I don't want to offend but you sound like exactly the type of developer I try to filter out. IME there is a large correlation between at least rudimentary command line proficiency and being a good developer. Aside from that I want someone to know about the world outside of the IDE and what options are available, because a unix like environment offers far more power than an IDE.

I expect developers should be able to automate common tasks, work with build tools, grep through logs, remote into servers, debug on servers without an IDE installed and a million other things that are very common.

Maybe this doesn't apply to your specific industry but it does to everyone I've worked in to varying degrees. Not memorizing git I could forgive if you could explain branching workflows, but living life in the IDE I wouldn't.

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

#286

Post by C1sc0cat » Wed, Dec 05, 2018, 4:25 PM UTC

mcv wrote: post #284

C1sc0cat wrote: post #276

Earlier quoted context omitted.

Really? do CERN, JPL NASA the various "interesting TLAs" do this for non New grads. I certainly didn't get asked coding Questions when I went to BHRA (ranked 1 or 2 in its field) research organisation. I was told in my first week "oh there is a book on Fortran in the library" teach yourself it

Yes, really. This is exactly my experience. I don't know whether CERN, JPL or NASA do this; they are not part of my experience. But it's very likely different for research institutes. I'm talking about companies.

That's where you go for challenging jobs and unfortunately shit pay.

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

#287

Post by rglullis » Wed, Dec 05, 2018, 4:26 PM UTC

mchannon wrote: post #273

rglullis wrote: post #248

Earlier quoted context omitted.

Seems like you have a problem with the implementation of the idea, not the idea itself. At my current employer, our recruiting manager has a preliminary talk with the candidate and if there seems to be mutual interest in continuing in the process, she sends a simple task. The task was defined by the technical team , it should be short (no more than an hour) and it has nothing to do with our work. Once she receives th…

> I am yet to hear any story of any candidate that was interested in the position but walked away due to the way that the process is conducted. Thank you for making my point. Why would you ever hear about it? This is the "British Rails" fallacy in action. (A long time ago, the British Rail organization had heard complaints that residents of a local community weren't satisfied with the once-daily train service it rece…

> Thank you for making my point. Why would you ever hear about it?

Seems like the one that does not want to listen is you.

The take home task is only communicated during the preliminary interview with the recruiter (i.e, it is not something that is required to start the application process) and we do get feedback from candidates that have withdrawn their application. And while we had cases of people that withdrawn for various reasons (company size/culture, process adopted, being too "startupy" for a German company, or even simply getting a better offer somewhere else) the take-home task is yet to be mentioned as an issue.

In the end, your reasons for being against take-home tasks are not really against the idea of take-home tasks, just some of the implementations you've been through. Your "point" does not stand.

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

#288

Post by lifeisstillgood » Sat, Dec 08, 2018, 10:14 AM UTC

lifeisstillgood wrote: post #243

lifeisstillgood wrote: post #95

Earlier quoted context omitted.

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…

A slightly extended thought The main antagonism here is that the hiring company wants to minimise its effort in getting great devs, and the devs want to minimise their effort in getting great jobs. The first point to note is that constant marketing is the first, best solution to this. I would definitely put more effort into joining a well-marketed company (StackOverflow?) than J.Random Inc. So both me and J.Random In…

An extra point - senior means FU money. Often people have degree of authority and sway with others in authority - often by right of tenure, organisational position and friendships.

But coming fresh and new into a company, it's hard to just have your opinion or taste taken seriously - especially where that opinion will be unpopular (ie your code base needs rewriting from scratch)

So FU money is needed to avoid the tendency "just to go along with it for a bit"

Hire rich people is hardly a great line, but it will have benefits.

Hiring desperate people with no other options does not sound like you are winning of course

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

#289

Post by timv » Mon, Dec 10, 2018, 10:17 AM UTC

ghaff wrote: post #232

elbrian wrote: post #167

Earlier quoted context omitted.

>My team has full-day interviews and I'm curious to see who has been self-selecting out of this. Anyone with any level of self-confidence, worth and respect.

I don't know if people are getting hung up on the term "full day" but I'm not sure I've ever heard of people being hired for senior (or even not so senior) professional roles without having multiple in-person interviews. I suppose there are distributed companies that just do things over video link these days (and I've interviewed people over a video link when necessitated by travel schedules or people being in differ…

"Full day" absolutely matters though, especially if you want to attract passive candidates.

If I'm unemployed, then full day is fine. If I'm really keen to get out of my current job, or really keen to work for you, then I might do it. But if I'm just exploring opportunities, or I have other options in progress, then I'm not taking a day off just to interview.

With any interview when it might be really obvious 10 minutes in that it's not going to work. If I've scheduled that during my lunch break, or for an hour before/after work, then that's a small cost.

If I take a day off work to interview, then that's costing me in the order of $1000. If I don't know whether I want to work for you, then why would I do it? And I definitely can't do that for 5-10 different roles that I might apply for.

A full day is also quite hard work. Interviews are stressful. Dealing with people you don't know, trying to make sure you don't do/say something stupid, it gets exhausting.

I generally expect 4-6 hours worth of interviews before an offer, but the typical process stretches those over a few weeks, which allows the candidate to fit them into available blocks of free time, and gives the candidate oppotunities to think about how things went, what questions to ask, whether this seems like the right fit, and pull out at any point.