
The software industry's greatest sin: hiring - nsainsbury
https://www.neilwithdata.com/developer-hiring
======
jackcosgrove
Technical interviews were once seen as a breath of fresh air.

You can be a nobody without connections or degrees and if you can prove you
have skills during an interview process you may be hired.

Contrast this with other hiring processes which are more irrational, like med
residency match, investment banks favoring "target school graduates", law
firms favoring "top 14 graduates", etc.

I think whiteboarding is dumb and I'm increasingly unwilling to go through
with it. That's a hurdle.

But in many careers the hiring processes are walls, as in there is 0% chance
you'll get hired. Because you don't know someone, because you didn't go to the
right school. The barriers have little correlation with ability to do the job,
and more importantly after some milestone has been crossed it's impossible for
you to improve your chances.

~~~
earthtourist
It is true that you can succeed well at tech companies without a degree from a
top school. Class, race, gender, sexual orientation are not barriers to
success. That's the positive thing.

The negative thing is that most tech companies heavily favor "top school"
candidates and actively recruit for them. They would rather higher someone
provably less qualified from a "top school" than someone else. They track and
boast about how many "top school" candidates they hire.

Tech companies are hugely biased in favoring the upper class. And then they
misguidedly try to pay a recompense for this unethical bias by discriminating
on the basis of race in favor of "unrepresented minorities". Of course, they
still really want those "URMs" to come from a "top school".

Their goal is to counter their active classism through active racism. As if
they somehow cancel each other out.

~~~
disgruntledphd2
One of my previous bosses (at a large tech company) moved over to the US and
was asked to hire 9-10 people in a quarter.

Everyone said it was impossible.

She went to LinkedIn, found people with the right skills (strong data and
ability to communicate), and had a massive fight with HR because none of the
candidates came from "top" schools.

She won the argument, and all of the hired candidates did a great job.

People (especially US people for some reason) seem overly obsessed with the
university someone attended, when it doesn't seem to be that predictive of
workplace success.

~~~
namdnay
> especially US people

definitely not. french companies actually have engineering salary tables
depending on your age and university

~~~
hunterwerlla
That sounds interesting, is there an english source to read about that?

~~~
namdnay
I can’t find anything concrete, each company does it internally. There are
some articles where they publish the starting salary based on your
university’s “rank”. Try google translate on this:
[https://www.google.com/amp/s/www.lexpress.fr/emploi/les-
atou...](https://www.google.com/amp/s/www.lexpress.fr/emploi/les-atouts-pour-
bien-negocier-son-premier-salaire_1325184.amp.html)

It discusses how there are 6 ranks for business schools, and your salary for
the first N years will be based on that. Same for engineering. It’s funny that
one of the companies is proud to declare that they can move salaries by “up to
5%!!!” based on the candidate themselves (whereas the school can make a 20-30%
difference...)

~~~
hunterwerlla
Google translate worked really well on the article, thanks! That's kind of
insane that the school you went to can give you a raise from 30k euro to 40k
euro despite having to do the same job.

------
asn0
We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week
interview process was a lot of effort for pretty mixed outcomes. We realized
an interview can't really answer the most important questions: how a candidate
works, and what's it like to work together.

So we added an option to interview by way of a paid trial period (work part-
time nights/weekends for a few weeks with the hiring team). Figured maybe some
people might prefer that, but probably wouldn't be feasible for most.

Every candidate since has chosen that route, with very good outcomes - so far,
everyone who did well in the trial period has been a good hire. Some of our
best hires did not interview well (and would not have been hired under our old
process), but were outstanding in the trial period. And, a couple candidates
interviewed so well we almost skipped the trial period, but they struggled to
complete even simple tasks during the trial.

We've now optimized interviews for that process, where the decision is
primarily about whether it's worth moving to a trial period. That usually only
takes a short screening call and a 1-hour call with the team (we're a remote
team, even before quarantines).

BTW, if you'd like to experience this first-hand, we're hiring -
[https://news.ycombinator.com/item?id=22753515](https://news.ycombinator.com/item?id=22753515)

~~~
bleah1000
I'm sure you get good outcomes from this, but I'd be willing to bet you are
completely weeding out whole classes of people. For example, most parents or
caregivers (single or otherwise) don't necessarily have the time for this.
Senior engineers are less likely to want to go through this.

I would guess that most of your hires are single young people. And you are
already kind of teaching them to work nights and weekends, which sounds like
you are, again, choosing people who would not have a problem with a bad work
life balance.

I also wouldn't be surprised if your process isn't teetering on the illegal
side. Not on purpose, but it might be accidentally favoring or disfavoring a
race/gender. Probably not enough to get you in trouble though, because those
things are hard to spot. And unless your company is really big, probably
nobody cares.

~~~
clarry
I think I'd like this even if I were married, as long as the trial period
isn't too long and interview experience indicates that I should have a good
chance of landing the job.

Contrast with the alternative: I'm a senior, considering switching jobs, but I
have no real way to evaluate the potential new employer beyond word-of-mouth
and interview experience. What if it turns out to be a place I don't like and
I just gave up my former position for something worse?

Working a few evenings & weekends (and getting a little extra $$) to evaluate
the new company sounds like a superb way to gain the confidence and jump ship
without regrets. In best case, I get a new job I like. In best case, I get
some extra money and keep my old job which is better than the new one proved
to be. Win/win? What's the worst that could happen?

~~~
asn0
When we offer the trial option, this is the #1 reason most people are
interested in it. They are just as concerned about evaluating us, as we are
about evaluating them.

------
dahart
> Developer hiring is broken

This seems to be a pretty popular opinion. It totally might be right, but it’s
not my own experience, so I have a serious question because maybe I don’t know
what’s happening out there with most hiring today - what are the broad-stroke
outcomes that demonstrate that hiring isn’t working? Are there statistics that
show that hiring has problems? All of the reasons given in the article are
claims without evidence, nor objective comparison to hiring for other
industries. When looking for jobs, I’ve never been evaluated on IQ or code
alone, it has always come with communication and personality and culture fit
evaluations, among many other things. When hiring, my own team does everything
this article claims isn’t being done. So I might be completely unaware of the
major trends out there... how can I see those trends from where I sit? Are
people not getting jobs who should, has there been high unemployment? Are
companies not able to hire people? If hiring is broken, what are the problems
it’s causing?

> It's a disguised IQ test

It is amusing to me that many blog posts and comments around here argue for
exactly that under the same banner ‘hiring is broken’. Lots of developers are
frustrated about being evaluated by how well they communicate and not by their
code. Lots of people here complain about in-person interviews and tests and
argue that take-home coding should be the norm, or that coding tests should
not used at all.

~~~
josephg
I'm a software engineer working at a company in the hiring space. I've done
over 400 technical interviews in the last year alone, and ... this is a hot
take, and not the view of my employer, but I think developer hiring processes
are fine (At least, at most mature companies.)

There's a problem at the moment in the market that there's a huge amount of
pent up demand for senior developers. The market has responded with bootcamps
and the like, and we have a ton of junior devs with very little knowledge and
experience pouring into the workforce. The sad truth is that most devs fresh
out of collage or a bootcamp aren't valuable enough to be worth hiring at
large tech companies like Google. Most people who apply to any hiring role you
advertise won't really be able to program effectively. (And if they can, they
won't know the conventions of the language they use, they won't know anything
about security, they won't be able to read code others write in order to debug
it, etc etc.).

Programming is hard. It probably takes about a decade of practice to become
good at it, and I don't think schools have figured out a replicable way to
take someone off the street and teach them programming yet. (For example, most
fresh grads have never had to read the code another programmer wrote. Imagine
teaching people how to write without teaching them how to read!)

I think there's lots of angry junior folks out there saying "Hey, I can write
a simple for() loop in python, and lots of people are hiring - but I apply to
lots of jobs and keep getting knocked back! The hiring process must be
broken!". And a few angry senior engineers out there saying "Why do I have to
keep writing fizzbuzz? Its like I have to prove over and over again that I can
program at all!".

Of course, nobody wants to admit that the reason they failed their 6th
whiteboard interview in a row is because they aren't very good at system
design. And the reason for that is that their collage didn't teach them any
system design skills, and they have no experience, and they never learned how
to use words to communicate technical ideas. And ArbitraryProductCo doesn't
have the runway to train you up.

Of course there's the occasional person who is really skilled and somehow
still manages to fail programming interviews all the time. But if the goal of
a technical interview is "make sure we don't hire anyone who wouldn't be
effective at the job", I think they're fit for purpose. I think the real sin
is that we're afraid to tell people they aren't very good at programming yet,
and we use technical interviews as a scape goat.

~~~
Apocryphon
> I think the real sin is that we're afraid to tell people they aren't very
> good at programming yet, and we use technical interviews as a scape goat.

So does this mean that programming education is broken? That companies should
invest more in training? That bootcamps should revamp what they teach? That
there should be industry standards for what programmers at different levels
should be expected to know?

The most maddening thing about interviews imo is the opacity. There's always
uncertainty about where exactly things went wrong, and how it should be fixed
next time. It's almost a meta-engineering problem of its own. And it's a
metaphor for the lack of software engineering standards.

~~~
lmm
> So does this mean that programming education is broken? That companies
> should invest more in training? That bootcamps should revamp what they
> teach? That there should be industry standards for what programmers at
> different levels should be expected to know?

Programming education is broken. I did one year of computer science at one of
the top universities in the world (switched into mathematics after that), and
I'd see that course as useless if not actively negative. The only way of
learning that I've seen really work for anyone (myself included) is more like
a craft apprenticeship, working closely with someone more experienced. We
shouldn't be surprised that that produces widely different approaches.

Frankly the field isn't mature enough to have standards. If you tried to set a
professional exam based on today's best practices, in five or ten years the
answers would mostly be wrong. We still don't know the right way to write
software. Million-dollar systems still come with laughably simple bugs.

What does the interview process look like for a craftsperson? That's probably
the best we can expect from a field as unsystematic as ours. The one thing
that strikes me is that in creative fields it's normal for people to show a
portfolio of past (client) projects, whereas in software past employers
usually keep all copies of your code. I have no idea how we'd go about
changing that norm though.

~~~
josephg
> What does the interview process look like for a craftsperson?

Welcome to my shop. Here's some wood. Make a chair!

In most of the interviews I conduct, I get the candidate to write follow a
spec we've written and some code. And I get the candidate to debug a program
with some failing unit tests. About half of the candidates I interview fresh
out of school have no idea how to get started debugging a program they didn't
write. You need to do that just about every day at work, and its usually not
even mentioned at school.

But I've worked as a teacher too. I will move heaven and earth for my
students, but in my darkest moments I think taboo thoughts. Maybe IQ is a real
thing, and maybe some people just don't have the neural hardware to ever be
good at programming. If thats true, we do those people a huge disservice. We
steal years of their lives and tens to hundreds of thousands of dollars
training them in a skill they can never master. I'd love to see the stats on
how many people graduate from a CS program, try but never find reliable work
in our industry. I worry the numbers might be damning.

A few months ago a candidate I interviewed asked for feedback at the end of
the interview. He wanted to know I recommended that he practice so he could
improve. I said he should pick an opensource project on github - preferably
something thats not too big and look through the issue tracker. Pick a simple
looking bug and try and fix the bug and submit a PR. His whole manner changed
after I said that - the idea of doing that was so incredibly daunting to him.
But that right there? More or less, thats the hiring bar. As an interviewer
I'm trying to answer the question "If I hire you, can you do the work?". Read,
think, understand, modify, write code, communicate it to your team. Thats the
work and thats the bar.

~~~
jaspax
Both of your "taboo thoughts" seem blatantly obvious to me, and not especially
taboo. Intelligence obviously exists and some people have more of it than
others, even if the metric "IQ" doesn't perfectly capture it. And yeah, some
people are not cut out to be programmers. Why are we pretending otherwise?

~~~
Apocryphon
I find that there's a borderline self-contradictory aspect of hacker culture.
While we romanticize the concept of the 10x programmer, which is an individual
of genius, our culture also stresses the concept of autodidacticism. Teach
yourself to code. Just use MOOCs. Build it yourself. Hack on an open source
project. So there's this tension between valorizing the inborn superhuman and
the belief that it's possible to reach greatness- though perhaps not 10x
greatness- by pulling yourself up by your bootstraps.

In a way, this is mirrored by the organizations themselves. Startups who make
the right moves, and work hard through grit and 60-hour weeks, can become
unicorns. Also some startups are led by visionary founders and cannot fail.

So all of this, buttressed by real world labor demands, create incentives for
people to try to become programmers. Even those who aren't "cut out to be
programmers." Our increasingly cutthroat and unequal society also incentivizes
people shifting to programming as a safe career choice. "Learn to code."

I don't know how we can stop "pretending otherwise." Tech companies continue
to complain about the engineering talent shortage. Bootcamps and online
courses continue to promise people that they can become that talent. There
aren't any agreed-upon industry standards by which to exclude people who truly
aren't fit for it. FAAMG has infinite money and power in the industry to
continue their entrenched practices. Most startups cargo cult the leading
megacorps' processes. So instead, candidates are encouraged to continue
grinding Leetcode and apply, apply again.

~~~
lmm
> I find that there's a borderline self-contradictory aspect of hacker
> culture. While we romanticize the concept of the 10x programmer, which is an
> individual of genius, our culture also stresses the concept of
> autodidacticism. Teach yourself to code. Just use MOOCs. Build it yourself.
> Hack on an open source project. So there's this tension between valorizing
> the inborn superhuman and the belief that it's possible to reach greatness-
> though perhaps not 10x greatness- by pulling yourself up by your bootstraps.

Those seem like orthogonal aspects. If we stressed the idea that you had to do
(say) a 4-year degree at a great university, or something akin to the bar
exam, would that be any more compatible with the idea that some people are 10x
better than others? If anything I'd say the opposite: we'd expect most of the
Harvard graduating class to be on roughly the same level, it seems a lot less
wild that some self-taught people could be 10x better than others.

> So all of this, buttressed by real world labor demands, create incentives
> for people to try to become programmers. Even those who aren't "cut out to
> be programmers." Our increasingly cutthroat and unequal society also
> incentivizes people shifting to programming as a safe career choice. "Learn
> to code."

This happens in every field though? You get people who are desperate to become
a doctor and apply to med school year after year, despite being completely
unsuited to it. You get people who insist they're gonna make it as an
actor/musician/comedian and spend decades working crappy day jobs so they can
live where the action is, when really they'd be better advised to pick a
career they're good at.

> I don't know how we can stop "pretending otherwise." Tech companies continue
> to complain about the engineering talent shortage. Bootcamps and online
> courses continue to promise people that they can become that talent. There
> aren't any agreed-upon industry standards by which to exclude people who
> truly aren't fit for it. FAAMG has infinite money and power in the industry
> to continue their entrenched practices. Most startups cargo cult the leading
> megacorps' processes. So instead, candidates are encouraged to continue
> grinding Leetcode and apply, apply again.

Well, if we told people outright that programming is a matter of IQ, and gave
an actual IQ test rather than an IQ-like test in interviews, that might help
some people realise it's not for them. You're right that what catches on in
the industry is largely a function of what the most successful companies pick,
but ultimately that list of top companies is not static and we'd hope that
companies with better hiring practices will (eventually) rise to the top.

~~~
Apocryphon
> If anything I'd say the opposite: we'd expect most of the Harvard graduating
> class to be on roughly the same level, it seems a lot less wild that some
> self-taught people could be 10x better than others.

That's not the point I was trying to make- I'm saying that in programming we
both prize talent born of nature, and skill honed by nurture. (Though
admittedly that may exist in many other disciplines.) Because of the latter
emphasis on grit, hacker culture encourages self-improvement and going beyond
the capacities one started with. That dogma of self-improvement goes against
the notion that people are not cut out to be programmers.

Though of course, this could also be a marketing ploy for recruitment on
behalf of management: "Anyone can code, you should learn to. But we only hire
from the best." By encouraging an increase in talent, they have a larger labor
pool to choose from (and potentially undercut wages), while plucking out the
few that can pass their interviews.

> This happens in every field though?

To some degree, but the details vary. Medicine or law used to be seen as safe
secure careers into the (upper) middle class, but doctors are limited through
the AMA, and currently law is a notoriously difficult and costly profession
with dwindling prospects. Entertainment and the arts is universally known as a
risky proposition. We're talking about software, which has had the reputation
of being the current surefire path to a stable, even successful, career, for
at least the past two or three decades.

> Well, if we told people outright that programming is a matter of IQ, and
> gave an actual IQ test rather than an IQ-like test in interviews, that might
> help some people realise it's not for them.

Leaving aside the legality of using IQ tests to exclude candidates, that opens
up the questions of _if_ there is a direct correlation between programming
good software and IQ, why programming out of all STEM fields should focus so
heavily on IQ, and why all of those other technical and engineering
professions don't need to resort to IQ tests for hiring.

------
Drecula
Given HN's demographics, I'm probably older than most here. I've worked with
and personally invented quite a few great products, usually spanning Product,
UX, and Engineering work. It's a joke to pretend ageism isn't a thing, and
asking questions that only a recent CS grad is going to remember is not a
tacit form of filtering for age. There's not many technical questions a fairly
smart, non-lazy person with some experience can't either find with a Google
search, a conversation with a peer, or a bit of hacking to figure it out. It's
been a LONG time since I had to write the code to invert a binary tree, but
I've done stuff orders of magnitude more tricky and valuable than that
countless times, as have many others. What makes a great engineer? I've lost
count of how many times I've had to rewrite the code of many engineers who
aced the 'whiteboard shuffle', then wrote hopelessly over-complex and
unmaintainable garbage. Most of software engineering is not that hard from a
'learn the things or look them up to get stuff done' perspective. What's hard
is working well with others and consistently emitting tight, semantic, legible
code that's fun to look at and extend.

~~~
jiveturkey
You say that as if you were born perfect. As someone of elder years myself
(and not just by SV standards), what you are saying is quite obvious to anyone
with experience. But when you're young and know everything, it's not so
obvious. We too, were brave believers of complex == good in our youth. Well, I
sure was.

It's also important to learn by failing (aka learn by doing). Like parenting,
there are many things in organizational behavior that can't be learned until
you experience it for yourself. Few of us can be told "don't do that" and will
internalize it to the degree necessary, without experiencing personally what
happens when you do "do that". These people graduating from top schools and
going straight into FAANG are doing themselves a disservice of the worst kind,
by missing out on important organizational learning experiences.

On that note, I recommend everyone either get fired from a job, or work for a
company so bad you quit, at least once. I also recommend it at most once. :)

As for inverting a binary tree, with your experience you must realize that the
very large majority of applicants are poseurs. You need to filter them with
easy things like inverting a binary tree. Most companies need "doers" not
"thinkers". Even at the highest levels of pseudo-management (staff and above
IC), you really better be able to do this kind of easy stuff.

~~~
Drecula
I'm sorry if I made it sound like I was born perfect. That wasn't what I was
trying to convey. Yes, we learn by making mistakes, and I've sure made at
least my fair share of them. My point is that horking out algorithms on demand
is definitely not the same thing as being a competent software engineer, nor
is it particularly predictive of the likelihood of developing those skills.
Also, I measure my success by the people I've helped and the impact I have on
the business. For instance, figuring out how to eliminate 500,000+ lines of
code from a codebase strikes me as way more valuable than hopping about at a
whiteboard like a trained monkey. Ask better questions, get more impactful
employees.

~~~
jiveturkey
Agreed!! Sorry I didn't mean to accuse you of anything.

I share your criticism for poor interview practices. But not that basic
knowledge whiteboard questions are asked -- sadly, it's a requirement --
rather that most don't get beyond that. Or dwell on the classic "OMG how could
you not know this piece of trivia that we only learned here at our org after
12 years refining the solution".

Anyway I adore that kind of interview. It lets me know I don't want to work
there! I call those interviews successful. Most candidates (or at least most
discussion of interviews from the candidate POV) seem to think the entire
purpose of an interview is to prostrate yourself to the all powerful company,
that they may see you as worthy, oh master. It's the wrong perspective.

So while I share your criticism, I am not dismayed by it.

------
analog31
To the best of my knowledge, my workplace uses a fairly traditional hiring
process that's the same for hiring a programmer or a machinist: Resume screen,
phone screen, on-site, offer.

I have to say we do really darn well, especially given we're located in the
Midwest and supposedly the brightest programmers have fled to the hot markets.
One thing I like is that we get a range of ages, which is heartwarming given
that I'm over 50 myself.

The thing to do is look around at your colleagues and ask if the hiring
process is really broken. It may be that we've all been driven into a panic
about hiring, by the hiring industry.

~~~
thaumasiotes
> a fairly traditional hiring process that's the same for hiring a programmer
> or a machinist: Resume screen, phone screen, on-site, offer.

Some years ago, I was looking for a job, and an employed friend of mine sent
me a problem and said "this is our hiring challenge. Try it out".

I completed it, and she asked for my resume, and turned in both to whoever the
relevant person was at her company.

She then reported back to me "he said this is the best response he's ever seen
to the challenge, but we're looking for someone with more experience". I was
not contacted by anyone else.

And years later, when I ribbed her about this, she told me "he regretted that,
later".

I note that by putting the resumé screen first, you're committing yourself to
the idea that whatever you're looking for in the resumé screen is more
important than anything you might learn in the phone screen or the on-site. Do
you believe that? Are the phases looking for the same things? If not, is that
intentional?

~~~
stevenwoo
I did resume screening for about fifteen years for different small companies,
it’s first because if I phone screened everyone who sent an letter or email
expressing interest there would be no time for anything else and I would be
wasting a lot of candidate time when I could look a resume and know if someone
was ballpark decent and just let both of us off the hook early with rejection
(a lot of people swing for the fences with applying for jobs) if this was
easily ascertainable from the resume. I am assuming candidates are making the
best argument for themselves in their resume.

~~~
user5994461
My last company put the automated HackerRank test first, because if we
filtered by phone call or resume first, there would be no time.

HackerRank was so great at saving everyone's time. One third of candidates
never opened the link. Open third opened but didn't do any exercise.

------
sumanthvepa
This makes so much sense. I've stopped doing in-depth technical interviews for
precisely this reason. Instead, I take the developer out for lunch and spend
an afternoon discussing our software stack and business with them. It always
gives be better results. There is no stress. I don't want to see their code,
but I do want to understand how they think and work.

~~~
hirundo
Would you hire a sculpter by taking them to lunch and talking about tools but
never seeing their sculpture?

~~~
KungFuJohnny
Would you hire a doctor by insisting they perform surgery in front of you?
Would you hire a lawyer by demanding they filling out legal paperwork in front
of you?

~~~
mattkrause
My background is a mix of neuroscience/biology and machine learning, and it's
always funny to me how jobs right on that margin interview totally
differently, depending on how the organization started.

If they think of themselves as "tech", you're at the whiteboard, reversing
strings in C and playing games with trees. When I interviewed for nearly
identical job in a "science" department, someone spent 45 minutes chatting
with me about the coding behind projects I had mentioned. I even offered to
show or write soome code and got told "Nah, we already looked at your github
and it's fine."

------
theelous3
This article was painful for me to read, mostly because of how accurately it
reflected my experience with job searching.

I'm not the worlds most experienced dev who's shipped multiple products, but
for a relatively inexperienced (2y professional, 5y total), I feel I am
overlooked for positions I would excel in because I am just plain bad at
technical interviews.

I have a fairly impressive github, a creative cv and recruitment page, and a
bunch of nice addons that show how much I care about programming both
technically and socially. I have probably the best possible background for
remote positions in particular. I get interviewed a lot because of all this,
and then facepalm my way out during technical interviews.

I'm the kind of dev that can eventually solve pretty much any leetcode-y type
problem, but it takes me a long time of sitting in silence and playfully
experimenting with a repl or similar. This translates extremely poorly to
interviews.

I have also noticed that my brain will just disconnect midway through
interviews and I will fail something that under ordinary circumstances I would
never miss.

A combination of my style of thinking mapping poorly to the interview format,
and stage fright, means that my odds are poor; even against candidates who
would be both technically and personably worse fits.

Not really sure how to tackle this :)

~~~
azhu
Sounds like you know exactly what your problem is. Technical interviewing is
just like normal problem solving, just you have to narrate your thoughts as if
the interviewer's inside your head with you. Get some sample problems that
match what you're seeing in your onsites, roleplay having an interviewer there
with you, and practice them while recording yourself. Best is if you can have
a real human. If you're passionate enough, it would be a great idea to
organize some kind of group for people in similar positions.

Either you will learn the skill enough or you will find a position that fits
your current skillset along the way. Being understood by other people is where
the rubber meets the road for ideas having any impact and communicating your
technical ideas is an important skill in general.

~~~
theelous3
Aye, I hear you. I was giving it more thought over the last few days having
written the above comment, and I realised that what happens in tech interviews
is that I switch my mode of thinking.

Under normal circumstances, I sit and problem solve, thinking only of the
issue at hand, branching out and following leads and so on.

Under interview circumstances, I instead try to anticipate what the person
scrutinising me wants to see, and try to like, game an ungameable situation,
which blocks my natural problem solving thinking.

I have noticed that when I'm in a position of subordination, I do worse
creatively. This isn't to say I can't work as employee, but rather in specific
situations, such as "person knows x and is just watching me try to do x", I
enter this reactive thought mode.

Conversely, when I am in a superordinate position, I find myself much more
creative than my baseline, thinking clearly and well.

I don't know how to handle this for interviews.

------
renewiltord
You've got to know if the other person can code. Lots of people can talk a
mean game and make nothing and few people can spot them.

That's the thing, though. If you make a reputation as the kind of guy who can
near 100% spot the good engineers, you will make boatloads of money. An
employer will pay you more than $30k if you only do great hires. You do 10 of
them with your conversation out to lunch and you've made $300k. That's the
low-end.

But no one can do that and the few with high hit-rates act as executive-search
agencies where they make a lot more.

But I think I would never interview anyone I've worked with. That just seems
like a waste. I already either know that they can or can't do things.

~~~
dvt
> You've got to know if the other person can code. Lots of people can talk a
> mean game and make nothing and few people can spot them.

If only this were true. I've co-authored a (technical) book, edited another,
have dozens of OSS contributions, and GitHub projects with hundreds of stars.
Everyone still tries to whiteboard interview me. Usually I tell them to screw
off, but still. My theory is that (a) people are too lazy to come up with
better hiring processes and (b) there's a prevalent "if it ain't broke"
mentality so there's little motivation to do anything about it.

~~~
crimsonalucard
Man the guy you responded to is right. I've interviewed and mistakenly hired
several types of these people.

Here's the thing, you're not too wrong either. I don't doubt that there are
tons of great programmers who can't pass a technical whiteboard interview for
various reasons.

But without a doubt if you pass a whiteboard interview your success at that
interview is highly highly correlated with your success at the job.

You tell me... how do we screen for these master bullshitters and hire people
like you? I would love to know because I see no other alternative than to use
whiteboard interviews. I want to hire someone like you, but I have no clue how
to differentiate you from a person who can really code and a person who is a
master bullshitter.

~~~
crimsonalucard
I think a novel take home test may work. Anybody have horror stories about
candidates who did well on a take home but bombed at the job?

------
ransom1538
My favorite interview was at digg.com. A four hour interview was going great.
My dream job. I knew their tech solid. Then the last guy - walked in
[ianeure]. He asked: "What is a having statement in sql". I leaped in -
rambled on and on how you can filter aggregated sets. His response: "I don't
think you know how they work." I sat there confused and concerned. He
explained you don't need a group by with a having statement and that I needed
to go back and study sql. I sat there awkwardly [I have been writing sql since
I was 14 - I was 25]. Welp, he then rolled his eyes and left. Four hours of an
interview ruined. Oh well. Yep. That is how tech interviews go. He went on to
ruin digg.com (the rewrite everything guy) and I promised myself to never be a
dick to people I interview.

~~~
gruez
> He explained you don't need a group by in a having statement and that I
> needed to go back and study sql. I sat there awkwardly [I have been writing
> sql since I was 14 - I was 25].

He's technically right though. For instance in postgres, you don't need to
have a GROUP BY clause when using HAVING
[https://www.postgresql.org/docs/current/sql-
select.html#SQL-...](https://www.postgresql.org/docs/current/sql-
select.html#SQL-HAVING)

~~~
war1025
"Technically correct", the most irritating form of "correct"

~~~
Infernal
Also, technically the only form of correct.

------
unexaminedlife
I decided pretty early in my career that I wasn't going to concentrate on
figuring out how to get hired to what folks consider the top tech companies in
the world.

I decided to take a different route. Take the decent-paying, but average job
at an average-ish company, which will require immersive experience in all
aspects of running a web infrastructure.

The reason for this, I didn't see "getting a job at Google" as the pinnacle
for me and my achievements. I saw "creating my own successful company" as the
end goal.

Sooo many benefits to this I think. You'll get the IMPORTANT experiences and
knowledge, which will benefit you regardless of whether you are able to
achieve the end goal of creating a successful business. The ceiling in terms
of compensation is SOOO much higher. And in this scenario you're ALWAYS doing
the most important things. In my experience working for large corporations you
will typically be doing things that are far less important and in most cases
your job will not push your limits. You will be a cog in a wheel using maybe
20% of your capacity to do amazing things.

Worst case you go back to doing what you love making a decent living. Best
case you far exceed anything any of the FAANG companies could ever offer you.

~~~
ativzzz
The only way you are going to exceed FAANG compensation at an average-ish
company is if you go into senior management at that company, which is a
completely different career track.

You make it sound like being a web developer at a non-FAANG is somehow
different than being a web develiper at a FAANG. Regardless, you are going to
be working on some permutation of a CRUD app.

------
mattbillenstein
You sorta evaluate the soft skills while evaluating the hard skills - how they
approach a question, how they solve the problem, etc. Our general rule hiring
was hire sharp people, but no assholes - at least nobody more of an asshole
than I am ;)

I think the biggest problem is actually whiteboard coding problems - nobody
does that in real life.

~~~
the_arun
I think designing on whiteboard helps if not coding. Designing shows the big
picture they have in mind for solving the problem.

~~~
jakear
Coding on a whiteboard is the worst. I’ve been in google interviews where I
mention that the whiteboard format makes the process very difficult because of
how much work it is to rework existing code.

The interview replied “well wouldn’t you have to do the same on a computer?”
_chuckles to himself at how clever he is that he realized that_

No numb-nuts, on a computer I can move lines around by pressing Alt+Down. Here
I need to erase the entire thing and re-write it, which wastes precious time,
so instead I spend way more time pre-planning the exact layout of the code,
which wastes more precious time.

And in the end you take a picture of it to transcribe into the computer to
send to the hiring overlords. Just let us use our tooling to begin with.

Ugh.

~~~
sgerenser
Last time I interviewed with Google (in 2018) they had me code on a
Chromebook. Still just dumb algo questions but much better than a whiteboard.

~~~
jakear
Interesting. This was 2019, but it was a SRE position. Don't know if that
makes a difference. Probably not, because the interviewers didn't even know it
was for an SRE position.

------
ChicagoDave
I hire people from direct conversation that jumps around many subjects. My
goal is to see the wheels turning, find what excites them, get the lights in
their eyes shining. If I can’t do that in even 15 minutes, then I lose
interest fast. If I can, an hour goes by in a flash and I really get to
determine if they align with the role they’ve applied to.

I could care less about data structures and graphs. Do they care about code
and can they learn and can they communicate. That’s what matters.

~~~
starpilot
Many companies get by with mediocre developers, mine is one of them. You're
not demonstrating that your interviewing style generates superior results.

~~~
ChicagoDave
As a consultant, I’m almost exclusively on high pressure projects that require
a higher level of talent.

I have zero problems hiring adequate talent if there are suitable roles.

------
11thEarlOfMar
We use a 3 step process:

1\. First interview, the candidate interviews us. What market we serve, what
our development processes are, what our technology stack is. If they express
interest by being prepared and asking good questions, we send them home with

2\. a programming task. Choose 1 of 5 tasks. The tasks are not abstract
problems, but come out of the designs we've implemented. We ask for 100 lines
of code and not more than 2 hours. They take as much time in days as they
need, and let us know when you're done. The candidate then comes back and
hosts a code review in front of our team. I give strict instructions before
hand: The purpose of the review is to learn how they thought through the
problem and how they solved it, not do criticize their style and approach.

3\. If we decide we like them to this point, the third interview is with
managers from other functions. How well does the candidate communicate, come
across to non-developers, express interest in the company and role, etc. It's
a check point to look for concerning weaknesses, as well as get buy in from
the broader organization.

This approach so far has yielded excellent results. We ask developers how much
time they took in the programming task and why they chose the one they solved.
The programming task is telling, not in the quality of their code and how long
they took, but how much did they get into it? We have had the range from
candidates who did not complete it at all and opted out, to candidates who
stumped 40 year veterans with elegant code. In every case, we learn how well
they can express their thoughts, and importantly, their level of love for the
discipline. This is as important to me as any other attribute.

------
gregrata
I wrote a book on this last year, out of my frustration with dev interviews

[https://www.amazon.com/Whiteboard-better-hire-best-
developer...](https://www.amazon.com/Whiteboard-better-hire-best-developers-
ebook/dp/B07FJ6N8P1)

I've interviewed and hired a lot of people over the years, and have been
interviewed a fair amount. The way a lot of companies do it didn't make sense
to me, so 5+ years ago I decided to figure out a better way to do it.

My basic premise in the book is that in an interview when asking someone to
show skill, it should be as close as possible to what the job is. Most
interviews are just not anything like a whiteboard interview or algorithm
question. I get that can show how someone thinks, how they ask questions, etc.
- but to be honest I rather have them actually DO something as they would do
if I hire them.

I've had a lot of luck with this way of interviewing. The reality is it can
still be a crapshoot - you really don't know what someone is going to be like
until you work with them for a while - but this at least gets closer to making
a more informed decision ('cause you basically work with someone, in a small
way!)

------
wrnr
People still acting like we all live in silicon valley and the dot com bubble
hasn't bursted twice, software engineering is over as a high impact career,
the meta has shifted from solving problems to finding problems.

There are too many smart people in this industry who won't/can't code but act
as gatekeeper to valuable problems. My advice is to search out these problems
yourself, its a much more challenging problem then any programming.

Or spend two weeks preparing for your technical interview to learn stuff you
won't ever use again and then do the bitch work of someones over-engineered
vanity project while the plebs are doing "research", "marketing", "design",
and "business development".

------
quezzle
I did a coding test the other day.

To be fair they said don’t put more than 2 to 4 hours in. However I’m not
someone who can fail to meet the requirements so I spent 8 hours building it
to meet the requirements exactly.

Heard nothing at all back.

Silence.

~~~
magicalhippo
I'm assuming it was for other reasons, but it is possible they did see you put
all that extra effort into it and figured that's not the sort of person they
want. At least at my job, balancing the time spent on various issues is very
important.

~~~
quezzle
No matter what they say, handing in a half done coding test because you ran
out of time is a fail. IMO anyway.

Probably it was virus related but I’m not very enthused about doing coding
tests any more.

~~~
zebnyc
Totally agreed. More often than not, I have failed the automated graded filter
tests. I seem to have better results when I know that the company is also
taking the process seriously for e.g., allocating an employee's time to
evaluate me over the phone / in-person

------
ddrt
I interviewed for an agency in my city. The first three interviews went well.
Then the interviewer vanished for a week or so. I thought things were done
after following up a few times with no response. Then I heard from them again
a month later, the position was infilled and they wanted me to come in and
meet the team.

So I did, they made fun of my suit, they grilled me and then acted like I was
unsure of the job roles... however I’d gone over them many times in the
listing, prepared, and had three successful interviews. The person I
originally interviewed was there, I have him an odd look, he gave me an “I’m
sorry” shrug. And I left, perplexed. I was polite and professional the entire
time.

Then they called again, now the CEO wants to meet me face to face. So I did,
the other person who was his partner didn’t show up until 40 minutes later. I
was having a great time with the CEO and asked him a lot about how he built
the company, what the future looked like, and what Em he enjoyed most about
the culture. I was getting into my work and history when the second individual
showed up. He arrived, interrupted the story unintroduced, made fun of my
suit, looked at his watch, and gave me an annoying look.

I started from the beginning as requested, I got a sentence in and he nudged
the CEO and said “were late”. And that was that.

While they were walking away he made fun of my suit again.

~~~
fxtentacle
I used to own a suit like that ;)

No, really. In my case I went with white-green because I liked it. It was
quite obvious that it made the bank employees feel unsure if they should mock
me or if I was some sort of secret celebrity.

------
papeda
The problem I keep running into is that the more room for nuance and fit and
holistic evaluation that you inject into a hiring process, the more room there
is for interviewers to fill that space with their own biases toward hiring
people like themselves. In that sense, the white board problems are pretty
fair, even if they're (very) imperfect.

------
non-entity
That "bad hires" section describes a lot of people I've know and worked with
and tbh, I kind of feel sorry for them. They're often incredibly intelligent
people that want to apply themselves. We hired this one guy who constantly
attempts to re-architect and rewrite various systems on his own, just to have
his works rejected.

At the same time, some of these guys are seniors. How on earth have you been
in the industry for this long and not grasped what your job is?

~~~
drchickensalad
I think in this field, it's not at all guaranteed that years worked means
better. For some people, they grow a mountain in a year. For others, barely at
all.

Honestly I agree with your pain because the above situation is also not
completely tied to how much you care. Luckily though, most of the time it is.

------
pdimitar
Anecdotal evidence:

Several times in my life I've had the strange luck of being told the internal
workings of a decision after I was rejected for a job. Usually somebody from
the interviewers liked me but couldn't convince the others, and subsequently
decides to find me on LinkedIn and send me a direct message.

The messages have been eerily similar and are usually like this:

"Hey Dimi, I want you to know that I think you would be a perfect senior dev
for our team. But the other guys said you were awkward part of the time, you
didn't feel like you'll fit with the rest of us, and one of them heavily
emphasised that you hesitated before answering one question very specific for
our work... and when I pressed them to elaborate further they just angrily
told me that I don't get it.

I wish you luck in your future searches but you should know that if it were up
to me you'd be working with us now."

You can lose your balance for a minute while being evaluated live by several
people? You can hesitate before answering a trick question about a niche
project? Imagine that.

It's really bittersweet to get these internal insights and can make you want
to pull your hair out -- but it did give me the perspective that most of the
people charged with hiring go by a gut feeling and personal sympathy.

~~~
frankzinger
Yeah almost anything is possible so one really has to try not to obsess about
it too much. I know it's hard. I can't say I'm able to do it either.

Anyway, my anecdote: we were interviewing for a C developer position. The next
candidate was in his 50s. Our project leader took a dislike to him the moment
he saw his resume. No idea why but I assumed it was either his age or that
this project leader knew him and didn't want to work with him for some
personal reason.

The project leader arrived to the interview at least 40m late. In that time
this candidate impressed me (as the C guy) very much and I said 'hire'
immediately. However, as presaged, the project leader said no.

This candidate had no way of knowing what had happened. He definitely could
tell I was impressed so he probably assumed it was his age. Just imagine how
he must've felt. I probably should've contacted him to let him know how messed
up the our process was.

~~~
pdimitar
Not sure how legal this is (the giving insights into your internal processes
to a stranger part) but since there are no trade secrets involved I'd imagine
it's quite safe.

As I said above, it can be really bittersweet knowing the details but I'd
advise you to strive to show maximum sympathy -- including contact them
privately and let them know what and why happened.

It's a little comfort for somebody who is about to run out of savings to hear
"sorry that our process is so effed up, dude, and best of luck in the future!"
but I can assure you that it helps them make peace with that past further down
the line.

------
thaumasiotes
> when a developer is hired, it is incredible the extent to which the process
> will ignore the human being and focus exclusively on algorithmic/technical
> aspects. It's a disguised IQ test, and we all know it.

> What's crazy is most people hiring will even throw away your ability to
> learn and adapt!

These conflict. At the very least, the second quote illustrates that the
hiring people are not aware that the interview is meant to be a disguised IQ
test.

------
Drecula
Let's also not forget the bias of Indians only hiring other Indians. There's
entire product development teams in the Bay area that are close to 100%
Indian. Sorry, I don't buy the excuse that's the only people available to
hire. How does this relate to competence and the quality of the engineering
work product? Race, gender, age, do NOT matter. So, why the pro-Indian bias?

~~~
ativzzz
I've noticed this trend in companies with Indian middle managers who tend to
aggressively pursue hiring outsourcing firms (like Accenture) to bring in
offshore Indian resources, and the project inevitably fails.

Every time I've seen this, the decisions to hire the outsourcing firm never
really made sense, so the easiest guess to make is the managers were receiving
some kind of kickback, but we can only guess.

~~~
arvinsim
I would hazard to say that it is an Indian cultural thing. But it seems to be
a spectrum since I have read accounts that some Indians don't hire Indians who
don't belong to the same caste/region/state.

------
johnmarcus
As someone currently interviewing, with 10ys exp scaling multiple successful
companies, I couldn't agree more. Some of the tech questions I've been asked
are so useless in practice it's unnerving.

------
doorty
Yes, it's the reason I'm not currently employed in the software industry.
After a decade of being a professional developer, I decided to start building
physical things and learning other maker skill sets. Whenever I need some
extra income I start looking at software jobs, but I'm not able to think
clearly during these sort of test situations, and they don't usually go well.
I've built so many things from software products and businesses from scratch
and could do so again, but it just makes me bitter to even subject myself to
this initiation. I would be much happier (and companies would have more
diverse candidates) if a resume and past experience did the talking like other
professions.

------
ccleve
The core problem is that many people who apply for software developer jobs are
attracted to the money, and just aren't very good at coding. Slogging through
these interviews is a drag and a waste of time for capable developers. So, the
process is delegated to junior people who don't yet have the judgment or
experience to know what's important.

This is a joke, but uncomfortably close to the way junior people interview:

[https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...](https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_carpenters_were_hired_like_programmers/)

------
louiskottmann
The thing is, when you start having a lot of candidates at your door, say,
because you are a big company with interesting problems and/or good benefits,
and the position is sought-after, your recruitment process costs even more. So
you look to lower that cost by filtering out applicants based on some
criterias. People from renowned schools go first because they are more likely
to be skilled on average, if you ever deplete that pool, you look for the
rest.

I recruit for my company, and we don't do that, in fact we do quite the
opposite. But I'm pretty sure that's how big companies see it.

------
DeathArrow
I think it depends on the company. In a small company it's vital that
developers understand user needs and want to provide a great user experience.
Bigger companies can, but not always will - see Google, have dedicated people
to think about the product the user experience and how the product should
catter to a particular user base. Those people can translate the requirements
for developers.

I am not saying that developers should be autistic and completely ignore
anything that is not code related but it can be done. Google failed but others
succeeded, see Adobe or Ubisoft.

I certainly like to code and like technical intricacies but I always looked to
code from an entrepreneur pov: always trying to work on something which will
be useful for someone and ask myself what feature is going to be useful, to
how many people and in what way. I did my share of "inverting binary trees"
but that was when I was a student and needed to learn. I always tryed though
to use such a technique to solve a real issue.

Maybe CS programs at universities should start teaching not only CS and
programming courses but also concepts about thinking products, understanding
user needs, assessing user needs.

Architects are trained not only on visual and technical aspects of planning
buildings but also on understanding user needs and making the building useful
for a particular customer. It's useless if a house looks good, uses clever
technical solutions but no one is wanting to live in it.

------
screye
Developer hiring is not broken, it is the people who do the hiring that are.

It could not be more clear to me and their conclusion only makes me more sure
of it

    
    
      We need to throw away this idea that you can get the measure of a person just by subjecting them to a faux-IQ test. 
    
      We need to fully internalize that being a great software developer is holistic and draws on abilities ranging from, yes, technical skill, but also empathy, experience, taste, grit, perseverance, and independence. 
    
      Being a great software developer is multi-disciplinary and we need to actively and vigorously reject the notion that just being good at "cutting code" and inverting a binary tree is the end of the story 
    
      and is therefore the only axis on which to assess people who work in teams and build products for other human beings.
    

The kind of person who is able to judge someone for such skills, is also
probably very high up the company ladder, a busy person who cannot interview
every candidate. At the end of the day, 50% of interviews are going to be
conducted by people who were until recently new-grads and have only taken
exams which are neither technologically holistic nor gauge for non-technical
essentials.

This is not a problem in the system. This is a problem of scale.

------
peterwwillis
Maybe that's just a software developer thing? When we hire technical but not
primarily software-developer roles, we focus on the particular role's
requirements, and the skillset and experience the candidate is bringing. If
this is a product support role, have you done product support? If this is an
ops role, have you fielded random "urgent" requests from development teams and
recovered bad production deploys? Do we need someone who can get something
done ASAP, and as such do they have all the needed skills _now_ , or can we
wait while they familiarize themselves with a bunch of new stuff?

I generally ask few technical questions because I'm mostly interested in
everything _other than_ your technical knowledge. I can find 50 people who
have taken a coding bootcamp and memorized an entire language's inner
workings. And I can usually quickly determine how deep your technical
knowledge is by throwing stupidly specific questions at you. But I won't know
whether you can apply that knowledge in a way that will gel with the team and
the requirements of the role.

Which is why most quality candidates come from personal referrals. If you want
to get a good job, develop good working relationships.

------
OliverJones
1\. Fizzbuzz

2\. If you claim SQL: Explain LEFT JOIN ... IS NULL pattern. Do you know about
little bobby tables (injection exploit).

3\. "How does the internet work?"

4\. "Tell me about a hard / interesting / instructive bug you had to handle.

5\. What would you do differently if you were the lord high poobah on your
last job?

6\. Tell me about something you helped finish and ship to users.

7\. What do you have to say about OUR product?

Those questions have helped me hire some great people. They apply to anybody
from a fresh-out to a self-taught to famous programmers.

You CAN shove into their face some strange line of code that depends on arcana
of operator precedence. But the only useful answer there is "I would never
write something so obscure."

~~~
StandardFuture
Or you could have gotten lucky in the pool of candidates you are sampling
from. If you end up only interviewing good (or bad) programmers, then your
interviewing process never really mattered in the first place. So, no
formulaic interview process is going to ever be proven effective (and in fact,
is very likely never going to be much more effective than a coin toss). People
really need to get over themselves with their "clever" questions and answers.

------
bfrog
I feel like this explains the needless product abandonment and reinventing at
Google.

------
erdos4d
No, the greatest sin of the software industry is the sprint meeting. That's
literally a lie we perpetrate every day.

------
illuminati1911
Is this really a thing outside US/US companies? I've been now 10 years in
software industry (as a developer) in Asia and Europe and never had one of
these "whiteboarding algorithm"-interviews.

Interviews I have attended might have included something like that, but it's
usually 1-5%. Most of the interview is talking about my previous experience,
"how would you design a system xyz", homework tasks, "Take a look at this
piece of source code for 15mins and tell me what's good and bad about it" etc.

~~~
stevenwoo
I’m in California but applied for a couple of jobs in Europe. One had a 24
hour timed test on hackerrank to complete 4 of 6 problems (unrelated and
complete mini games) and another for an Android position had a timed
hackerrank test in Java trivia (disguised as a programming test) with a short
time limit. These were the screens so the follow up on sites were probably
worse.

------
cryptica
People have been saying that tech hiring is broken over and over for a decade
now but nothing was done about it. Hiring processes are still rooted in the
"If you can solve this tricky textbook problem, you're smart" ideology which
is completely wrong because it commoditizes a very narrow type of intelligence
which is not related to value creation.

Unfortunately it's too late to fix that problem now. If a top value-creating
developer was hired by one of these companies today, their approach and
thinking style would be fundamentally incompatible with most of the other
people who work in the company today (due to the legacy of bad hiring).
Moreover, their boss would probably be one of those textbook and process-
oriented people who is completely detached from actual value creation; working
under such people is deeply depressing for value creators who have developed a
laser-focus "eye on the prize" and "simplest is best" mentality from years
working in harsh startup environments.

I would argue that the "simplest is best" mindset is good at any scale but the
corporate hiring process has systematically weeded those people out.

That's why corporate monopolies are harmful for society, some entrepreneurial
people just can't fit in at the bottom of large corporate hierarchies but yet
they are often left without any alternatives.

------
tictoc
Is it actually an IQ test? Can you practice for an iq test like you can for an
interview? I don't see it being that difficult to just grind on leetcode
enough to snag a FAANG job.

~~~
SpicyLemonZest
It's not that difficult for people smart enough to get a FAANG job.
Personally, I've heard anecdotes from people who can't understand leetcode
problems even when given the solution. Professionally, I've seen multiple
people who were clearly _trying_ to recite a memorized solution for an
interview problem, but just weren't clever enough to do it properly or talk
about how it works.

~~~
opportune
For all the complaints about whiteboarding, it does filter out a lot of people
who can't seem to generalize problems or are weak at either problem solving or
coding. I don't see how anyone who has given technical interviews could say
whiteboarding is a waste of time, unless they are not good enough at
whiteboarding to be able to productively give such an interview.

------
smilekzs
I'm in a mid-sized startup with headcount in the mid hundreds, and my mental
model is like this: Say you have a batch of 100 ppl applying for the
generalist SWE position, among which you can only afford to bring onboard ~10.
So you need a filter that approximates this desired selectivity, and it needs
to be consistently applied across the board for fairness. Also, you can't
afford to spend too much time + effort per candidate. What do you do?

It so turns out that simple technical problems that requires coding, in
conjunction with active spotting for deal-breaking red-flags, can be
calibrated well to achieve both fairness and desired selectivity. I can't
think of anything else that can so conveniently satisfy the rather essential
conditions above. Of course the devil is in the details... which lies mostly
in the kind of technical problem you ask.

Personally I prefer handing out distilled real problems encountered at work,
with a hint of realism, no dependency on know-how other than a solid
understanding of CS fundamental, and reduced to be self-contained. Think of
the "kinda smart" bits sprinkled across your codebase. This of course requires
careful design and calibration, and risks spoilers online, but it's been
consistently working well. Personal anecdote though so YMMV.

------
ben7799
The problem as I see it with focusing on history & people skills too much is a
lot of the weak candidates are flat out lying about those kind of things.

I've interviewed more people in the last year than any previous year of my
career. We found numerous candidates cheating on online coding tests. Weak
candidates that fall flat on their face when asked to do something super
simple like a FizzBuzz problem list massive accomplishments on their resumes.
Often it seems like they are listing everything the team they worked on
accomplished, not what they accomplished.

And the weak candidates frequently list things like "Expert at Spring
Framework" or "Expert at J2EE". To be an expert on those things is very rare
since they are enormous frameworks. Not many strong candidates will list
themselves as experts on giant projects unless they were one of the founders
of the project.

He is talking about filtering out developers with good technical skills who
have other aspects of their personality/behavior that don't mesh with his
business. But the bigger problem seems to be finding people who actually have
real technical skills. The things he's worrying about are easier for
management to correct/control.

~~~
yellowstuff
Ability to invert a binary tree is not what you actually want to measure, but
you can't bluff your way through it, so it's an attractive target to measure,
especially at a large company trying to have standardized practices.
Professional accomplishments is much closer to what you care about, but you
can bluff. But it's still possible to give a good subjective interview. Good
interviewers will find a area on someone's resume that they have deep
knowledge of and drill deep. It takes longer to sniff out a complete fraud
than FizzBuzz, but it can still be an effective approach.

~~~
ben7799
Inverting a binary tree is actually something that weak candidates seem to
find a way to cheat on though.

Same thing with Fizzbuzz, so it was an artificial example in my post.

The best thing for us seems to be relatively simple coding questions that are
domain specific problems.

My go-to the last year or so has been an interview like this:

1) Give a demo of the product

2) Explain a problem the product has/had to solve

3) Go over the entities/objects involved in the problem

4) Present this as a simplified whiteboard problem

5) Candidate needs to write some code on the board to solve the issue (Typical
solutions < 20 lines of code)

6) Discuss scalability of the solution

7) Discuss alternate ways to refactor the larger code base to avoid having to
write the algorithm that was written on the whiteboard at all

The process of having to take a problem that comes from a specific product &
translate that into code seems to catch the weak candidates that cheated on
the online coding tests and bluffed the recruiter nearly every time.

This is as opposed to places like Google that just constantly try to ramp up
the difficulty of the non real-world coding questions they're asking the
interviewee.

------
sultanofswing
The software industry's greatest blog post sin: "Hiring in tech is broken"

This topic is trite. Furthermore no one seems to be able to offer up actual
tangible suggestions as to how to fix this, or some objective 'better way'.

Disclaimer I work at a FAANG etc company: Also this has been distinctly "not"
my experience at many FAANG type companies. Usually these interviews, even the
one's I haven't done well in, have been highly conversational, and all contain
a fairly in depth 'soft skills' interview as well.

Yes, your technical knowledge has to be good, but a good interview will keep
pressing at the edge of your knowledge (not to make you 'fail'), but to see
how you handle the unknown.

In fact for one of the companies I ended up working at I was called in for a
second soft skills interview just to dig even deeper on the dimension the
author claims is 'never tested for'.

Much like these authors I don't have a perfect solution to this, however I
will say one of the most rewarding interviews I've ever done (at a well funded
startup where I did NOT get the offer was comprised of):

\- 1 Algo question (standard fare)

\- 1 Architecture question (standard fare)

\- 1 'find a bug in this mock part of the codebase / pair program with me'
question. Implementation didn't necessarily have to be perfect, mostly was
interested in diagnosing the actual problem and talking about 'how' we might
solve it (very fun)

\- 1 Product Sense (!) question with actual PMs (very fun)

\- 1 General culture fit / experience interview

~~~
vsareto
>Furthermore no one seems to be able to offer up actual tangible suggestions
as to how to fix this, or some objective 'better way'.

There are other professions with models of credentials that could be adopted
to software given some time and adjustment and faith. Then we could shed our
current technical interviews in favor of shorter interviews overall. You
naturally need more people to handle interview bandwidth as your company
grows.

People want to show some credential and not have to deal with technical
interviews at every potential opportunity. We've learned enough about
technical interviews that we should be able to make this kind of widely-
recognized credential. We just don't want to do it. We'd rather keep
recruiters employed and force developers to budget large blocks of
interviewing time.

------
deedubaya
There are two camps here that strongly correlate to their opinions: those who
have been through a job hunt in the last 5 years, and those who haven’t.

------
hlmencken
Being a manager and hirer is very different from being the interviewee. It's
great to believe that you could have some innate ability to judge one's
empathy and character in a set of interviews but so much of that runs to favor
people who can talk well, which is a wholly different skill from being to code
well. Saying technical interviews are disguised IQ tests is quite the horse-
shit metaphor. I won't dig into all the problems with IQ tests. Certainly some
people have innate ability to do well in quantitative tests, but I know so
many people who have put in so much work to get so good at what they do
against difficulty and belittling their success at interviewing as something
inherent like IQ is awful. Getting to that level takes experience. It takes
grit. Programming is a highly technical skill, I have worked with people I
don't get along with and people I can't talk to comfortably who have written
amazing code and when I am reviewing code that is going to be depended upon by
millions of people each day I will always merge good code over someone I like
personally. Lots of developers also have responsibilities that use empathy and
character and leadership and those people you should always hire along that
rubric as well, but if what you need is strong technical skill and ability to
solve hard problems with code. You have to find someone who can program well;
after that you can have a lot of flexibility in how you work with them and
what other responsibilities you give them. I think you are off in comparing
programmers to white collar professions. Compare them to skilled professions
ala crane operators, machinists, or surgeons. If you don't have hard technical
problems then you have the luxury of not needing people who are very good
technically, so you can have the luxury of rounding out your interview, but if
you have programs for which code quality is very important, you should trust
someone who can build good software.

------
kcorey
In my experience the UK is slightly less focused on credentials than the
backwards boneheads in the US.

That's the good news.

The bad news is that tech interviews in the UK tend toward the same faux-IQ
test mentality.

When are recruiters going to realise that just because you can reduce a person
to a HackerRank score, that doesn't inform a good hiring decision?

I've often said the _only_ way to see how someone is going to work out in an
office is to hire them and let them work for a month on probation. After a
month, if they've demonstrated an ability to talk, to collaborate, and to
learn, then keep 'em. If not, cut 'em loose.

 _everything_ else in tech hiring is B.S. I have yet to see an alternative
that can't be gamed, that takes in the holistic person.

And _none_ of my jobs have really brought out the best in me. In jobs I've
done well, I drove that myself. In jobs I didn't, it usually came down to bad
communication (in both directions). Nothing to do with the recruitment _at
all_.

~~~
frankzinger
> When are recruiters going to realise that just because you can reduce a
> person to a HackerRank score, that doesn't inform a good hiring decision?

Never. If tech people can't find a way to do it there is no way a non-
technical person will be able to. Pretty sure this is why Google has its own
recruiters. Your average recruiter has no clue how to grade candidates. For
other companies it's probably best to find a way to apply directly.

I recently went through the process and got a job from a direct application. I
dealt directly with the tech lead. The process was entirely devoid of BS. We
understood each other right from the beginning---perfect clarity. After the
little bit of time I spent looking through job ads and dealing with recruiters
I am endlessly thankful that I got this job before having had to deal with all
that for longer than a couple of weeks. The difference was stark.

------
starpilot
Would companies make more money if they hired in this "wholistic" way? Every
time this comes up, I struggle to see how these top tier companies with these
algo-intensive interview practices are compromised by not being "wholistic."
They're raking in cash. By all quantitative measures their hiring is working
extremely well for them.

------
badrabbit
Whiteboarding sucks. I was asked to do this once or twice, I can't think while
others watch because I am focusing on what they are seeing, and my penmanship
sucks. It's not for anyone that gets nervous easy. I just don't get it, why
not put up a text editor on a wall screen and ask people to write the same
code there?

------
dfilppi
Oddly, the more real experience you have diminishes your chance of being
hired. You might recall how to 'invert a binary tree' had you recently
graduated from college. But since inverting binary trees is an extremely rare
need in the real world, you are doomed if you have significant experience.

------
p0nce
I liked most interviews, but the one that irks me are when the interviewer
asks very specific questions that are specific to the particular domain the
company is in.

But one of the biggest reason to apply somewhere as a developer is precisely
to get to know a problem domain. Money is not the only incentive, by far.

------
austincheney
I posted this comment yesterday buried in some thread and even though it was
buried it still got 37 up votes.

[https://news.ycombinator.com/item?id=22821318](https://news.ycombinator.com/item?id=22821318)

I post a similar comment in this thread and it gets downvoted to user flagged:

[https://news.ycombinator.com/item?id=22831474](https://news.ycombinator.com/item?id=22831474)

Perhaps the largest handicap in developer hiring is bias as evident by the
stark contrast in response to these two comments that convey identical
sentiments about the same subject with slightly different language and yet
receive opposite response.

A company is a absolutely not objective in their candidate selection if
developers are the deciding factor in the hiring of other developers.

------
12yrprogrammer
It's weird, I've programmed Everything from Random Forest in VBA to full stack
apps to embedded, but I can't get an interview. "Just do projects" they told
me.

Maybe I'm asking for too much money? 90k/yr.

I want to switch from Engineering(120k/yr) to programming, but I've been
unable.

SE Michigan.

~~~
fennecfoxen
90k a year is totally doable for medium-experience software in principle, but
in southeast Michigan I'm much less sure. The salaries are laid out
differently.

For those coming into the industry from outside, the real questions may be
less about what you're capable of programming, and more about your wisdom in
producing code that works well with other code and with the realities of
failure. It's hard enough to get a good sense of how much of that wisdom you
have even when you _are_ a software engineer...

------
helen___keller
It's often very unclear what you really want out of a candidate, much less how
to select for that.

Maybe a workplace wants someone who will conform to corporate culture and
cheerlead for the company. Maybe a workplace wants someone who will learn a
big stack of internal tools quickly. Maybe a workplace wants someone who will
grind out intense hours without complaint. Maybe a workplace wants someone who
isn't going to "waste time" paying technical debt and instead just ship an MVP
as soon as possible. Maybe a workplace wants someone who learns new skills on
their free time tries to incorporate them at work.

Workplaces don't identify or admit what they really want out of a candidate.
And they certainly don't have a way for testing against it in interview.

Top tier (read: cash-flush) companies have settled for hiring strategies that
effectively select for "yuppies" (I dont mean this in a derogatory way) who
are willing to bust their ass and do whatever it takes to overcome any
obstacle they are given. This mentality is common among top schools that are
already intensely selective and competitive. People with this mentality are
much more likely to spend hundreds of hours prepping for tests, such as the
leetcode meta today.

Ultimately, while it's very annoying during a job search, I'm thankful for the
fucked state of hiring because it means software engineers _aren 't
commoditized_.

If we were indistinguishable cogs, and any engineer with N years experience
can be replaced by any other engineer with N years experience, that kind of
dynamic ultimately results in a strong downward pressure on employee's power
and wage. We are closer to a talent dynamic where every engineer is unique and
some are much better hires than others. You wouldn't hire an actor just based
on their resume. Knowing how many years they've acted or in how many roles
isn't enough, you need an audition.

Software engineering is halfway between these extremes, and we should be
thankful that we aren't (yet) indistinguishable cogs in the corporate machine.

------
master_yoda_1
Here is the text from one of the interviewer who clear the fb interview "The
second interview was very hard they asked me a leetcode hard question and I
was only able to solve it because I did the exact question before. Complete
luck there. Personally I think it was unreasonable to expect someone to solve
that difficult of a question in 30 minutes. The overall acceptance rate on the
question on Leetcode is around 20%." [https://leetcode.com/discuss/interview-
question/563659/faceb...](https://leetcode.com/discuss/interview-
question/563659/facebook-ml-engineer-santa-monica-pending)

------
wffurr
>> It's a disguised IQ test

Funny, an IQ test has one of the best correlations with job performance among
all hiring methods; one of the few to do better than random chance.

>> Does this person have incredible grit and perseverance? Who cares! Does
this person communicate and write well? Who cares! How friendly and amicable
is this person? Who cares!

I specifically evaluate all of those things and write them up in the report
after a technical interview. I don't know where this person is interviewing,
but all of these do matter.

But it doesn't matter how friendly you are if you can't also demonstrate
problem solving and coding ability.

Also, what a disaster these threads always are. Depressing.

------
thomk
I never understood why companies don't take a slower, ramp up approach for
interviewing.

ROUND 1 THE INTERVIEW

Step 1: Interview candidates for 'culture fit'. Chat on the phone, get to know
the person a bit, ask questions about what they did before. See if they have a
sense of humor, get them to relax. Don't try to trick them, just have a chat.

Step 2: Ask a few 'how do you think questions'. Why are manhole covers round?
How many school busses are in New York City, etc. These are questions with no
clear answer and missing input data (like real life). Listen to how they work
out problems in their head. Then ask fuzzy questions with no clear answer, and
relatively high consequences for rightness or wrongness. See how they deal
with that. Ask workplace conflict questions and irate coworker questions, see
how they respond. Give them all the time they need.

Step 3: At the end of the interview, send them some take home code projects
without a time limit. Give them some toy software program and ask them to fix
a few reported bugs in it. Then give them a small greenfield project and see
how they structure and document their code.

ROUND 2: THE DATING PERIOD

If all of the above goes well; hire them on a 1 month trial basis and see how
everyone works together. Maybe they don't like your company? Maybe they smell
funny? Maybe you force everyone to do yoga? Maybe they MUST travel with their
service chimpanzee? Who knows? Spend a month working together and find out. If
either of you see a red flag; shake hands and go your separate ways.

\- - -

My point is this; putting someone through a gauntlet of stressful, random
interview questions and whiteboard coding issues makes people stressed and
nervous so they do not act like themselves. If the job is a high stress job
and it's important to handle a lot of stress; you'll see that during the
dating period.

Imagine having to decide if you were going to marry someone based on a few
hours of conversation and 'whiteboard coding problems'. It's too much of a
commitment with too little information.

Hire people, not machines.

~~~
thomk
One last point on this. The general idea is to see HOW someone thinks. One way
to do that is to have them map out and work through a problem on a whiteboard
without code. I'm talking boxes and arrows. Ask a question like 'How does (for
example) bittorrent work IN GENERAL?'

Have them map out the answer on a whiteboard for _one_ person who knows how
bittorrent works and can nudge them along if needed. The idea is to see how
well they communicate complex ideas, not how well they have memorized the
bittorrent protocol.

------
joelbluminator
I think a very important point from this article got lost in this discussion;
many engineers aren't aligned with the business and the end users, but instead
often needlessly chase new stacks, over engineer the code base, migrate to
micro services (prematurely), rewrite an existing codebase in a new hot
language instead of just refactoring, needless throwing React/Redux at the
problem etc etc. So many times these efforts give zero value to the code base
or the product. This type of behaviour seems to go unnoticed since business
doesn't understand engineering and has to trust the engineering managers.

------
ggggtez
> neil with data .com

> no data in the article to back up claims

Yet another person who claims that hiring is broken. If this is the case, then
show me the company that is not using technical interviews, and demonstrate to
me that all these other companies are failing to hiring the best people for
the job.

The closest they get to evidence of their claim is that Google didn't hire 1
random guy 4 years ago. Oh, and that Google built Stadia (??? huh ???).

Did I just read an anti-Google blogpost disguised as an anti-interview
blogpost? What does Stadia have to do with interviews?

------
ojr
I did on a onsite at Google and learned the most during the lunch portion, my
interviewers didn't know basic ES6. At lunch, I talked with an engineer who
was a teacher before his first industry job at Google which he has worked for
5 years, in contrast with me that had work at 4 different places in 5 years. I
didn't get the job even though my github and industry skills were more vast.
They would rather hire "theory over practice" developers because they are
easier to retain, which is fair.

------
jorblumesea
The worst part about hiring is once you're into the "elite circles" it becomes
less work. Work for a FAANG? Getting a much becomes far easier and sometimes
with less difficult questions.

Whether you agree with the IQ test or not, it's not even a level playing field
or merit based. It's about an elite club keeping things elite.

Half the engineers working for FB, Google etc would not get hired today. Yet
they still ask questions that they would not be able to answer as a form of
gate keeping.

~~~
mwerty
>Half the engineers working for FB, Google etc would not get hired today.

I thought people jump around a lot these days.

~~~
TheSpiceIsLife
That doesn’t invalidate the idea that half, or some other portion, don’t.

~~~
mwerty
don’t =/= can’t.

------
resume384
Nice insight. Recently posted my take after jumping into the industry head
first after going it independently for decades....

[https://www.linkedin.com/pulse/let-me-open-you-
adam-m](https://www.linkedin.com/pulse/let-me-open-you-adam-m)

[https://news.ycombinator.com/item?id=22820905](https://news.ycombinator.com/item?id=22820905)

------
danielscrubs
"Your interviews are hurting my ego." "How did they hire that guy? He can't
code his way out of a paper bag!"

We (me included) protect our egos like our lives depend on it. Very few people
have the balls to just admit the interview went terrible because of
themselves, it's always the person on the other sides (interviewer OR
interviewee) fault.

------
KingOfCoders
I did love the way eBay did hiring with 360 interviews. I interviewed my
future boss and recommended that she should be hired.

------
jppope
I wrote about a better way to hire people:
[https://jonpauluritis.com/a-better-way-to-hire-
people](https://jonpauluritis.com/a-better-way-to-hire-people)

It works remarkably well if you're flexible enough to follow it.

------
chronofar
Nothing will ever beat a trial. It's more expensive, but it's clear shortcuts
just don't work that well. Give people a chance to work with you and then you
both can make a well informed decision about how the situation is likely to
play out.

------
alkibiades
some frustrating parts for me:

1\. if i got an offer from your company a year ago, why do i need to redo the
phone screen and entire process?

2\. if someone has 10 years of experience at google and is L6, why do they
need to do the standard process to work at some rinky startup?

~~~
chihuahua
The reason for (2) may be the following: can the company verify that the
candidate did in fact work at Google for 10 years and reached L6? I don't know
about Google, but if someone claims they worked at Microsoft as an L65, and
they call Microsoft to fact-check, Microsoft will only tell them when that
person started and ended their employment there. They will not disclose any
other information.

------
ausjke
The best way I see it, is to have this guy to work for a while, say a few
weeks or a few months as a contractor, then either ends it or converts to a
permanent job. This is the best interview approach.

~~~
rsynnott
Honestly that would filter out basically anyone senior, and anyone who could
get an actual job elsewhere. Given the choice of going through a normal tech
interview process before leaving my current job, or leaving my job for this,
why on earth would I pick this?

------
loup-vaillant
> _Almost no other "white collar" profession I'm aware of will so completely
> and thoroughly ignore your actual proven ability, historical
> accomplishments, and holistic qualities, as part of the hiring process._

Perhaps that's because programmer is _not_ a white collar profession? Those
who don't manage other programmers are naturally at the bottom of the
hierarchy, just like a machinist (clearly a blue collar profession, though I
would certainly show proper deference to them before I even dare approach a
machine).

Never mind how useful, or how skilled, people at the bottom are. They're at
the bottom, and that alone probably affects how they are treated. The hiring
process is just an effect of this.

~~~
rsynnott
"White collar" doesn't normally exclusively mean managerial, it means
'professional' in a kind of poorly-defined, rather obsolete, classist way. A
"you know it when you see it" thing. For instance, a doctor is white collar
(but probably not a manager). So's an accountant, or an engineer; again,
they're mostly not managers.

~~~
loup-vaillant
How about a cordwainer? Many are highly qualified professionals, and I bet
they're "blue collar" all the same. They're working with their hands making
shoes after all. I think this "white/blue" distinction blinds us somewhat.
What really matters is how others (in particular those who have power over us)
perceive us.

As for being a profession, relatively few programmers are independent. Most
work under a boss, with the same hierarchical constraints as a factory worker.
We're not organised as a profession. I dare say we _aren 't_ a profession just
yet. Our trade is too young for us to have achieved good average competence
(doubling our numbers doesn't help, and is an indication that there's no
selection pressure yet).

The only thing that makes us "white collar" is that we work in clean
environment, without physical exertion.

~~~
rsynnott
> How about a cordwainer? Many are highly qualified professionals, and I bet
> they're "blue collar" all the same.

Yup. That's largely where we get into the classism thing. "White collar"
doesn't say anything in particular about skill or earnings (or even education,
necessarily; you don't need a degree to be white collar); it's a class
signifier.

> As for being a profession, relatively few programmers are independent. Most
> work under a boss, with the same hierarchical constraints as a factory
> worker.

Same goes for doctors (in most countries), accountants, etc. And of course, a
middle-manager is white collar. While collar doesn't necessarily mean self-
employed/company owner/bourgeois. It's more complicated than that.

------
globular-toast
> It's a disguised IQ test.

No. It also tests knowledge and familiarity with whatever technology is
required. But yes, of course it tests IQ. What else is important? The way you
look? The way you speak? Your background? I don't care about any of that. If
you can express yourself in a technical context then you automatically satisfy
all other requirements.

I like technical interviews. They remove bias. It means someone isn't going to
get the job just because I "like" them or, worse, I want to fornicate with
them. I've hired people of all ages, races, and other "identities" thanks to
the technical interview.

------
netjiro
Tossing my 2c in the ring, this is how I usually hire new dudes[1]:

\- Ask the existing team for a set of dude recommendations, and the reasons.

\- Track down a set of dudes myself. Usually from publications, open source,
or previous products.

\- Discuss with the dudes regarding the greater project target, team, goals,
initial tasks, scheduling. Ask the dudes for other dudes they can recommend,
and why.

\- From here on I pay the dudes for their time and effort during recruitment,
always:

\- Have the dudes look at previous problems and solutions, if available, and
ask for feedback.

\- Have the dudes spend time with existing team on current work and ideas.
When populating entire teams I have dudes work with each other. I especially
look for people who are freely sharing even with people they are (technically)
in competition with.

\- I always followup on my initial predictions over time, to see where I'm
right or wrong, and what to look for in the future.

I often hire scientists or other people who do a lot of work out in the open.
It's just so much easier to quickly get a feel for peoples' output by looking
at, and discussing, previous work. And most of my projects require bleeding
edge specialists.

I advertise <25% of my positions (guesstimate). This is a failing on my part.
I have no magic lens to read CVs, so they carry no additional information
value for me.

Hiring is expensive and often takes a long time, but hiring the wrong people
is much worse.

Throughout my projects I have only had one person leave, and that was for a
once in a lifetime offer. I very rarely need to fire anyone.

I would rather hire two excellent dudes than five good dudes. So I tend to
have the budget to pay good rates. Then I call up temporary manpower to solve
the more mundane tasks so I can keep my excellent people on the more difficult
and interesting items.

Red flags I look for when I'm on the other side of the table:

\- Who is doing the hiring? Some checkbox HR drone, the owners/investors, or
the actual team?

\- Hiring evaluation tools. Have they actually bothered to read up on the
latest few decades of research, or are they just following dogmatic trends? Do
they even track their own prediction skills when hiring?

\- What is their understanding of the project, tasks, etc?

\- Do they respect my time investment?

1) a "dude" is gender and ageless, of no persuasion, has neither skin nor eye
colour, and so on.

~~~
JohnL4
> 1) a "dude" is gender and ageless, of no persuasion, has neither skin nor
> eye colour, and so on.

In that case, s/dude/person/g

Language affects thought, right?

~~~
netjiro
Very true, my deviance. But words change meaning and connotations over time.
For me "dude" is a blank placeholder. I should of course take more care to see
my text from the eyes and mind of the target reader.

IIRC the 2004 bsg called everyone "sir" regardless of gender. I remember that
nudged me the first and second time I heard it, but then it was just second
nature. It had lost it's (for me) implied gender.

------
thorstenn
Leonardo da Vinci means Leonardo from Vinci. Trivia is not always useful but
is an indicator of curiosity.

------
dudul
A week on HN wouldn't be complete without the traditional "hiring is broken"
blog post.

------
Lio
I’m not a technical interviewer specialist, I’m a developer who has in the
past given interviews.

Other than filtering out chancers with a lack of required basic skills, one
thing that’s always bothered me is how my own personal Dunning-Kruger effect
alters the interview process.

I obviously only ask questions I think I know the answers to otherwise how
would I know if they were correctly answered?. So that may mean I miss out on
candidates with a range of skills I lack and can’t detect in interviews.

Interviewing successfully, I suspect, is a ”difficult” problem if you take it
really seriously.

Like those pointless “skills matrixes” that inexperienced managers like to set
up for their teams. I mean you can ask me my skill level for a particular
subject matter but how can I answer you with any accuracy if I don’t know what
I don’t know?

------
dccoolgai
"disguised IQ test"

If only. It's more like a Wonderlic Test.

------
rafiki6
I feel similarly as the author but I'm starting to take a more balanced
approach to all of this and it's helping me put things into perspective. I'll
play the game because I'm not sure what other choice I have. I don't enjoy my
current job and in order to get the jobs I want with the people I want to work
with this is the price. That being said, it's absurd we have to do this EVERY
DAMN TIME. Even moving between FAANG requires you to do this. That in and of
itself is a clear indication of how bad of a signal this interview process is.
Reviewing reddit and team blind and HN (as this is the best data that I have),
it seems many folks working at a big tech company still need to leetcode to
move to another big tech company despite already passing the bar at one! If
that isn't a clear indication of the type of information these interviews
provide I don't know what other evidence we need.

And here is the real crux of the whole thing. Considering how standard it is,
we might as well just make it a part of a software developer
certification/license that you have to do once to break into the industry. The
funny thing is, despite our best efforts to not become a real standard
profession we are behaving a lot like one, except we don't realize it and keep
making candidates jump through the same hoops repeatedly.

Now many of you will balk at the prospect of standardizing but hear me out.
Are we really that different from any other profession? At the end of the day
most CS curriculums are very much the same. Why can't we do standardized tests
to "pass the bar" so to speak? And additional certifications can be taken for
specialties (e.g. ML, Cyber Security, Finance etc.) like in many other
engineering professions or like specializing in medicine.

Yes, knowing algorithms and data structures IS imporant to being a good
software developer, even if you are building CRUD or mobile apps. But, how
many times to do I need to prove I know them? Yes, showing leadership skills
IS important to being a good software developer. But isn't being a leader
mostly about conflict management, moral obligation and being ethical?

Maybe we can stop fearing becoming a real profession that is beholden to
standards and public scrutiny and embrace it. It will end up being better for
everyone.

For juniors (not in age, but in experience), it offers a consistent
predictable way to learn and grow, and a set of criteria they can focus on
learning to land junior positions. From there we can treat them like
apprentices, and to get certification you need to spend x number of years
being supervised. This allows companies to also retain their junior talent for
longer and their investment in their training can pay off in the long run
because even if they lose a junior who's now certified, they can hire a
recently certified intermediate from another company!

For seniors, it means we can focus on demonstrating why we are seniors (i.e.
I've built these systems, led these projects, etc.), and offers a real honest
predictable path to becoming a staff or principal (i.e. a master).

For companies, it means they can focus on hiring PEOPLE, not leetcoding
machines. They shouldn't have to worry about assessing the technical skills of
individuals. The only reason they do so is because they feel they have to. If
they had confidence that the people they are interviewing are likely qualified
as it is, then they can actually focus their time and effort on more important
things to assess such as if a person is a good fit for the mission. People
assume companies do this because they want to haze candidates. The reality is,
companies just don't have any better way of de-risking their hires at this
time.

We can revisit the criteria regularly to make sure the tests we need to pass
represent what it means to be do our jobs and do them well. We can have
industry input, academic input and so on. We can even have the professional
body accredit programs so as not to have candidates waste their time and to
ensure academic programs keep up with the advances industry makes. Further, we
can make this a global thing.

Rather than shunning becoming a true profession, let's learn from the mistakes
of other professions and build a process that helps everyone.

------
kafrofrite
Just adding on the post. I used to work for big tech companies, I interviewed
for some and also I had the pleasure of interviewing candidates. I mostly
interviewed for security related roles but at some stage, I had constantly
positive feedback from the candidate so I was thrown in to interview
candidates for other roles as well.

I agree with the article, and had my fair share of bad apples so my thoughts
here. Unless the role was something that required dealing with incidents,
there was no point on doing a technical interview onsite and seeing how the
candidate reacts under stress. Generally, noone cares how well a candidate
performs under stress. Instead, I'd let them deal with technical problems on
their own time, if they wanted and tell them to spend no more than 2 days (I'd
actually kill the instance to ensure that). For security positions, I ended up
building a CTF platform and told them to solve as many challenges as they wish
and send back a report.

For the onsite interviews, we did mostly cultural interviews. There was a bit
of technical questions involved, mostly open-ended questions to see how they
approached a problem. This usually was to design some system or, given a tiny
codebase, how they'd go implementing a feature. Also, I did what we ended up
naming "spirals". Successive questions, increasing in difficulty to see how
much in depth they went during their research. E.g. Traceroute -> Ping -> ICMP
-> Differences in Linux vs Windows. This had two benefits. It was clear how
much in depth they would go and two, it was almost guaranteed that at some
point they wouldn't know the answer, which is fine, but forces them to explain
how they would go to find the answer. Almost always, I'd tell them whether
they were on the right path and if they were stuck kinda help them. I'd give
about 5-10 minutes for the candidate to ask me anything. Literally, anything.
For me, this was important because I would get a sense for how candidates
evaluated the company and what they were interested in.

Beyond that, at some stage, we added some questions called internally the "I
read it on the internet". The questions were pretty straightforward, e.g.
given a terminal, tell me how would you ssh in this box as XYZ user or how
would you rm a directory. Fun fact. I initially made fun of the operations
guys asking those questions until I interviewed a series of people where noone
knew how to do simple stuff with their terminals. Btw, I didn't focus at all
on technologies. Given the size of the company, asking "How much you know
about $LANGUAGE" would be futile. I wanted to hire people who could pick up
new technologies and, given the size of the company most of the tools were
custom-built or heavily modified. It was pointless asking "$LANGUAGE" and then
telling them "Well, great, just keep in mind we don't actually use exactly
$LANGUAGE but rather our own version of it". Last, and probably the most
important. I asked myself how I wanted to be treated during an interview. I
kept in mind that I generally wanted to be treated with dignity and respect, I
kept in mind that the resume is basically a snapshot of someone's life and the
candidate is a human being and acted accordingly. Also, I valued for
candidates who asked for feedback and actually I'd give them some and tell
them stuff to read reg. things I felt they could do better. Btw, I also
assumed that each candidate would get an offer and I didn't want them coming
in and thinking "That's the idiot that was acting cocky during the interview".

------
redis_mlc
The interview question that best exemplifies what Neil wrote is, "Did you
write it yourself, or as part of a team?"

Both answers are wrong, depending on the interviewer.

If you say "yourself", you're admitting you're a lone wolf. If you say "team",
then you were along for the ride, even if only two people were on the team.

~~~
otab111
I mean a candidate should be able to distinguish their contribution to a
project in some more fine grained way than this. If they come from freelance
and say "I wrote the code on my own" that's fine but maybe you could mention
how you communicated with the client to establish requirements and milestones
and get to a successful delivery.

If you worked in a team you should be even more able to explain your
individual contribution & the context in which you worked.

This is not a trick question. A good answer is "I did x, y, and z tasks, which
required a, b, and c interactions with the world around me to make sure I was
doing the right work and meeting expectations".

~~~
anonymoushn
I once failed this question at a FAANG company. We were talking about a recent
project that my company did with Pivotal. So like every project Pivotal does,
we spent about one day a week dividing up the upcoming work into tiny pieces,
then we spent the other four days pair programming by doing whatever the top
task on the backlog was. Predictibly, on a team that had 3 pairs, this means I
or my pair did about 1/3 of all things, distributed somewhat uniformly
throughout the project.

"What parts are you solely responsible for?" 0 things, the same as everyone
else who worked on this project! Wrong answer though.

------
crimsonalucard
I had a candidate totally fail the algorithm interview. Is a binary tree
balanced? I thumbs downed him.

I was overruled and he was hired based off of his credentials, resume and what
he talked about in the interview with another person who just had a talk about
"architecture."

Turns out the guy can't even code. He constantly just talks about architecture
and tries to tell everyone to completely change the architecture to be event
driven. But when given an assignment to work on the actual product he totally
fails. It's crazy, the man is a complete clown.

Here's what I think. You can't hire a candidate based off of just a technical
interview alone. But you can't just hire a candidate off of his credentials
either. There's too much room for lies and deception in this area. You need
both metrics in order to get the most information out of a candidate. It goes
both ways.

The Technical Interview was invented because of too much of the above problem.
People who are charismatic and exaggerate their resume and turn out not being
able to code. Of course nowadays with canned memorization going rampant and
technical interviews becoming IQ tests there's really no accurate way
measuring a candidate.

I'll just say that as bad as an IQ test is in identifying good programmers who
are bad at IQ tests, a person with high IQ is likely going to be a good
programmer.

------
mberning
If you were to go in to an interview for a welding gig you would likely be
asked to produce something simple like a cube or other basic shape. Nothing
extravagant, but it demonstrates competency with the tools, materials, and
techniques. I have tried very hard to replicate this in our hiring process.
But the sad reality is that many applicants cannot code to the level suggested
by their resume.

------
codeisawesome
Literally any single person can aspire to be a Software Engineer at a major
tech company by studying online, on their own, with resources that are either
free or modestly expensive.

I disagree that it is a broken process. I do not want the software world to
also start selecting for non-hard-work metrics like who your parents were.

~~~
tomnj
You can work hard at things other than leetcode though, like actual jobs,
personal projects, or learning tech in your field (web frameworks, programming
languages, whatever).

------
jmpeax
"I failed my technical interview, so here's a blog post".

Software is one of the very few industries where lying on your resume and
lying through your teeth about your prior accomplishments can be very easily
tested.

------
ra5
Agree with all points made. Especially with the first point (engineer hiring
tends to be one dimensional) as well as the “your company is who you hire”
point - and even the google example given for that point. Google is great at
software. No one writes better software than google hands down, but what
you/they learn is that it’s not always about how good you code (else GCP would
be the #1 cloud platform). Great write up

~~~
throwaway00081
"No one writes better software than google hands down"

When was the last time you worked within Google?

------
lazyjones
People who hire developers wouldn't be as focused on the candidates'
experience with the technology in the job ad if developers were typically more
open for new tech that would be learnt at the job. Try to teach a 40+ Perl
developer a new language if you want to see what I mean...

When you compare IT with other industries like the author did, this is what
makes hiring so different. Other industries are fine with hiring graduates
with no specific experience and the candidates are eager to learn on the job.
Whereas in IT, half the people will tell you "can't do this", "don't like
that", "won't learn Java" ...

~~~
cableshaft
I’m almost 40. I can learn new programming languages just fine, thank you. And
new languages/tech generally aren’t too hard to pick up once you’ve learned a
few, for the most part.

They do a lot of the same things, just the incantations are different.

I do have more non-coding hobbies now and other responsibilities sucking up
more time than when I was young, so I don’t have as much time to learn them on
my own, but I still can and do learn them, especially if needed at work.

~~~
scollet
Thanks for that. Necessity is is me chopping wood for 8 hours. Everything else
is enjoying the fire.

