A Method I’ve Used to Eliminate Bad Tech Hires

#1

Post by nickfrost » Wed, Nov 09, 2016, 11:13 PM UTC

A Method I’ve Used to Eliminate Bad Tech Hires
mattermark.com

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#2

Post by raoulw » Thu, Nov 10, 2016, 12:02 AM UTC

Trials are how we do things at Automattic. Not only do we get a feel for the candidate, but the candidate gets a feel for us too.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#3

Post by fowlerpower » Thu, Nov 10, 2016, 12:07 AM UTC

I think this is a great system that reduces false positives, significantly. It helps candidates shine and it helps employers get good engineers.

I would not rely solely on this as no process is perfect. However, I do weigh this part of the process the highest for my hiring.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#4

Post by happytrails » Thu, Nov 10, 2016, 12:09 AM UTC

We do a similar thing at our office. Phone interview to make sure basics are known and then a "homework" assignment. This weeds out a lot of folks who can't cut it. Then the interview itself we can get the social aspect out of the way.

Sometimes a candidate is a good coder but a horrible communicator or human :|

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#5

Post by stove » Thu, Nov 10, 2016, 12:11 AM UTC

Does anyone have experience with this style of interview from the candidate side of the equation?

I want to move to this style of hiring; however, I fear that because it's against the grain I may miss out on good candidates. Is that unfounded?

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#6

Post by hslee16 » Thu, Nov 10, 2016, 12:14 AM UTC

Having candidates work on small projects simulates the communication required to complete actual/mock work projects. This will definitely foster better rapport between people involved.

Personally, I'd rather be given a weekend to work on a smaller project rather than be tested on algorithms that are available by common libraries of most programming languages.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#7

Post by illicium » Thu, Nov 10, 2016, 12:16 AM UTC

Or I can have the candidate code with me for an hour during the interview, and save $100. They get to ask me questions about the problem directly, and I can see where they are struggling, and how they debug (trial and error? Google/SO?)

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#8

Post by Kluny » Thu, Nov 10, 2016, 12:21 AM UTC

illicium wrote: post #7

Or I can have the candidate code with me for an hour during the interview, and save $100. They get to ask me questions about the problem directly, and I can see where they are struggling, and how they debug (trial and error? Google/SO?)

It sounds like you would get a lot less out of this method than you would from the one described in the article.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#9

Post by Kluny » Thu, Nov 10, 2016, 12:23 AM UTC

raoulw wrote: post #2

Trials are how we do things at Automattic. Not only do we get a feel for the candidate, but the candidate gets a feel for us too.

I've actually got a technical interview from Automattic sitting in my inbox right now, that I'm planning to work on tonight! Any tips? Is it possible/encouraged to write back and ask questions during the test?

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#10

Post by ahh » Thu, Nov 10, 2016, 12:27 AM UTC

This system is interesting but has a crucial flaw: I legally can't take part. I have a job now, which claims ownership over any tech-related IP I create. There are processes for getting exceptions, but a) you won't get them for actual job-related things b) I'm not asking Google for an exception so I can interview somewhere else.

This is true for nearly anyone with a standard SV job. So if you're willing to restrict your pool to the currently unemployed, this can work, but I think you'd rather not do that.