3 ms·
My favorite interviews are when they give me a take home project that takes 2-3 hours and then during the technical interview you go over the solution and talk
by notus 7y ago
My favorite interviews are when they give me a take home project that takes 2-3 hours and then during the technical interview you go over the solution and talk about ways to improve it. It gives applicants a chance to actually prepare for the interview in a meaningful way and I personally am much less nervous for this type of interview.
- malvosenior 7y agoI think this is a great way to do it. I don't even give people take home assignments, but a small project coded on the applicant's own time, not in real-time with the interviewers watching is far superior to the alternative. Live coding a problem you were just given, in front of strangers that are also evaluating you for a job is not a good way to evaluate candidates. Interviewing for a job is already a stressful situation, adding live coding to the mix takes it far into absurdly difficult territory. No real life job conditions match that type of situation, and if they do then there are other much bigger problems at play in that company.
- 11thEarlOfMar 7y agoThis is our approach. Choose one of five assignments, we ask for 100 lines of code, take it home, take as much time as you need. When you come back, we do a code walk through with the team. We've hired only great people with this approach, and they've told me after the fact that they really appreciated that it tested them in a natural manner, rather than a type of competition.
- ebiester 7y agoI'm starting to feel like we're self-organizing a bit into types of companies based on our interviewing styles. There are developers who excel at whiteboarding. There are those who excel at presenting their own projects from their github experience. There are yet others that excel in small code samples on company-driven problems, and some that excel in larger code samples. The truth is that no one interviewing style works best for finding all developers that are a match for the company. Either we need to accommodate multiple interviewing practices, or we need to accept that we are going to gather in the companies that match our interviewing styles the best. I wonder sometimes if there isn't room for a company that hires everyone who can fizzbuzz and is a good fit for the company as determined by behavioral interviews, and then accept a large attrition within the first 3 months. I think the honest truth is that no matter what we do, interviewing is a hard problem.
- manthedudeguy 7y ago> we ask for 100 lines of code Why?
- 11thEarlOfMar 7y agoWe don't want them to spend too much time. I tell them we don't expect them to spend more than 2 hours, and we're looking for 100 lines. I don't think it's reasonable to ask for much more of their time than that. Turns out they all wind up spending 8+ hours and most really get into the task.
- shantly 7y agoI love a rough lines/size guide and will be stealing that idea :-) The biggest risk with those take-home projects is that you'll lose out on the "2-3 hour project" because someone else spent 5-6 hours and had time not to just finish it, but to make it look very polished—unreasonably polished for 2-3 hours. So you either do it as directed and worry, or spend way more time on it (enough that I'd probably just pass unless it was one hell of a job) Keep it small enough and you don't run into the thing where you're excluding the semi-happily employed, competent devs, because they don't really have to put up with your shit to find new employment, which is the case with those defined time (but not really) larger projects.
- manthedudeguy 7y agoDo you mean you don't want more than 100 lines, or that you want around 100 lines exactly? The latter seems preposterous to me.