Re:Harder programming questions do a worse job of predicting...
by Zimahl on Monday February 18, 2019 @03:44PM
(#19194262)
If you want to do it for junior developers, fine, but as a senior dev, I'm not doing any take home assignment. It's an immediate pass from me. There is very little possibility that you can glean anything from my code other than picking apart it for code review bullshit. I'm not going to waste 2 to 6 hours on this - done it before, never again.
Re:Harder programming questions do a worse job of predicting...
by JamieF1 on Monday February 18, 2019 @04:17PM
(#19194538)
And this is why I built a site to allow people to search for jobs based on interview type. Although I haven't done any proper marketing yet, still a work in progress (https://softwarejobs.xyz)
Everybody is different.
Re:Harder programming questions do a worse job of predicting...
by StreamBright on Monday February 18, 2019 @02:54PM
(#19193780)
Standard set of questions is a must, some companies do not realise that and surprised when totally random people show up on day 1.
Re:Harder programming questions do a worse job of predicting...
by gaustin on Monday February 18, 2019 @02:56PM
(#19193796)
How do you handle two separate onsites for people that have to travel to get to your office?
Re:Harder programming questions do a worse job of predicting...
by pmiller2 on Monday February 18, 2019 @03:26PM
(#19194081)
I’m sure it works out well for you in that the candidates that pass can probably do the job. But, you basically have lost me by the time you’re asking for more than a 20 minute recruiter call, 60 minute phone screen, and a ~5 hour onsite.
Re:Harder programming questions do a worse job of predicting...
by chrshawkes on Monday February 18, 2019 @05:15PM
(#19194982)
I immediately decline your type of interviews and my life is most likely better for it.
1. Phone screen which takes 15 or 20 minutes. 2. The candidate fills out an essay, including showing us some code they're proud of. 3. If the essay ticks the boxes we conduct a 1 hour on site interview. We use the same a set of questions for every candidate, so the investment is easy to manage, and our team has a shared set of expectations on what is good or bad. 4. If the interview goes well, we give them a take home assignment. Takes between 2 and 6 hours, depending on how experienced the candidate is. Problem is in C and/or Python (or both) 5. We wrap up with a 2 to 3 hour onsite interview. We walk through the assignment and have a deeper conversation about culture and fit.
The results have been positive for us: we've made some great hires and weeded out some candidates who weren't a good fit.
We've also been able to scale it down to the process we use for interns.
The 1 hour interview has some typical programming interview questions, but we wrap them into a real-world example. The goal isn't to prove they know how to program, but more about allowing them to show us how they think/work out a problem.