3 ms·
this might be a good way to filter for people who are fluent in the stack & dev environment you are measuring with, and have an intermediate or better level of
by shoo 8y ago
this might be a good way to filter for people who are fluent in the stack & dev environment you are measuring with, and have an intermediate or better level of base programming ability. this isn't a way to measure for other skills you might want people to have in a dev team (e.g. structuring code sensibly, controlling technical debt, experience with production deploys or whatever), and you're potentially going to miss highly capable devs who simply aren't fluent in what you're measuring, yet might be able to ramp up to be highly useful in a month or two.
i'm not a frontend dev , but having an 11 step technical question in only 1 hour seems a bit excessive. i'm more used to having a single technical question in one hour - with a few facets and some asymptotics, with an optional harder extension question for the less common person who can get a good solution to the first problem rapidly.
it kind of depends on what you want for the role --- do you have a bunch of boxes in the org chart where you want people who are intermediate-ish and can hit the ground running cranking out new features? or do you want some people with really good potential and are prepared to invest a bit in training them?
instead of focusing on the technical interview stage of the pipeline, another option would be to try adjusting the earlier stages. What evidence do you have that the filtering from 150 applicants down to 8 finalists is not throwing away a bunch of potentially good hires? e.g. What would happen if you tried to run all 150 applicants through the technical interview first?
- yeldarb 8y agoWe ordered our steps in the funnel that way because we wanted to prioritize people who wanted to work for _us_ (as opposed to getting any job or just the top paying job) and who had good communication skills and seemed like they would make a good fit with the team. The technical skills are important, for sure, but we'd rather have someone less experienced who was motivated to learn because this was their dream job than someone with tons of experience that didn't really care about having _this_ job. That's a good point about the timing; I did allow people to go over the time limit if they seemed like they were still making progress and needed it. Prior to the interviews I thought steps 1-8 (which were setting up for 9-11) would take about 15 minutes and we'd have the remaining 45 for the meat of the interview.
- lordCarbonFiber 8y agoOne rule of thumb I've found when constructing interviews is take how long it would take you (or any other member on your team) to do the problem cold and then multiply that by 2 to 3x. This gives two main advantages. The first is you have plenty of time for a conversation. Even assuming ideal conditions it takes between 2 and 3 times longer to walk someone through a solution as you implement it than just to incept an idea. Second is the interview platform is all ready stressful and deeply unnatural so building in some buffer for that necessary context switch helps you extract more signal. That all being said, if you beat a 2% rate on your total funnel you're doing pretty well. Most people just aren't going to be a good fit; that's just the reality of this industry with huge choice for the candidate (you almost certainly will not be anyone's first pick; the numbers are against you), near limitless specializations, and no real qualification body.