
How to Fix the Tech Hiring - fagnerbrack
https://medium.com/@fagnerbrack/how-to-fix-the-tech-hiring-f56ae8192d8c
======
marcinzm
The article basically says, as I'm reading it, that it's good to use the
perfect technical solution to a problem. However that is a very short sighted
and narrow look at software engineering. Software engineering is a team
effort, a business effort and filled with unknown unknowns.

If you've written everything in X then ensuring that your next project is also
in X (even if X isn't perfect for it) has many advantages. Your bus factor is
high since your whole team is familiar with the technology. There are fewer
unknown issues that you'd hit versus a new approach. You'll be able to re-use
already written code so getting things running will be faster. There'll be
fewer drawn out arguments and discussions on technology choice at every
juncture. There will be more eyes able to properly review the code and choices
made.

Hiring and overarching technological decisions are as much about business as
technology. I've seen many engineers hired who want to rewrite everything in Y
because they're not familiar with X. The business gain of it is negative but
they still push for it.

I'm not saying that hiring only X is the best choice all the time but rather
that a middle ground based on the specifics of the business is necessary. A
flat out decision to never hire explicitly for X is as blind as one to without
thought always hire for X.

~~~
convolvatron
the article isnt suggesting you should hire people who only know a different
framework from the one you are using, but that you should hire people who are
capable of being productive in all sorts of frameworks.

~~~
WomanCanCode
How do you measure that? How do you know that someone will be capable of
working in any 300 different frameworks?

~~~
Frost1x
If they've used a variety of frameworks and worked on a variety of different
projects with varied architectures, it's pretty easy to assume they're not
only willing but capable of learning new things. I can pickup pretty much any
framework in any language and start utilizing it, but I can assure you it will
take me at least a few weeks of learning and using examples/templates to get
in the groove of things and a month or so to start really getting into
leveraging capabilities. If it's a terribly designed framework, API, or very
oddly structured language, it may take a bit more time--or if its leveraged in
a massive codebase you need to understand that's poorly documented (were no
longer talking about the framework itself though).

Of course if you're trying to measure how quick someone can pickup a framework
or if they're capable of "hitting the ground running" on arbitrary framework X
with arbitrary existing codebase Y with deliverables/output that assume no
learning curves while having no desire investimg in long term talent
retention, this approach isn't for you. If minimizing time to market is your
main goal, this approach isn't for you. If you want to produce something
different where time to market can still reasonable but a bit slower, this
approach may be for you.

~~~
nobodyandproud
This is resume padding and a red flag.

The right tool for the right job AND shop, or you end up with a major
maintenance nightmare.

------
VRay
Tech hiring is fundamentally flawed much more than the author here thinks

[https://daedtech.com/programmer-skill-fetish-
contextualized/](https://daedtech.com/programmer-skill-fetish-contextualized/)

Even working on the core team at some of the world's most prestigious software
companies, most of the work I've seen has been completely doable by any
competent programmers who can communicate with their teams and organize their
own time. I've only run across maybe a single bug per 3-4 years that actually
required a superb coding prodigy to fix.

Interview coding tests select for gladiators when these companies actually
need legionnaires

~~~
dano
I'm going to borrow your gladiators vs. legionnaire analogy. Legionnaires need
leaders and leaders need followers. There's something in those thoughts.
Thanks.

------
dasil003
So polyglot > framework dev. Great, I agree with that.

I don't think this even scratches the surface of what's hard about tech hiring
and where the flaws are in practice.

~~~
Bartweiss
Yep, I think this is either ignoring the main problems or mistaking a symptom
for the disease. Certainly, people try to hire for "Ember gurus" or "10 years
experience in Swift" or whatever else, and that goes poorly. But it's one of a
dozen serious problems with tech hiring, and not near the top.

If anything, I think people end up hiring for framework experience _because_
tech hiring is hard and broken. If you're relying on outside recruiters who
can't read a resume, much less evaluate somebody's past projects, then hunting
specific framework keywords at least gets you relevant candidates. If your
interview sensitivity is terrible, then you can't accurately gauge whether
someone will pick up your language/framework quickly, so it makes sense to
only hire people who've already proven they understand it. And if your
onboarding and codebase are a mess, you'll want people who know the language
well enough to e.g. troubleshoot a broken build on their own.

Hiring people who already know everything isn't the problem with tech hiring,
it's a weak effort to paper over the more fundamental problems.

~~~
nobodyandproud
The closest profession to software is law.

It’s not a problem, once firms realize what business problems they need to
solve.

~~~
Bartweiss
This is a good point, although I'm not sure how it transfers cleanly. Hiring
lawyers seems to have two elements lots of people desperately don't want to
import to hiring software devs.

First, the credentialism in law is extreme and getting worse. It used to be
that most states would at least let you sit the bar freely; these days
becoming "self taught" or even "correspondence course" lawyer is usually
prohibited by law. This is sort of understandable given the stakes of
malpractice and the difficulty of judging quality, but it also implies that
the bar isn't an adequate measure of skill, and creates a limited supply of
law degrees at extremely high prices.

Second, the desirability of lawyers is basically exponential: there are
schools with graduates commanding $1,000/hour rates while other capable
attorneys go unemployed. For law, this again makes some sense: lawyer-hours
are not usually additive, most clients can't judge what they're getting, and
buying a bad legal 'product' is usually revealed in the form of a massive
expense after it's too late to fix. Software has shades of this with the "10x
programmer" stuff, but only security and maybe architecture design actually
reproduce the 'too late to fix' issue. Paying a CMU programmer 10x what a
state-school programmer gets isn't usually going to be an effective strategy.

Hiring programs like lawyers would probably lead to fewer screwups, but I
think it would also waste a huge amount of money and expertise. And I'm not
sure that splitting the difference is a coherent option.

~~~
nobodyandproud
I never said the hiring of lawyers is a good example :)

The practice of law and law school are two completely separate things.

This is something that I think Med School has done correctly. Once you finish
school, you must do your residency and the school provides this. This is whete
you actually learn how to practice your profession.

Law school, from what I understand, doesn’t provide this crucial step.

Software development does not either, and perhaps this is one of the problems.
School teaches the fundamentals, but it doesn’t provide the necessary
tradecraft training.

So the only metrics to go by are buzzword tests, or arbitrary algorithm tests
divorced from the actual job.

It’s the rare interview where they test CS fundamentals—which most people
should remember, unless they ask for implementation—and coding best (and
worst) practices, which is currently lacking.

------
sleepysysadmin
Last time I did 'HR' training. They told us all about how to judge people.

You can't hire someone who doesn't have a firm handshake.

You can't hire someone with typos on their resume.

You must have that university degree right.

You can't hire someone who is a convict.

You can't hire old people.

So after HR has already eliminated all these people. They are left with the
bottom of the barrel people who are apparently superman with no character
flaws.

Then we wonder why we can't seem to hire anyone.

~~~
benbristow
"You can't hire someone with typos on their resume."

This one I can kind of agree with. Should really double check before you send
something like that around. Spell checkers exist.

~~~
hrktb
spell checkers are not magic though, and can be fighting with auto-complete
and other auto correction processes.

I think it's more common than ever to be typing correct phrases in English be
have it replaced by something else matching the user's native language, or a
more common word that just doesn't fit in the phrase that was written.

Of course it's a good sign if someone reread everything before it gets
submitted, but otherwise having some minor typo shouldn't stop a developper
for instance from getting an interview IMO.

------
blunte
This is good advice. However, unless it can be rewritten to appeal to a CFO,
the important guidance will never reach the people who define the positions
and filter candidates.

Executive management needs to understand WHY fundamental/generalist skills are
more valuable than specialized skills (or at least are of comparable value
except in rare cases). And the "why" that most executives understand is
"because it results in more profit long term".

Few executives or hiring managers are technically experienced enough to really
know what skills are required to do a certain job. Since they know they don't
know, they make effort to be very specific and target the technologies (and
frameworks) that the person they are replacing was known to be using. If it's
a new position, they have selected a popular stack based on what other people
in their industry are using. In the mind of the manager, it makes practical
sense to aim for exactly what they believe they need.

Successfully delivering this message to the right audience would require a
great and charismatic communicator. Unless this leader is already famous, I
don't see the advice having a lasting impact. Heck, even if... I still don't
expect lasting impact. Companies have been getting by ok (measured by
executive compensation and shareholder value) so far, so putting in the extra
effort and risk for possibly a better long term result isn't likely to happen.

There is a bright side to this situation: some very talented people who don't
fit the current hiring process may go off and do something on their own (or
with others like them), resulting in great new things. In fact, that's usually
how innovation happens.

------
arnvald
> Hire people with fundamental skills, not framework or technology skills

I think this is the most important advice for employers. Companies often hire
people that have experience in as many tools in their current stack as
possible. Few of them realize that in 5 years their stack can be entirely
different, and that more important than knowing current tools is the ability
to learn the new ones.

~~~
xtracto
The problem is that this is less and less feasible. More and more I see
candidates that come just from "Angular Bootcamps" and similar who do not know
fundamentals. Even people with a degree struggle with them.

Following Sijin´s competency matrix, most of the people I interview fall in
the first level, not really knowing much about stuff.

------
hacknat
This article is basically a complaint masquerading as advice.

> There once was a company with 34 employees and 34 different titles

Don’t be coy with us ;) We know who you’re talking about.

Presuming that all tech hiring is broken, and that your article is for people
who think tech hiring is fine, without any data to support your claim is going
to get your advice ignored.

~~~
granshaw
Who _were_ they talking about?

~~~
hacknat
Themselves.

------
Nasrudith
He seems to miss a point about the "meta" of hiring when avoiding framework
experience vs design.

Namely that how canidates advertise and actual talent and abilities may not
align fully. It doesn't make sense to emphasize their bests if nobody is
interested or it is taken for granted. Besides they have to try to play to
more than you and filtering on arbitraries is how you miss talent, boost
expenses and increase delay.

------
raxxorrax
Meh, please just don't tell me why you are going to change empty phrases for
hiring processes again, just give me the list of pop-pleasantries.

I get it that you don't expect me to be honest and I can use words entrenched
in so much honey that even your mother will get diabetes.

------
cat199
how to fix the superfluous use of 'the'.

but also: 'API Influencer' as job title? wow.

------
oaiey
It is easier to train the technology than the business. Understanding the
business and it's needs is usually more valuable than a tech stack. I do not
see that being mentioned at all.

------
sureaboutthis
My example of how crazy things are nowadays.

Long ago, I designed and developed a medical computer for a well-known
manufacturer. If you walked into any eye doctor or surgeon today and mentioned
its name, they would know what it is.

I started my own company but over the past five years, I would consistently
see three former co-workers from that same company. I told them I was thinking
of selling out and--jokingly--said I would re-apply for my old job. The
response was always positive. "You should!", they'd say, "Put me down as a
reference!".

Last October, I sold out. Last January, I ran into one of those co-workers.
He's now a project manager. The other two co-workers were actually my bosses,
one of whom is now a "Fellow". "There's an opening," he said, "Come apply at
put me down as a reference."

So I did. Never heard anything back. I called my friend who talked to the
"Fellow". That guy gave me the email of the headhunter who was now in charge
of all hiring and told me to mention all three of their names. The headhunter
replied and told me the job was, essentially, working on the same product I
designed and would I be interested in working on a new version of that.

So I sent my resume which shows that I've been working on almost the exact
same thing and that I had worked for that company for seven years on that
exact same product and have three high level managers and former bosses who
all encouraged me to apply for that job.

Never heard from him.

My former boss, who was the Director of Engineering and is now a "Fellow" is
actually now retired and only works there part-time. He said he has no say
into how they do things now and all hiring is done through the headhunter. The
project manager is in a different department now so they don't care what he
thinks. The other engineering manager also retired and, apparently, no one
cares about his thoughts either.

~~~
nobodyandproud
The HR person probably gets a kickback by hiring from specific headhunters.

Good luck proving it, though.

