3 ms·

> Okay, I have interviewed hundreds of people in the last decade, and I can tell you that most are not good enough. Me, too. I straight-up disagree; I think in

> Okay, I have interviewed hundreds of people in the last decade, and I can tell you that most are not good enough. Me, too. I straight-up disagree; I think interviewing is just so broken it gives a false impression of quality issues in the labor pool. Realistically if you have a handful of core skills you can ramp up to basically any problem with enough time. That's time on the order of months, maybe, not years. Companies just don't want to bother training anyone anymore. Why bother when you can just complain endlessly and hope some politicians throw cheap labor your way? In that sense you're absolutely right, but the whole "quality" thing is completely unrelated. > I have been successful in liberating money from VCs and create jobs, and I want the best people that money can buy. I think people seriously overestimate the difference engineer quality makes. Most products can be built with mediocre talent. I'm sorry, that's the truth. We all love to have strong opinions on who we should hire and I say "almost anyone, just throw meat at the problem". Most problems are solved with time and not cleverness. Startups are definitely more sensitive to quality, but startups don't make up much of the labor pool, and they don't pay competitively with much larger companies that don't need the quality. I'm being a little hyperbolic here—you do need people with experience and ability to see red flags to lead the flock—but not by much.

throwaway48476 2y ago
This is the truth that peoples egos can't seem to handle.
UncleOxidant 2y ago
Add in that in the search for the perfect candidate that has all 16 bullet point requirements you'll come across folks who have, say, a solid 13 of them, but they'll get passed over waiting for the perfect candidate to come around. Which can take many months... years even. In the meantime you could have been bringing up one of those 13-point candidates getting them up to speed on those 3 missing bullet points. And you'd likely have gotten to a desired level of productivity faster than by waiting for that perfect candidate while wringing your hands that there just aren't enough qualified people out there.
- throwaway7783 2y ago
  I don't think anyone is saying wait for the perfect candidate. No one is perfect and no one checks all the boxes. That would be a fool's errand. But most good engineers can differentiate between a good (not superstar) engineer and a mediocre/bad engineer in a couple of conversations. I really have not seen anyone optimize for a mediocre candidate, nor for a superstar. Superstars come by with luck or with tons of incentives (money, stock, tech or whatever is their itch).
  - UncleOxidant 2y ago
    I've often seen this happen. A few years back I applied for a job at a startup where I checked a lot of the boxes, but not all, but some of the boxes I checked were difficult to come by - never heard anything back. Six months passed and I was contacted by them, would I be interested in interviewing? I was and I ended up getting the job. Later when I asked about the position being open for so long I was told by one of the people involved that there were folks who were waiting for the perfect candidate to come along and finally, after many months, they were convinced that the perfect candidate probably didn't exist. So yeah, there's at least one instance of it where I know for sure that's what was going on and I've seen others where I'll watch a job listing keep appearing for several months.
    - throwaway7783 2y ago
      So they learned their lesson and hopefully don't make the same mistake again. We are in anecdote land now (both yours and mine), I don't know what's more common. Behavior like that (waiting for long for perfect candidate) can cripple or kill businesses
Aperocky 2y ago
> Most problems are solved with time and not cleverness. Yes, because given time someone clever would have came in and fixed it. It's like doing push up in the elevator and believing that arriving at the 100th floor is due to doing push ups. The GE, IBM, Intel, Boeing are few examples that didn't believe in quality - and not just people apparently, and their problems aren't getting solved with time.
- PittleyDunkin 2y ago
  Eh, I just don't see it. GE and IBM and Boeing are solving the problems they want to solve. Management dysfunction can't be blamed on low-quality workers. Anyway, I'm a little reluctant to draw the parallel with Boeing because I simply don't know what kind of work goes into that sort of engineering. Maybe cleverness is a big part! > Yes, because given time someone clever would have came in and fixed it. I can't emphasize enough how much software engineers overestimate the value of their own cleverness. Bugs are fixed with persistence, in my experience—I've used "cleverness" to find only a handful of bugs across my entire nearly two-decade career. I don't want to say I'm "the best engineer on the team" or anything like that, but I dependably fix the bugs that are put on my plate regardless of how frustrating they are to crack, regardless of what tools I need to bust out to get the job done. Debuggers, printf, valgrind, core dumps, packet captures, profilers, repls, disassembly, whatever's necessary. But all of these take persistence to reach for and use to crack the case. Experience is a short cut, but that's a very different thing than cleverness, and you very directly pay for that experience. Not to mention if I see "cleverness" in a code review you're gonna bet I'm gonna comment and ask you to make it less clever unless that cleverness seems to neatly solve a problem. Even then, commenting is absolutely critical. Time, not cleverness, is the key. Hell, the joke used to be that being a software engineer is 80% googling. Now that barrier's been lowered even further with chatbots: you can literally ask it to find the bug, explain behavior, fix the bug, etc. It doesn't take much competence to correct the output. All it takes is not giving up when you see problems.
  - Aperocky 2y ago
    Well everything you've written suggest to me that you're clever, or maybe that shouldn't be the word, but somewhere between smart and wise. And a lot of people aren't that.
devnullbrain 2y ago
>I think interviewing is just so broken it gives a false impression of quality issues in the labor pool. I've been in a team where hiring requirements have emerged through the filter of HR almost unrecognisable. Naturally, they're still objective requirements, so qualified candidates are filtered out before ever meeting someone who could judge if they're qualified. It gets noticed, but nothing happens. Of course it doesn't: you're stepping on important toes. That's how it tends to work. Candidates are filtered out by non-technical staff, including openly using programs that filter out CVs missing keywords. In smaller companies, this even gets farmed out to third-party recruiters that have poorly aligned incentives. How can we know if candidates are qualified? We never see most of them. It's hard to imagine many things worse for productivity than bad hiring processes. But it's all just accepted.
dml2135 2y ago
Screw the company -- sure, maybe they can build a product with mediocre talent. But I don't want to work with mediocre devs, because they make my life harder. I'd much rather wait for someone I want to work with, than hire the first person that is "good enough".
srj 2y ago
> I think people seriously overestimate the difference engineer quality makes. Most products can be built with mediocre talent. I'm sorry, that's the truth. We all love to have strong opinions on who we should hire and I say "almost anyone, just throw meat at the problem". Most problems are solved with time and not cleverness. I'm surprised that your experience here is so different from mine. The best engineers I've had are capable of things that the average to below average ones could likely have never achieved, even with an order of magnitude more time. I don't think it comes down to cleverness as it does inventiveness. There are dots that great engineers can connect that often nobody else could spot. They also need less process, and a large number of people with all of the coordination overhead does not linearly scale.
throwaway7783 2y ago
Most products can be built with mediocre talent. But no one actively goes after mediocre talent. And yes, startups are more sensitive to this, I really had to let go mediocre people because it affects everything. Throwing meat at the problem for long enough time really screws up the product. Even at a very large company that I worked for, innovation ground to halt after a decade of this thinking, because systems that started simple enough, got complex over time in part because of market and primarily because of mediocrity. Adding things became a nightmare, because we threw meat at problems for a long time. Maybe what you say has worked for your situations, but it really never worked for me over my experience, and it just was a downward spiral over time every single time.
- mlinhares 2y ago
  If workers are mediocre, management needs to be top notch to deliver great products. If management is mediocre, workers need to be top notch to deliver great products. The odds you'll land at a place that have both are vanishingly low. It also takes a lot of work, money and interest to turn a big ball of mud around and no one gets a prize for that, people get a prize for churning out features and bugfixes, so this is what you get, specially because most large scale rewrite projects are utter and complete failures.
  - throwaway7783 2y ago
    Each can compensate for the other only to an extent. We don't need top notch, we need good. Most large scale projects may fail, but we ended up assembling good people for all the rewrites. Five of the six projects were successful (in production with objectively better metrics). One failed due to underestimating the operational complexity of a piece of technology.

throwaway48476 2y ago

This is the truth that peoples egos can't seem to handle.

UncleOxidant 2y ago

Add in that in the search for the perfect candidate that has all 16 bullet point requirements you'll come across folks who have, say, a solid 13 of them, but they'll get passed over waiting for the perfect candidate to come around. Which can take many months... years even. In the meantime you could have been bringing up one of those 13-point candidates getting them up to speed on those 3 missing bullet points. And you'd likely have gotten to a desired level of productivity faster than by waiting for that perfect candidate while wringing your hands that there just aren't enough qualified people out there.

throwaway7783 2y ago
I don't think anyone is saying wait for the perfect candidate. No one is perfect and no one checks all the boxes. That would be a fool's errand. But most good engineers can differentiate between a good (not superstar) engineer and a mediocre/bad engineer in a couple of conversations. I really have not seen anyone optimize for a mediocre candidate, nor for a superstar. Superstars come by with luck or with tons of incentives (money, stock, tech or whatever is their itch).
- UncleOxidant 2y ago
  I've often seen this happen. A few years back I applied for a job at a startup where I checked a lot of the boxes, but not all, but some of the boxes I checked were difficult to come by - never heard anything back. Six months passed and I was contacted by them, would I be interested in interviewing? I was and I ended up getting the job. Later when I asked about the position being open for so long I was told by one of the people involved that there were folks who were waiting for the perfect candidate to come along and finally, after many months, they were convinced that the perfect candidate probably didn't exist. So yeah, there's at least one instance of it where I know for sure that's what was going on and I've seen others where I'll watch a job listing keep appearing for several months.
  - throwaway7783 2y ago
    So they learned their lesson and hopefully don't make the same mistake again. We are in anecdote land now (both yours and mine), I don't know what's more common. Behavior like that (waiting for long for perfect candidate) can cripple or kill businesses

Aperocky 2y ago

> Most problems are solved with time and not cleverness. Yes, because given time someone clever would have came in and fixed it. It's like doing push up in the elevator and believing that arriving at the 100th floor is due to doing push ups. The GE, IBM, Intel, Boeing are few examples that didn't believe in quality - and not just people apparently, and their problems aren't getting solved with time.

PittleyDunkin 2y ago
Eh, I just don't see it. GE and IBM and Boeing are solving the problems they want to solve. Management dysfunction can't be blamed on low-quality workers. Anyway, I'm a little reluctant to draw the parallel with Boeing because I simply don't know what kind of work goes into that sort of engineering. Maybe cleverness is a big part! > Yes, because given time someone clever would have came in and fixed it. I can't emphasize enough how much software engineers overestimate the value of their own cleverness. Bugs are fixed with persistence, in my experience—I've used "cleverness" to find only a handful of bugs across my entire nearly two-decade career. I don't want to say I'm "the best engineer on the team" or anything like that, but I dependably fix the bugs that are put on my plate regardless of how frustrating they are to crack, regardless of what tools I need to bust out to get the job done. Debuggers, printf, valgrind, core dumps, packet captures, profilers, repls, disassembly, whatever's necessary. But all of these take persistence to reach for and use to crack the case. Experience is a short cut, but that's a very different thing than cleverness, and you very directly pay for that experience. Not to mention if I see "cleverness" in a code review you're gonna bet I'm gonna comment and ask you to make it less clever unless that cleverness seems to neatly solve a problem. Even then, commenting is absolutely critical. Time, not cleverness, is the key. Hell, the joke used to be that being a software engineer is 80% googling. Now that barrier's been lowered even further with chatbots: you can literally ask it to find the bug, explain behavior, fix the bug, etc. It doesn't take much competence to correct the output. All it takes is not giving up when you see problems.
- Aperocky 2y ago
  Well everything you've written suggest to me that you're clever, or maybe that shouldn't be the word, but somewhere between smart and wise. And a lot of people aren't that.

devnullbrain 2y ago

>I think interviewing is just so broken it gives a false impression of quality issues in the labor pool. I've been in a team where hiring requirements have emerged through the filter of HR almost unrecognisable. Naturally, they're still objective requirements, so qualified candidates are filtered out before ever meeting someone who could judge if they're qualified. It gets noticed, but nothing happens. Of course it doesn't: you're stepping on important toes. That's how it tends to work. Candidates are filtered out by non-technical staff, including openly using programs that filter out CVs missing keywords. In smaller companies, this even gets farmed out to third-party recruiters that have poorly aligned incentives. How can we know if candidates are qualified? We never see most of them. It's hard to imagine many things worse for productivity than bad hiring processes. But it's all just accepted.

dml2135 2y ago

Screw the company -- sure, maybe they can build a product with mediocre talent. But I don't want to work with mediocre devs, because they make my life harder. I'd much rather wait for someone I want to work with, than hire the first person that is "good enough".

srj 2y ago

> I think people seriously overestimate the difference engineer quality makes. Most products can be built with mediocre talent. I'm sorry, that's the truth. We all love to have strong opinions on who we should hire and I say "almost anyone, just throw meat at the problem". Most problems are solved with time and not cleverness. I'm surprised that your experience here is so different from mine. The best engineers I've had are capable of things that the average to below average ones could likely have never achieved, even with an order of magnitude more time. I don't think it comes down to cleverness as it does inventiveness. There are dots that great engineers can connect that often nobody else could spot. They also need less process, and a large number of people with all of the coordination overhead does not linearly scale.

throwaway7783 2y ago

Most products can be built with mediocre talent. But no one actively goes after mediocre talent. And yes, startups are more sensitive to this, I really had to let go mediocre people because it affects everything. Throwing meat at the problem for long enough time really screws up the product. Even at a very large company that I worked for, innovation ground to halt after a decade of this thinking, because systems that started simple enough, got complex over time in part because of market and primarily because of mediocrity. Adding things became a nightmare, because we threw meat at problems for a long time. Maybe what you say has worked for your situations, but it really never worked for me over my experience, and it just was a downward spiral over time every single time.

mlinhares 2y ago
If workers are mediocre, management needs to be top notch to deliver great products. If management is mediocre, workers need to be top notch to deliver great products. The odds you'll land at a place that have both are vanishingly low. It also takes a lot of work, money and interest to turn a big ball of mud around and no one gets a prize for that, people get a prize for churning out features and bugfixes, so this is what you get, specially because most large scale rewrite projects are utter and complete failures.
- throwaway7783 2y ago
  Each can compensate for the other only to an extent. We don't need top notch, we need good. Most large scale projects may fail, but we ended up assembling good people for all the rewrites. Five of the six projects were successful (in production with objectively better metrics). One failed due to underestimating the operational complexity of a piece of technology.