Over the last decade+ I've been involved in the hiring process at every company I've been an employee at. I've either been a key technical interviewer, or the hiring manager. I would be able to pass all my interviews, and I'm pleased to say that (with one exception) all of my hires have succeeded in their roles. I have a very straightforward process.
- Look at every resume, pass/fail fast. Ask the Recruiter or HR to give you more resumes, not less (they typically are not equipped to assess techncal resumes)
- 15 minute phone screen. Make sure the role fits expectations, make sure the salary range is acceptable, get and give a verbal background.
- At-home code task. Something that takes an hour or so to get functional. More if the interviewee wants to put some spit-shine on it. I ask for a git repo back, and I tell the applicant up front that the code will be used to springboard the technical interview.
- 2 hour technical interview, no live-coding. In person or virtual. This involves other engineers from the org -- we code review the git repo. For each code task I have a set of 3/4 "Product Manager" style enhancement requests, we then verbally talk through the technical changes & challenges for each ask.
- 15 minute chat with the CT or VP or whomever is my boss.
- Extend an offer.
It's all very real, and very pragmatic, and shouldn't suck more than 4-6 hours out of an applicants life, total. I want to be able to extend an offer within days, assuming everyone's schedule aligns. There is 0 reason to go deeper. If you cannot asses someone's technical chops in a 2 hour conversation, you shouldn't be involved in hiring. If you couldn't complete the coding challenges to your own satisfaction, you shouldn't be involved in hiring (there are engineers I've worked with who are no longer involved in hiring due to unneeded pedantry that they themselves would not tolerate if the shoe was on the other foot).
Just thinking about all the roles I’ve interviewed for across from someone with 2 yoe asking a version of an A* algorithm implementation for web development.
No. Because it is a problem that has nothing to do with real work. I would need to spend at least a month practicing those kinds of problems to be able to perform well in that 1 hour.
The last few times we have done interviews I’ve done the same coding test as the applicants while they are working on it. I try to solve it in a slightly different way each time.
We are currently revamping our hiring process and the questions we keep asking are “Would X, Y, Z pass this or get hung up on this coding test, question, etc”. As in taking care to think about how existing employees would do on the new process.
A few years ago we started using HackerRank and created a test with 4 or 5 coding questions for candidates to do on their own. They could pick the programming language from about 10 options and the questions had varying degrees of complexity, with one being particularly difficult.
I sent it to almost all engineers on the team before we started using it and none could hit a 100% on it.
We still went ahead and started using it in our process. Non surprisingly, most folks would fail to get a perfect score but we still use it to see what they tried and also one of the following interviews was a review of the whole test with the applicant as we discussed their thought process and what other odeas they may have come with since they took the test.
Our intention with the test was mostly basic problem solving skills and was the first step in the process so it also worked as a filter.
Yes. My company thankfully does not do leetcode stuff. When I was interviewing I was tasked with some serialization/deseriazation, which we actually used inside our company.
Readit News
I consider it a miracle that I got in. I thank God every day.
Did the interview matter, in terms of technically assessing for what I do day to day? Very little.
- Look at every resume, pass/fail fast. Ask the Recruiter or HR to give you more resumes, not less (they typically are not equipped to assess techncal resumes)
- 15 minute phone screen. Make sure the role fits expectations, make sure the salary range is acceptable, get and give a verbal background.
- At-home code task. Something that takes an hour or so to get functional. More if the interviewee wants to put some spit-shine on it. I ask for a git repo back, and I tell the applicant up front that the code will be used to springboard the technical interview.
- 2 hour technical interview, no live-coding. In person or virtual. This involves other engineers from the org -- we code review the git repo. For each code task I have a set of 3/4 "Product Manager" style enhancement requests, we then verbally talk through the technical changes & challenges for each ask.
- 15 minute chat with the CT or VP or whomever is my boss.
- Extend an offer.
It's all very real, and very pragmatic, and shouldn't suck more than 4-6 hours out of an applicants life, total. I want to be able to extend an offer within days, assuming everyone's schedule aligns. There is 0 reason to go deeper. If you cannot asses someone's technical chops in a 2 hour conversation, you shouldn't be involved in hiring. If you couldn't complete the coding challenges to your own satisfaction, you shouldn't be involved in hiring (there are engineers I've worked with who are no longer involved in hiring due to unneeded pedantry that they themselves would not tolerate if the shoe was on the other foot).
Sounds like a decent place!
We are currently revamping our hiring process and the questions we keep asking are “Would X, Y, Z pass this or get hung up on this coding test, question, etc”. As in taking care to think about how existing employees would do on the new process.
I sent it to almost all engineers on the team before we started using it and none could hit a 100% on it.
We still went ahead and started using it in our process. Non surprisingly, most folks would fail to get a perfect score but we still use it to see what they tried and also one of the following interviews was a review of the whole test with the applicant as we discussed their thought process and what other odeas they may have come with since they took the test.
Our intention with the test was mostly basic problem solving skills and was the first step in the process so it also worked as a filter.
Deleted Comment