I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I think the way we do hiring is terrible (and not just in programming). Lots of surveys suggest that if you regret only half of your hires after a year you're about average. That's depressing to think about.
I think candidates need to be prepared for the interview even if there's a chance your interviewer will be unfair for some reason. Being prepared won't guarantee you an offer but being unprepared will almost certainly guarantee that you won't get one.
We tried doing phone interviews first and it didn't work for us. I don't know if "web developer" positions attract particularly unqualified candidates or it is related to the shortage of developers in my city but it didn't work.
Our current practice is to scan the resumes and as long as they are remotely qualified we invite the candidates to do a quick test online. All they have to do is write a very simple function to assess whether they can program at all. They are given 15 minutes to do what should take 5 not more than minutes. Less than 30% of the candidates succeed. They are cut if they don't pass.
I know that sounds harsh but we see a lot of people who say all the right things completely fail when we give them an absolutely beginner programming assignment.
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
Preparation undeniably counts but with no offense intended to anyone, I'll quote a proverb that I felt is apt here
A fool can ask more questions than seven wise men can answer.
While your approach is practical given the shortage of time, I think it's time we (as an industry) collectively revamp the interview process so that people are judged based on what they're really capable of rather than textbook assignments that hold no real world value whatsoever.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
From my limited know-how, I'd ideally ensure the candidate undergoes 2 or 3 rounds of interviews with people of the designated team and if they clear it, a panel round with all of them so that it's easy to get a fair overview of the candidate while eliminating individual bias.
The idea here would be to ask (technical concepts - general and particularly role based along with behavioral) questions.
Yes, shortage of time is a major constraint here and so is proper execution of this but even if done with 70% efficacy, I believe the new hires will be of much better quality.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Thanks for sharing this, Vinay. I think the devil is in the details here. Executed well, this would probably work. Executed poorly, and it could be a time waster.
I definitely agree with the team being involved in the interview (and perhaps even giving each member a veto).
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
Glad to help Blaine! Do share your experiences if ever you put it into practice or even add something more so that the rest of us will find it useful too.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yes, I agree with most of your points.
I think the way we do hiring is terrible (and not just in programming). Lots of surveys suggest that if you regret only half of your hires after a year you're about average. That's depressing to think about.
I think candidates need to be prepared for the interview even if there's a chance your interviewer will be unfair for some reason. Being prepared won't guarantee you an offer but being unprepared will almost certainly guarantee that you won't get one.
We tried doing phone interviews first and it didn't work for us. I don't know if "web developer" positions attract particularly unqualified candidates or it is related to the shortage of developers in my city but it didn't work.
Our current practice is to scan the resumes and as long as they are remotely qualified we invite the candidates to do a quick test online. All they have to do is write a very simple function to assess whether they can program at all. They are given 15 minutes to do what should take 5 not more than minutes. Less than 30% of the candidates succeed. They are cut if they don't pass.
I know that sounds harsh but we see a lot of people who say all the right things completely fail when we give them an absolutely beginner programming assignment.
Preparation undeniably counts but with no offense intended to anyone, I'll quote a proverb that I felt is apt here
While your approach is practical given the shortage of time, I think it's time we (as an industry) collectively revamp the interview process so that people are judged based on what they're really capable of rather than textbook assignments that hold no real world value whatsoever.
Agreed. How do we do it? What would a better process look like?
From my limited know-how, I'd ideally ensure the candidate undergoes 2 or 3 rounds of interviews with people of the designated team and if they clear it, a panel round with all of them so that it's easy to get a fair overview of the candidate while eliminating individual bias.
The idea here would be to ask (technical concepts - general and particularly role based along with behavioral) questions.
Yes, shortage of time is a major constraint here and so is proper execution of this but even if done with 70% efficacy, I believe the new hires will be of much better quality.
Thanks for sharing this, Vinay. I think the devil is in the details here. Executed well, this would probably work. Executed poorly, and it could be a time waster.
I definitely agree with the team being involved in the interview (and perhaps even giving each member a veto).
Glad to help Blaine! Do share your experiences if ever you put it into practice or even add something more so that the rest of us will find it useful too.