4 ms·

This is confusing to me, because supposedly there’s a shortage of “good engineers”. That may be the case or not, but if so, why are these additional bottlenecks

This is confusing to me, because supposedly there’s a shortage of “good engineers”. That may be the case or not, but if so, why are these additional bottlenecks being added when these interviews universally seem to be perceived as irrelevant to the daily work of engineering? What would make more sense to me is if the focus moved toward architecture design instead of leetcode. “What stack would you propose for this product?” Instead of, “Take these two arrays of strings and output a new array where no strings has a letter found in another blah blah blah...”

tmpz22 6y ago
There isn't a shortage of generic developers, but there are shortages of specialized developers. One shortage example would be an SRE who knows Azure, Kubernetes, Jenkins, and Jira, very well. Another example would be a front-end developer who knows iOS development so well that they can make up for the pit-falls of React Native while also writing half decent typescript code. It's often difficult to interview specialized developers because the specialist often understands (or pretends to understand) the specialty better then the interviewer themselves. These hiring opportunities represent a large number (maybe even a majority) of roles at small, medium, and large, companies. FANNG and maybe a few other companies which have custom tool chains from top to bottom are a little bit different because Google probably doesn't care if you know Jenkins because you'll have to be trained in their homegrown alternative anyways.
- Apocryphon 6y ago
  The demise of training in this industry is pretty lamentable. While companies can't be expected to turn generic developers into incredibly specialized developers, they probably could do more to help the former move closer to the latter.
wolco 6y ago
There is no shortage of good engineers applying to these places. There is a cheap engineer shortage.
seankimdesign 6y ago
I think I read something a while back from the point-of-view of a Google recruiter or someone that described their reasoning for this. The reality is that most companies are okay with the possibility of rejecting a good engineer who has all the potential to be a good fit for them. There's really no shortage of candidates who want to work for them, so they are okay with false negatives as long as engineers are still lining up to interview for them. What they aren't okay with, however, is the possibility of accidentally accepting a bad engineer: a problem which is quite costly to remedy. The current state of algorithm-heavy interview process is really just a hamfisted solution to the problem stated above. They are trying to minimize false-positives while accepting that it increases the rate of false-negatives, and their proxy for implementing this threshold is algorithmic knowledge. It's not fun for anyone involved, but I guess I have to assume it works.
greenshackle2 6y ago
Personally, I've done interviews where I ask a few toy algo questions of increasing difficulty, in a language of their choice. The first question is trivial and screens out candidates who can't code at all. The more difficult questions are more to see if they can communicate clearly about code, and performance / complexity issues, and how they respond to questions and feedback on their code. I don't care that much whether they can solve questions 2 and 3 perfectly, but they should be able to come up with something. If they pass that I would devise a longer interview suited to their CV. I expect a senior to be able to answer architectural questions and / or talk intelligently about architectural decisions they've made on past projects. If they claim experience in a job-relevant domain I would ask domain-specific questions, if not, the expectation would be that they would ramp up, and I would stick to more general questions. So the point is to avoid wasting time preparing and doing longer interviews for candidates who can't even calculate the average value of an array (or worse, hiring them), and get a bit of an idea of their ability to think and communicate about code. I'm honestly not very confident this is a good approach but that's why I did it.

tmpz22 6y ago

There isn't a shortage of generic developers, but there are shortages of specialized developers. One shortage example would be an SRE who knows Azure, Kubernetes, Jenkins, and Jira, very well. Another example would be a front-end developer who knows iOS development so well that they can make up for the pit-falls of React Native while also writing half decent typescript code. It's often difficult to interview specialized developers because the specialist often understands (or pretends to understand) the specialty better then the interviewer themselves. These hiring opportunities represent a large number (maybe even a majority) of roles at small, medium, and large, companies. FANNG and maybe a few other companies which have custom tool chains from top to bottom are a little bit different because Google probably doesn't care if you know Jenkins because you'll have to be trained in their homegrown alternative anyways.

Apocryphon 6y ago
The demise of training in this industry is pretty lamentable. While companies can't be expected to turn generic developers into incredibly specialized developers, they probably could do more to help the former move closer to the latter.

wolco 6y ago

There is no shortage of good engineers applying to these places. There is a cheap engineer shortage.

seankimdesign 6y ago

I think I read something a while back from the point-of-view of a Google recruiter or someone that described their reasoning for this. The reality is that most companies are okay with the possibility of rejecting a good engineer who has all the potential to be a good fit for them. There's really no shortage of candidates who want to work for them, so they are okay with false negatives as long as engineers are still lining up to interview for them. What they aren't okay with, however, is the possibility of accidentally accepting a bad engineer: a problem which is quite costly to remedy. The current state of algorithm-heavy interview process is really just a hamfisted solution to the problem stated above. They are trying to minimize false-positives while accepting that it increases the rate of false-negatives, and their proxy for implementing this threshold is algorithmic knowledge. It's not fun for anyone involved, but I guess I have to assume it works.

greenshackle2 6y ago

Personally, I've done interviews where I ask a few toy algo questions of increasing difficulty, in a language of their choice. The first question is trivial and screens out candidates who can't code at all. The more difficult questions are more to see if they can communicate clearly about code, and performance / complexity issues, and how they respond to questions and feedback on their code. I don't care that much whether they can solve questions 2 and 3 perfectly, but they should be able to come up with something. If they pass that I would devise a longer interview suited to their CV. I expect a senior to be able to answer architectural questions and / or talk intelligently about architectural decisions they've made on past projects. If they claim experience in a job-relevant domain I would ask domain-specific questions, if not, the expectation would be that they would ramp up, and I would stick to more general questions. So the point is to avoid wasting time preparing and doing longer interviews for candidates who can't even calculate the average value of an array (or worse, hiring them), and get a bit of an idea of their ability to think and communicate about code. I'm honestly not very confident this is a good approach but that's why I did it.