3 ms·

My optimal hiring process: 1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume. 2. Phone screen...ask th

My optimal hiring process: 1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume. 2. Phone screen...ask them simple technical and project questions directly from their resume. They wrote it so they should know it. Generally, bullshitters are exposed right away. Time investment: 20-30 mins 3. Take home project. A somewhat simple but non-trivial project like: Write an autocomplete search script using a large text document as your dictionary. This will test their understanding of algos and software engineering best practices. Time investment: 10 mins to review the code 4. They talk with 3-4 other engineers. Those engineers now have a simple project to compare candidates and to question the candidate with. "Why did you choose this algo?", "How did you break down this problem?". Each engineer can ask whatever they want. Time investment: 30 mins. 5. Final engineering huddle. Compare candidates, pros and cons. Gut feelings. Etc. Time investment: 30 mins. The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code? The project also spares the rest of the team from wasting time interviewing non-serious candidates.

odonnellryan 10y ago
> Time investment: 10 mins to review the code I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code? > The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code? Honestly, you don't get to see much if that person has a day job. You don't know who wrote it, if they had a friend review it, if they spent two or twenty hours on the project. You don't know anything about them by reading this project. If it is shit, yes, you probably shouldn't hire them. But if it is good code... 1) The user might be doing something your devs don't understand, because they are bad devs, not because they suck. 2) "Good code" is fairly subjective. I've written some pretty good code and been shot down for "not using a graphing database."
- up_and_up 10y ago
  > I never think this is fair. The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one. > You don't know anything about them by reading this project. You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
  - odonnellryan 10y ago
    > The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one. Mostly, you're determining who had more time to spend on the project. > You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process. You're adding another thing to rule candidates out but not in. The problem with exclusion is it becomes more and more likely to rule out good candidates.
runchberries 10y ago
> Time investment: 10 mins to review the code This is what really irks me about take home exercises. The candidate spends 2-4 hours (or 12 and say they did it in 2) and the interviewer has no real commitment to reading and understanding it. 10 minutes to review the code? I would expect a video call where we go over the code together. All interviewing I do, I do while talking to them and give them ample time to explain it back to me. The candidate is investing their time. You should have enough respect to invest your time too.
- up_and_up 10y ago
  > This is what really irks me about take home exercises. The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one. > I would expect a video call where we go over the code together. Thats what the next step is for.

odonnellryan 10y ago

> Time investment: 10 mins to review the code I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code? > The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code? Honestly, you don't get to see much if that person has a day job. You don't know who wrote it, if they had a friend review it, if they spent two or twenty hours on the project. You don't know anything about them by reading this project. If it is shit, yes, you probably shouldn't hire them. But if it is good code... 1) The user might be doing something your devs don't understand, because they are bad devs, not because they suck. 2) "Good code" is fairly subjective. I've written some pretty good code and been shot down for "not using a graphing database."

up_and_up 10y ago
> I never think this is fair. The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one. > You don't know anything about them by reading this project. You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
- odonnellryan 10y ago
  > The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one. Mostly, you're determining who had more time to spend on the project. > You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process. You're adding another thing to rule candidates out but not in. The problem with exclusion is it becomes more and more likely to rule out good candidates.

runchberries 10y ago

> Time investment: 10 mins to review the code This is what really irks me about take home exercises. The candidate spends 2-4 hours (or 12 and say they did it in 2) and the interviewer has no real commitment to reading and understanding it. 10 minutes to review the code? I would expect a video call where we go over the code together. All interviewing I do, I do while talking to them and give them ample time to explain it back to me. The candidate is investing their time. You should have enough respect to invest your time too.

up_and_up 10y ago
> This is what really irks me about take home exercises. The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one. > I would expect a video call where we go over the code together. Thats what the next step is for.