[gatinsama]

There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who understand what they are doing. And then... the 100xers like Linus. It's pyramid-shaped. If the author is referring to people who understand what they are doing as "normal" engineers, granted, you can make a great team out of these... but how do you find many of them in the first place without bumping into the others?

[Juliate]

Not of that opinion.

I met great engineers or developers who won't even care to answer a fizzbuzz-type question.

I met terrible ones who had top technical and math capabilities but little agency at pointing what is relevant or not in their work.

Even considering it's pyramid-shaped is excluding all the externalities that make one person thrive in some contexts, and just flat or negative in others.

Take a top performer, if he's not in the right position at the right time, nothing will happen. Conversely, someone not so good, but being in the right place at the right moment may nudge things in the right direction.

That's exactly around what I understand the OP develops in her article: engineering, building is a work of teams, not individuals. In a team, people come and go, roles are different, shift with time and progress. "Terrible" people become "excellent" and the other way around, that's life.

Perfect performance all the time isn't even what we require of machines, because then they (or systems they relate to) break faster. Why would one have the same expectations with people?

[rachofsunshine]

"There exist exceptions to a trend" does not mean the trend is not a valid proxy (see [1]), and "refuses to do fizzbuzz" is different from "can't do fizzbuzz".

I run a technical recruiting company, and we ask candidates a question like [2] on our interview (EDIT: we ask other stuff too, this is only part of it). It's not exactly fizzbuzz, but it's really not far beyond it. A candidate we interviewed just a couple days ago took that problem and couldn't even complete the first step. This is the equivalent of asking someone applying for a job as a statistician what the distribution of the sum of two normals is, or asking someone applying for a job as a con-law lawyer what the fifth amendment is, and having them go totally blank.

Is it conceivable that they were just having a rough day and their brain hiccuped really badly? Sure, I suppose. If we did ten thousand interviews, we'd probably have at least one person who is objectively great perform that way.

But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.

-----

[1] https://news.ycombinator.com/item?id=43006330 [2] https://www.otherbranch.com/shared/practice-coding-problem

[Juliate]

Fine with you for your tech candidate question, if that works for you.

Maybe I never encountered your perspective; in 20 years in the industry, in about 10 significant software prod/consulting companies, we never outsourced hiring or pre-hiring. From my experience and perception, minor coding tests are a hiring filter than does not gives good results, for both sides of the interview.

You want to hire junior candidates? that test is fun and maybe ok an indicator. Having them live comment/describe/solve existing pieces of code is much more effective and fast. They will still demonstrate ability once on the job, that's what juniors are for.

You want to hire experienced (or even senior) candidates and filter for domain knowledge? 1. Filter on experience & referrals. 2. Conversations: same approach as with the juniors, but much deeper and wider, relevant to your domain. 3. Call at least one reference to counter-check.

A generic fizzbuzz/minesweeper (remember also "code a functional basic blog engine with comments in 30min" back in 2006) coding test demonstrates (in my very subjective and limited opinion) laziness and kind of a lack of interest in the candidate from the hiring person/company.

I understand that when you screen 1000s of people, it gets massive and more basic filters may apply, at least at first contact, though.

> But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.

I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.

[rachofsunshine]

> You want to hire experienced (or even senior) candidates and filter for domain knowledge? 1. Filter on experience & referrals. 2. Conversations: same approach as with the juniors, but much deeper and wider, relevant to your domain. 3. Call at least one reference to counter-check.

The reason I don't believe in (1) is that the candidate I described in my previous post claims nearly fifteen years of experience, some of it as a lead, and completely bombed our entire interview. Referrals are another matter (and they are indeed an excellent channel when you can get them), but they tend to be pretty low-volume - if you're hiring from the general public at all, presumably referrals didn't get you what you wanted.

By the same token, the majority of people we've placed so far were people whose resumes didn't particularly shine - but who turned out to be very good engineers when given an opportunity to actually work on a problem. (That isn't just my opinion, it's the opinions of the companies that hired them.)

For (2), I agree. We do do that as well (coding's one of three parts of our interview, not the whole thing).

For (3), have you ever had a reference give a negative review? A lot of companies make it outright policy to do so, and iirc there are legal restrictions on employers doing so in a lot of places. I wouldn't trust that with any reliability (although it's still good practice 'cause it's cheap).

> I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.

Of course soft-skills matter! I never meant to imply otherwise. But soft skills will only get you so far if you don't know how to do the fundamental responsibilities of your job.

[Juliate]

Thanks for the insights.

As for (3), I never got _negative_ reviews, rather confirmations or hints that confirmed what emerged through the interviews and either lead us to stop the process (rare, but happened) or helped adjusting the position and onboarding to better fit the hire.

[arkh]

You also have force multipliers. Which can be some managers: people whose presence on a project will make decent software engineers produce like a 2x one.

[atoav]

To start with, there are engineers who deserve the title engineer. You are probably better of to hire a former civil/electrical engineer that can fizz-buzz than someone that can just fizz-buzz.

Coding and productivity are one thing, but engineering in the end is a lot about having a certain awareness of the impact your technological choices have on a project both in the short and long term. I'd rather take someone who has this awareness, than someone who hasn't, even if the person in the latter category would be slightly better at coding.

[alecco]

Agree. The required abilities multiply rather than add so the right tail extends much further than a normal distribution. The gap between median and top performers is extremely large.

[alecco]

Please read that the right way. Deliberate practice compounds exponentially. Those extra hours refactoring, contributing to OSS, or mastering systems design create 10x impact through learned architectural intuition that median devs never develop. Your new skills will go a long way.

[datadrivenangel]

The 10x programmer is based on research cited in the Mythical Man Month, and there the most productive programmer was 10 times more productive than the least productive, as far as time taken to complete a coding task. The most productive were ~3x faster than the mean/median programmer.

[interludead]

There's a huge middle ground between "can't FizzBuzz" and "100x Linus-level genius," and that middle is where most functioning engineering teams live

[gatinsama]

Yes, but it's way more on the can't fizzbuzz side. Our view is skewed because of the people we work with. If you have an extreme Pareto distribution, talking about "normal" is not helpful.