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.
Let me approach this from the interviewer/employer's point of view.
You advertise a web programming position and get dozens or hundreds of applicants. Everyone's claiming to be just awesome in their resumes. But when you start interviewing people, many of them aren't remotely qualified. We don't have time to interview everybody to such a degree that we can be absolutely sure we have an accurate picture of their capabilities--if we had that much free time we wouldn't need to hire anybody.
So we need to streamline the process somehow. But where do we set the bar? There are two kinds of errors we can make:
Pass on a qualified candidate (unfortunate but not a big deal)
Hire an unsuitable candidate (potentially disastrous, especially in a small business)
This is the situation potential employers find themselves in. And the rational thing to do is filter out the weak candidates as quickly and cheaply as we can, even if it means potentially culling an excellent candidate. Hence, little tests and coding exams. Are they perfect? Hell no. But they do thin the list of candidates substantially.
From there, we try to gain the most information about the remaining candidates for the least cost. So we start with short phone interviews. Then in-person interviews. Perhaps followed by another in-person interview. And finally a small paid project.
If it helps, we focus on asking questions that are applicable to the position--we don't ask candidates to do puzzles or big O notation.
I don't know of a better way to do it but I can totally appreciate how challenging and tedious this process can be for applicants who are having trouble getting hired.
If I can offer a tip to people trying to get a job: be well prepared for the interview. It's shocking how bad people do in interviews. Yes, people get nervous. But even taking that into account, most people are shockingly unprepared. Get a friend to ask you questions. Do little coding challenges. Do mock interviews with a friend if you can't get your nerves under control. Prepare and rehearse answers to likely questions beforehand. Give the interviewer a reason to advance you to the next level.
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
The whole concept of thinning down the list using far from perfect online challenges seems odd to me (unless you're doing university campus placements wherein there tend to be 200 folks applying for 10-20 roles. For regular hirings, the ratio is mostly lesser)
Your procedure sounds appropriate but I'd rather start off with a short phone interview (or Skype) so that both sides get clarity on what they're looking for.
Yes I know, a short call is not enough to determine that but it's analogous to speed dating. By the end of that call, both sides can conclude (unfortunately, this heavily leans on the interviewer side but however I've said no to a fair share of companies after such a call myself) whether there should be a next round OR not.
It's good to know that your focus is on applicable questions rather than theoretical ones. In the rare few that I've partaken, I usually asked both technical / behavioral questions relevant to the role and to extract the interviewee's idea of working.
Lastly, please note that the preparations that you've mentioned like solving mock challenges, interviews & rehearsal are helpful but the real interview is a different ball-game altogether since little things can derail it.
Like a unusually difficult interview which was due to the interviewer's bad mood as he came through humongous traffic (Yes, I've been in one of these too and needless to say I didn't make it ahead even though I was in sync with their requirements)
I think your last sentence should hold true for the interviewer as well. They need to equally convince a prospective candidate as to why working with them is a good thing.
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.
Let me approach this from the interviewer/employer's point of view.
You advertise a web programming position and get dozens or hundreds of applicants. Everyone's claiming to be just awesome in their resumes. But when you start interviewing people, many of them aren't remotely qualified. We don't have time to interview everybody to such a degree that we can be absolutely sure we have an accurate picture of their capabilities--if we had that much free time we wouldn't need to hire anybody.
So we need to streamline the process somehow. But where do we set the bar? There are two kinds of errors we can make:
This is the situation potential employers find themselves in. And the rational thing to do is filter out the weak candidates as quickly and cheaply as we can, even if it means potentially culling an excellent candidate. Hence, little tests and coding exams. Are they perfect? Hell no. But they do thin the list of candidates substantially.
From there, we try to gain the most information about the remaining candidates for the least cost. So we start with short phone interviews. Then in-person interviews. Perhaps followed by another in-person interview. And finally a small paid project.
If it helps, we focus on asking questions that are applicable to the position--we don't ask candidates to do puzzles or big O notation.
I don't know of a better way to do it but I can totally appreciate how challenging and tedious this process can be for applicants who are having trouble getting hired.
If I can offer a tip to people trying to get a job: be well prepared for the interview. It's shocking how bad people do in interviews. Yes, people get nervous. But even taking that into account, most people are shockingly unprepared. Get a friend to ask you questions. Do little coding challenges. Do mock interviews with a friend if you can't get your nerves under control. Prepare and rehearse answers to likely questions beforehand. Give the interviewer a reason to advance you to the next level.
The whole concept of thinning down the list using far from perfect online challenges seems odd to me (unless you're doing university campus placements wherein there tend to be 200 folks applying for 10-20 roles. For regular hirings, the ratio is mostly lesser)
Your procedure sounds appropriate but I'd rather start off with a short phone interview (or Skype) so that both sides get clarity on what they're looking for.
Yes I know, a short call is not enough to determine that but it's analogous to speed dating. By the end of that call, both sides can conclude (unfortunately, this heavily leans on the interviewer side but however I've said no to a fair share of companies after such a call myself) whether there should be a next round OR not.
It's good to know that your focus is on applicable questions rather than theoretical ones. In the rare few that I've partaken, I usually asked both technical / behavioral questions relevant to the role and to extract the interviewee's idea of working.
Lastly, please note that the preparations that you've mentioned like solving mock challenges, interviews & rehearsal are helpful but the real interview is a different ball-game altogether since little things can derail it.
I think your last sentence should hold true for the interviewer as well. They need to equally convince a prospective candidate as to why working with them is a good thing.
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.