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?

#41

Post by gpm » Mon, Dec 03, 2018, 5:40 AM UTC

Speed.

Obviously not a complete answer, but I think it's a component that isn't being mentioned here. Disclaiming that I don't have much experience (still in university).

One of my internships went from "applying -> interviewing -> accepting" in under 24 hours. Impressed the hell out of me. It was really the reason why I ended up accepting their job. 24 hours is obviously abnormally fast, but a week or two doesn't need to be.

One of my friends ended up rejecting an offer both from Google and Apple because the interview process took too long with no responses. They got a good offer in the mean time, and after waiting over a month for a response they decided they had to go with it. (They followed through with the rest of the Google/Apple interview process anyways for the experience... which was basically just host matching and getting an offer).

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

#42

Post by klenwell » Mon, Dec 03, 2018, 5:41 AM UTC

I notice a lot of these answers focus on the technical or coding challenge. As a hiring manager, that's critical, but technical competency only accounts for about a third of the qualities my team is evaluating in a candidate.

I've given this question a lot of thought over the last couple years as I've lead teams that have needed to get organized and expand quickly. Here's my summary taken from a Google Slides presentation I put together titled "Hiring in a Time of Cargo Culturalism".

It starts with Principles and Guidelines:

- Hiring cycles will be structured and as short as possible.

- When we start a hiring cycle, we will finish it by hiring the most qualified applicant who accepts our offer.

- Every applicant will receive a response within 48 hours and be updated on the status of their application at each step asap.

- The hiring process will be as transparent as possible.

- Objective and fair-minded measures will displace biased and bigoted ones.

- Every applicant will appreciate their experience, even the rejected ones.

- The process will be agile and adapt over time to improve and meet the specific needs of the organization.

- Onboarding will begin with hiring.

Then an outline of my team's current Methodology:

- A thoughtful and literate job posting will accurately describe the job and foreshadow the company culture.

- Simple challenges and honeypots will filter serious candidates from the applicant bots.

- At the end of every step, we will inform the applicant what comes next. Courteous templated responses will be promptly delivered.

- Two interviews. No more than three. The coding challenge will represent a genuine work sample. It will be no more than one or two hours.

- Candidates will be evaluated using a simple quantitative assessment of core competencies (see Ch. 21 of Kahneman’s Thinking Fast and Slow).

- Final decision will be a collective decision of the hiring team.

- After hiring cycle is complete, hiring team will hold a retrospective.

I've hired over a dozen developers this year. They haven't all been homeruns but no strikeouts either. A few singles or walks. A lot of solid doubles. And that's mostly what my company needs.

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

#43

Post by rococode » Mon, Dec 03, 2018, 5:43 AM UTC

lawnchair_larry wrote: post #30

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

Yeah, I'm currently a grad student so there's definitely some bias haha.

The kind of question I had in mind would be along the lines of "say you have a tree, how could you find the nearest common ancestor of two nodes in that tree?". I actually got this question during an interview recently, and I felt it was of a suitable difficulty where I could figure out a solution without any specific knowledge other than what a tree is (which most developers should know).

I'm sure I'm still young and naive, but my line of thinking is that a question like that is good for having a person show their thought process when figuring out a problem they haven't seen before. Design questions are a bit different because they tend to just require a rehash of a codebase you've worked with before.

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

#44

Post by vtesucks » Mon, Dec 03, 2018, 5:47 AM UTC

klenwell wrote: post #42

I notice a lot of these answers focus on the technical or coding challenge. As a hiring manager, that's critical, but technical competency only accounts for about a third of the qualities my team is evaluating in a candidate. I've given this question a lot of thought over the last couple years as I've lead teams that have needed to get organized and expand quickly. Here's my summary taken from a Google Slides present…

Your answer shows you are experienced . How do you test for inter prrsonal skills?

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

#45

Post by yjhoney » Mon, Dec 03, 2018, 5:50 AM UTC

I've spent alot of time thinking about this, and I've concluded with this:

Hire local people minimum wage to learn and teach each other coding structured around your company's codebase. Once they get to know the basics, have them work on your company's open source projects. Identify the ones who actively help others and convert them as a full time software engineer.

It takes an average person about 1 year to learn enough basics to contribute to a codebase, and paying someone minimum wage only costs about 30k / year so it works out financially on both sides.

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

#46

Post by thatswrong0 » Mon, Dec 03, 2018, 5:51 AM UTC

Speed and no trivia / bullshit interview question. Interviews should be assessing me on the skills I’ll need to get the job done, not recanting some data structure or algorithm to solve a problem that’s unlike anything I’ll ever actually deal with.

Ask me about my past projects and decisions I made and mistakes I made and what I’d do differently. Sit down with me and actually code with me and get a feel for what that’s like. Ask me to how I’d design some actually realistic system, and drill into the details of each.

I shouldn’t have to train to pass an interview. Prepare, yes. Practice a bunch of problems unrelated to the job at hand, no thank you.

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

#47

Post by oceanghost » Mon, Dec 03, 2018, 5:56 AM UTC

Counterintuitively I think the problem with hiring is actually a problem with firing. Hear me out.

Everyone is so focused on finding this mythical perfect candidate, instead of giving people a chance. Which is really another way of saying "We're afraid to fire people."

Culturally, we should hire and fire more freely.

I once got a call from a company that said I was an absolute perfect fit for what they were doing-- would I consider a 6-month contract-to-hire? I had been in my job 10 years and told them no. They were so flabbergasted they called back and asked if I wouldn't consider it, that the CTH was simply to see if I was a "culture fit." I told them in plain language that if I was such a perfect candidate, they could hire me straight out. That I'd been in a job 10 years, was obviously happy, why would I jump ship so they could dangle employment as a carrot in front of me?

I can't tell you how many jobs I've not gotten because I didn't get some gotchya question-- or in some cases understood more than the person interviewing me.

The abusive hours need to end, as does the concept of "culture fit" which is just a proxy for age, race, religion, binger drinker status, etc.

We need to stop judging people and trying to feel better about ourselves by dismissing people who can't answer questions we just googled ourselves. Almost every company I've ever talked to claims they only hire the best candidates. That simply, cannot be true.

How is anyone supposed to grow if you can only get a job you're an expert in? And when what you're supposed to be an expert in changes every two years?

The answer is, culturally, you're not.

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

#48

Post by MarkMc » Mon, Dec 03, 2018, 6:34 AM UTC

sifoobar wrote: post #28

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.

All the coding challenges I ask of my candidates have been real-world problems I had to solve in the past where I though, "huh, this would probably be a good interview question". I also pay candidates for their time, except for the initial screening test.

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

#49

Post by navinsylvester » Mon, Dec 03, 2018, 6:35 AM UTC

sifoobar wrote: post #28

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.

Second that. I was hired via this model. Have also used this approach to hire and this has paid off more than any other approach.

A simple 100 line code can be curated and taught by a friend/relative in a very elaborate way. This approach can negate that issue in someway.

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

#50

Post by austincheney » Mon, Dec 03, 2018, 6:40 AM UTC

The interviewer should ask the candidate, in the candidate's own words, to walk through solving a problem proposed by the interviewer. No whiteboard. Just a simple conversation. The candidate must be provided the opportunity to organize their thoughts with notes on paper and have a short pause of time to think through an answer.

Problem solving is a fairly universal thought experience not limited to writing code. The goal is to ascertain whether the candidate can break down the complexity of a problem into simple steps, organize their thoughts into a clear flow, communicate clearly, and finally recommend a valid solution.

You don't need to test whether the candidate can actually write code, because this is built into the nature of the exercise as qualified by the feasibility of the proposed solution. This exercise also implicitly tests confidence, creativity, experience, and approach style.

Most importantly though, it separates the competent from the incompetent. No amount of framework foolishness and dependency baggage will communicate a solution for you.