In my experience hiring takes a lot of time and effort. I'm curious how companies scale their development teams while keeping enough capacity to develop?
You could probably hire someone good in about 2 weeks. I interviewed for my current job at 6 PM, got an offer letter at 8 AM the next day. Most of the people in the company go through a quick hire as well and while there's some bad hires it's more that they're inexperienced/cheap rather than the process.
I've had interviews that take months, but I don't really see the value of this. Why do you need 6 people to make a decision? Why do you need to ask them technical questions when you can ask for their college results? Why do you need to test them for skills they'll use maybe once a year?
Thank you for sharing your experience. I thought about cutting the process short like you suggested and live with the chances of bad hires but:
1. How do you avoid having a bad effect on the current team when they see churn like that?
2. College results could work for junior hires, but senior ones? Rely on feeling about their previous work experience?
1. Churn is bad, but it's a red flag that goes away. I think how you deal with bad hires matters more. Pushing the burden to the rest of the team (i.e. not firing) or bullying them into quitting is what hurts teams more. There's also a morale hit to having someone do the job of two people while waiting 4 months to hire someone else for the role.
2. For the most part, you just need someone who can do the job. Most people applying for seniors could; it's just a question of how fast/accurate/stable. For the most part, expected salaries tends to correlate with their ability.
Many of the bad hires I've seen were "cheap hires"; they applied for senior positions but were often paid half as much as a senior just because they were from a poorer country.
One guy had more ability as a researcher, less as a developer (he'd get things done very, very slowly, but produced well crafted code and was able to tackle the hardest problems). One guy was a great programmer but had personality issues, often getting into fights. Another scored highest on all the tests, but worked 12 hours/day and got nothing done. So I'm not sure assessments help in filtering most of these problems.
The reason is that bad hiring, depending on your current size, is one of the most ruinous things you can do. So people take their time. The alternative is ‘fire fast’ (with caveats), but a lot of places are afraid of doing that. Personally I prefer it.
> Why do you need to ask them technical questions when you can ask for their college results?
I would prefer a "fire fast" policy to the egregious and lengthy technical interview process that is common today.
However I've found that the few places that do say they supposedly have a "fire fast" policy, also have an egregious and lengthy interview pipeline also.
> Why do you need to ask them technical questions when you can ask for their college results?
Unfortunately, college results are not the most reliable. A in Algorithms class from a world-class CS university means something very different than the same A from some completely no-name Uni where teaching standards are very low and cheating is widespread and accepted. What's worse, even the people from top uni could be cheaters (it's just less likely) or rode on the backs of their colleagues in group projects.
Also, some people are like me and are not motivated to do well in school just for arbitrary and meaningless grades (I once got a grade corrected by the prof from C+ to A and didn't bother to go collect it, because what's the point of grades anyway?), while they will be very motivated in a job where they're paid good money.
I’m not sure it’s even true that cheating is less prevalent at top universities. It’s probably not something we can know in practice. Anecdotally I saw a fair amount. You could make the argument that people are more likely to cheat to even get in to top schools, resulting in more cheaters ending up there. Who knows.
This argument applies for every other field, but you don't see civil engineers doing interviews past a week, and even with substandard hires, building are built just fine.
About 20 years ago, it was also common sense that a CS degree from Caltech means more than a 3 month Rails bootcamp, but now they're all treated the same.
>> what's the point of grades anyway
> To get a good job :p
That's the thing - in my country (Poland) nobody looks at grades anyway. The only exceptions are American companies that have offices there. Everybody else cares very much about the kind of University you graduated from (I think they mostly treat it as a proxy for general IQ and work ethic - best Polish schools for CS have admission rate of 7-10%), but don't care about grades.
> About 20 years ago, it was also common sense that a CS degree from Caltech means more than a 3 month Rails bootcamp, but now they're all treated the same.
Maybe because coding just got easier? I have a junior guy on my team that barely comprehends how computers work under the hood. However, he's still quite productive in an advanced/esoteric functional programming language. He just needs a little guidance by a senior to debug some less obvious issues or to review his designs to make sure they're not a performance catastrophe. Meanwhile, 20 years ago he'd just add a ton of segfaults to a C++ codebase and be fired...
Do they have a degree in accounting or agricultural engineering? Surely they did some math. And if they didn't, it's fair to assume they don't have algorithms experience.
I'm not sure if this is an "American thing", but in (Western) Europe usually a candidate that holds a degree in engineering or has a couple of years of experience is enough to be considered a competent developer. Sure, there are tech interviews and the like, but in all my years of experience and companies I have worked for, most if not all of the colleagues I have worked with were normal developers (which for 99% of the tech companies out there means 'good developers').
That's possible, but then doesn't that limit your candidates pool to people with engineering degrees?
I'm not sure about the couple of years experience, that's sometimes a miss depending on what they built during those years.
I've worked with people who have a degree and a couple years of holding a developer job without actually being able to do software development. It's not pleasant.
When I do a technical interview, I'm mostly looking for basic skills: from a brief description of the problem with example input, ask any questions and describe the output and show what the output would be. Then write code that does what you described; any language is fine as long as it's consistent on the board. My problem is reversable, so if we have time, I ask them to write the code to go the other way.
The problem itself isn't hard, the biggest issue people have is being consistent; even after we spent a good portion of time coming up with an example output, some people do something totally different. Very ocassionally, I get someone who has real trouble with a basic for loop. Sometimes, people are having a bad day and you can tell, which is unfortunate. If they're local, you can try to get them rescheduled, but if they were flown in, that's kind of their one shot for a while.
My experience is around half year. That includes searching for that good developer and the other 9-10 senior interviews which you had your hopes up but didn't match. It's really hard to find a good senior dev these days...
Once you have the candidate, it shouldn't take that long, maybe a week or two, it really depends on how many steps your hiring process. At the company I work at, we have a technical interview and a soft skills interview, and we try to have them all in one day (because with the hight demand of developers, we might miss them if we take to long).
Anyway, what takes more time is actually getting the interview, and this depends on the value your company adds to collaborators. For example, if you're a company with great reputation, salaries, good benefits, interesting projects, you will get good candidates in line. But if your company isn't really "outstanding", finding someone that's truly good will take a lot of effort. Bear in mind software developers have many job offers, in a weekly basis.
This is why it's so important to build an employers brand!!
That has also been my experience. Truth is, there are many good developers out there. Maybe they can't be bothered to practice for leetcode (and why should you do it if you do not have 100k applicants per open role?).
In ~4h total time interview you can have a very strong feeling if someone will be a fit culturally and if they aren't incompetent. Give them a chance.
Or you can spend months and many more hours to roll a dice with a bit higher chance of making a better hire...
There are probably a lot of variables here, for example when I lived in Edinburgh there was a local company that always had job-openings for Perl programmers. I could have applied for it, but never did because their salary was 50% less than anything else local.
Whenever I hear companies struggle with hiring at least a lot of the time the reason is that there are better jobs available in the same city for more money.
Whenever I've been between jobs I've just googled "Sysadmin $location", and tend to find a new position within 2-4 weeks. But if there are five adverts and two of them have low salaries I ignore them.
Good developer is highly subjective and often disappointing. When people say that they typically mean specifically targeted candidate. How long it takes to find that person typically comes down to:
* specificity of targeting
* commonality of targeted skills in the market place
* competition for such candidates
Confusing something good for those factors is half the reason many companies stop reading resumes and make poor hiring decisions. A poor hiring decision is not just someone unqualified but also people who are well qualified yet not what you expect or need.
In my case as a JavaScript developer many companies knowingly ship the same kinds of crappy software over and over because they leverage their hiring risks away from writing software to tooling popular tools/frameworks.
24 comments
[ 2.1 ms ] story [ 59.3 ms ] threadShift the deadline
Pay contractors
Sacrifice quality by either working overtime or reducing standards
Depending on organization the hiring process can be fast and effective.
I've had interviews that take months, but I don't really see the value of this. Why do you need 6 people to make a decision? Why do you need to ask them technical questions when you can ask for their college results? Why do you need to test them for skills they'll use maybe once a year?
2. For the most part, you just need someone who can do the job. Most people applying for seniors could; it's just a question of how fast/accurate/stable. For the most part, expected salaries tends to correlate with their ability.
Many of the bad hires I've seen were "cheap hires"; they applied for senior positions but were often paid half as much as a senior just because they were from a poorer country.
One guy had more ability as a researcher, less as a developer (he'd get things done very, very slowly, but produced well crafted code and was able to tackle the hardest problems). One guy was a great programmer but had personality issues, often getting into fights. Another scored highest on all the tests, but worked 12 hours/day and got nothing done. So I'm not sure assessments help in filtering most of these problems.
> Why do you need to ask them technical questions when you can ask for their college results?
Genuinely no offence, but this one hurt to read!
However I've found that the few places that do say they supposedly have a "fire fast" policy, also have an egregious and lengthy interview pipeline also.
Unfortunately, college results are not the most reliable. A in Algorithms class from a world-class CS university means something very different than the same A from some completely no-name Uni where teaching standards are very low and cheating is widespread and accepted. What's worse, even the people from top uni could be cheaters (it's just less likely) or rode on the backs of their colleagues in group projects.
Also, some people are like me and are not motivated to do well in school just for arbitrary and meaningless grades (I once got a grade corrected by the prof from C+ to A and didn't bother to go collect it, because what's the point of grades anyway?), while they will be very motivated in a job where they're paid good money.
To get a good job :p
This argument applies for every other field, but you don't see civil engineers doing interviews past a week, and even with substandard hires, building are built just fine.
About 20 years ago, it was also common sense that a CS degree from Caltech means more than a 3 month Rails bootcamp, but now they're all treated the same.
That's the thing - in my country (Poland) nobody looks at grades anyway. The only exceptions are American companies that have offices there. Everybody else cares very much about the kind of University you graduated from (I think they mostly treat it as a proxy for general IQ and work ethic - best Polish schools for CS have admission rate of 7-10%), but don't care about grades.
> About 20 years ago, it was also common sense that a CS degree from Caltech means more than a 3 month Rails bootcamp, but now they're all treated the same.
Maybe because coding just got easier? I have a junior guy on my team that barely comprehends how computers work under the hood. However, he's still quite productive in an advanced/esoteric functional programming language. He just needs a little guidance by a senior to debug some less obvious issues or to review his designs to make sure they're not a performance catastrophe. Meanwhile, 20 years ago he'd just add a ton of segfaults to a C++ codebase and be fired...
What about non-CS degree folks? What about people who graduated 20 years ago?
I'm not talking about rock stars.
When I do a technical interview, I'm mostly looking for basic skills: from a brief description of the problem with example input, ask any questions and describe the output and show what the output would be. Then write code that does what you described; any language is fine as long as it's consistent on the board. My problem is reversable, so if we have time, I ask them to write the code to go the other way.
The problem itself isn't hard, the biggest issue people have is being consistent; even after we spent a good portion of time coming up with an example output, some people do something totally different. Very ocassionally, I get someone who has real trouble with a basic for loop. Sometimes, people are having a bad day and you can tell, which is unfortunate. If they're local, you can try to get them rescheduled, but if they were flown in, that's kind of their one shot for a while.
Anyway, what takes more time is actually getting the interview, and this depends on the value your company adds to collaborators. For example, if you're a company with great reputation, salaries, good benefits, interesting projects, you will get good candidates in line. But if your company isn't really "outstanding", finding someone that's truly good will take a lot of effort. Bear in mind software developers have many job offers, in a weekly basis.
This is why it's so important to build an employers brand!!
In ~4h total time interview you can have a very strong feeling if someone will be a fit culturally and if they aren't incompetent. Give them a chance.
Or you can spend months and many more hours to roll a dice with a bit higher chance of making a better hire...
Whenever I hear companies struggle with hiring at least a lot of the time the reason is that there are better jobs available in the same city for more money.
Whenever I've been between jobs I've just googled "Sysadmin $location", and tend to find a new position within 2-4 weeks. But if there are five adverts and two of them have low salaries I ignore them.
* specificity of targeting
* commonality of targeted skills in the market place
* competition for such candidates
Confusing something good for those factors is half the reason many companies stop reading resumes and make poor hiring decisions. A poor hiring decision is not just someone unqualified but also people who are well qualified yet not what you expect or need.
In my case as a JavaScript developer many companies knowingly ship the same kinds of crappy software over and over because they leverage their hiring risks away from writing software to tooling popular tools/frameworks.