
Follow-up to “The dystopian world of software engineering interviews” - Apocryphon
https://www.jarednelsen.dev/posts/what-to-do-when-you-reach-number-1-on-hacker-news
======
achievingApathy
I will never forget the time I was given a coding "challenge" and sent home
with the instruction to send it back whenever I felt it was complete. This
sent my OCD into overdrive, of course. For the better part of two days
straight I coded my heart out and came up with this (what I thought perfect)
robust system with all the bells and whistles. Heard nothing back. At all. My
calls into the recruiter went unreturned and I figured I must have offended
them somehow.

Fast forward a year and a friend of mine gets hired there. Turns out not only
was my code pretty good, but had magically made its way into one of their
production systems. The test cases that I wrote for my interview the year
before word for word copied and pasted right into the prod test runs.

I know this because I used my name as the input for fname, lname trying to be
a bit cheeky.

~~~
e40
One has to wonder, then, why they didn't hire you.

I have a theory. It's quite cynical, but it's taken me about 5 decades to
arrive at it: life is a beauty pageant. I don't say this lightly. It was a
very slow process to get to this point.

A friend, colleague recently interviewed at a very popular, pre-IPO company
that is often discussed (positively) here. He doesn't look like your typical
engineer, but he's literally the smartest person I've worked with. He gets
shit done. He learns new things all the time. As his current manager, I told
him I would give him a perfect recommendation. He had an "in" with a current
employee. He aced 5/6 of the mini interviews, but "failed" one. Fine, it
happens. But, something he said to me stuck in my head: the building of said
company was filled with rows and rows of 20-30 white kids. He saw 2 people of
color, and one was a greeter at the front door.

I don't believe the people that interviewed him were racist, but I think every
person applies a "does he/she look the part" filter and if the answer is no,
the mind finds reasons to not hire.

It's not just hiring that I think is pageant-like. So many things in life are.
So much so, that I think people themselves actually live up or down to their
physical features and characteristics. Look at the executives at a F500
company. Male and female. Why do they look so similar? I live in a somewhat
affluent community. Why does everyone here look like they "belong"? This is
not a gated community, so why does that happen?

Physical features are such a basic filter, applied to ourselves and others,
that I don't think we are hardly aware of it.

EDIT: there are always exceptions. It's been my experience that exceptions are
rare, though. And the exceptions sort of prove my point.

~~~
tonyedgecombe
I often think it would be better to introduce a random element into the
process. Set some minimum criteria then just roll a dice.

~~~
UncleOxidant
Lots of biomimetic optimization algorithms like Ant Colony Optimization do
this. Maybe adding some randomness in the hiring process would be a good
thing?

------
ipnon
What is tragic here is the amount of effort that is now expended by young
computer scientists into the game of algorithms. Whereas a young programmer in
the past may have spent their extra days writing games in Basic or static web
pages, hackers these days seem to do Leetcode until the wheels come off.

We are failing to bring certain softwares into existence by effectively
requiring programmers to their effort into the World Wide Nether, finding the
Kth smallest element in an unsorted BST for the millionth time, for seemingly
no purpose except for it is "how things must unfortunately be done."

~~~
PragmaticPulp
> What is tragic here is the amount of effort that is now expended by young
> computer scientists into the game of algorithms.

This is a funny topic to me. A decade ago, before Leetcode, Hackerrank, and
_Cracking The Coding Interview_ , it was common for developers to complain
that software developers were losing touch with algorithmic knowledge. HN-type
websites were full of discussions about clueless software engineers doing
damage to companies by implementing O(n^2) algorithms that worked fine on
small datasets but failed in production. It was popular to complain that
modern libraries, frameworks, and programming languages were making developers
too soft to write good code.

The industry responded by re-emphasizing the value of CS fundamentals and
algorithmic knowledge. The training industry responded with easy tools to
teach and learn these algorithms. The internet is full of easily accessible
materials to teach these principles to anyone motivated enough to Google it.

Now, the popular narrative has flipped. Internet comment sections want to hate
algorithms and suggest that programmers don't need to understand the basics.
Just rely on the frameworks and libraries to do the right thing. Just Google
the solution and weave the libraries together to do what you want.

> Whereas a young programmer in the past may have spent their extra days
> writing games in Basic or static web pages, hackers these days seem to do
> Leetcode until the wheels come off.

Young programmers don't wake up in the morning and choose between writing
static web pages or grinding leetcode. There are more opportunities than ever
before to learn whatever you want.

Have you actually worked with students lately? Leetcode style systems are a
lot of fun for people. It's a straight to the point system that teaches
algorithms and other fundamentals in self-contained brain teasers that are
straight to the point. And it's trivially easy to Google for supporting
training material. In my experience, the same people who are self-motivated
enough to build web pages and games are frequently also interested in Leetcode
style brain teasers.

People aren't choosing between one or the other. That's a false dichotomy. All
of the highly driven students I've worked with have a range of experience from
toy projects to Leetcode style learning challenges.

~~~
tomnj
> Leetcode style systems are a lot of fun for people.

That’s not true for everyone, especially in such high stress situations as an
interview. I like crosswords, but I wouldn’t want to do them in front of
someone judging me for a job in 45 min while thinking aloud.

~~~
cameronbrown
All job interviews are stressful. Are you just scapegoating whiteboarding?

~~~
tomnj
Not scapegoating anything, nor do I think it’s reasonable to expect interviews
are not stressful.

------
ChrisMarshallNY
I've mentioned this before.

I have a portfolio that consists of six figures LoC of code, across dozens of
open-source repos; most of which I am the 100% sole author.

I've written a fairly large open-source system that is rapidly becoming the
world standard for a specific (rather small) demographic. It deliberately uses
old and rather primitive technology (which is a big reason for it becoming a
standard).

I've written hundreds and hundreds (probably thousands) of pages of
documentation and Web site entries, designed Web sites, and helped hundreds of
people and organizations to develop online presence (all for free). I've run
instructional courses on a number of different topics.

I speak Swift without an accent. I can write ship-ready applications for every
Apple operating system. I've been writing shipping software for over thirty
years.

I'm good with device control. I've written embedded operating systems (long
ago -different beast from today's).

And, of course, I can PROVE it. It's all out there.

And no one bothers to look at my portfolio when I've been contacted to apply
for engineering positions. I usually send a couple of links to repos and/or
blog entries that apply directly to the position. My portfolio leaves
absolutely no question at all about what I can and can't do, technically.

I once even had someone insinuate that I had somehow faked my portfolio. I'm
not exactly sure how they thought I did it. Maybe I hired an Indian shop to
write tens of thousands of lines of code, hundreds of blog entries, design
multiple Web sites, and hack GitHub and BitBucket to fake a decade of commit
history.

At least, that was the reason they gave for ignoring the links I sent, and
instead, giving a binary tree "Draw Spunky" test (I don't do well on them;
never have, never will. I spend exactly 0.0 hours on HackerRank, practicing).

I stopped trying to look for work. I don't need it, and I was getting tired of
the grind.

I just set up my own gig, where I do the stuff I want to do. Maybe someone
will want to work with me in the future; maybe not.

I don't really care, and I'm quite happy.

~~~
dahart
> no one bothers to look at my portfolio [...] I usually send a couple of
> links [...] My portfolio leaves absolutely no question at all about what I
> can and can't do, technically.

I hear this a lot from software engineers, but it might be worth thinking
about the underlying expectation that anyone should spend time poking through
repos on the internet, why they would, and how hard it might be to standardize
a hiring process that compares you to other candidates. Contrast your own
opinion of HackerRank with the hope that hiring managers, who perhaps often
don’t have the time, interest, or even ability to read someone’s portfolio to
determine the quality of the code.

As someone who’s done a lot of hiring, I often glance at an online portfolio
briefly, but I find it to be a low-quality signal for whether I will want to
hire the person, and even for the technical ability. If I don’t know you, I
can’t tell from your online portfolio whether you’re the sole author and/or
how much you’ve contributed to a project. I can’t easily tell if you get a lot
of your code from StackOverflow, or write it yourself. I can’t tell what
motivates you, whether you love programming or you are hoping for a high
salary.

While high technical ability is a requirement for someone I hire, it’s not
actually the primary requirement. What I need to know is how adaptable people
are, how well they’ll work in a team, how quick they are on their feet,
whether they’re friendly under pressure, a whole bunch of things that you
can’t learn from a github account. Communication, attitude, curiosity,
optimism, and cooperativeness are incredibly important traits, as is technical
potential vs existing technical ability. I seek out ways to hire people who
can (and want to) learn quickly, regardless of current skill level.

Personally, I’m totally convinced by your comment that your technical ability
is high, where you say it is. You would easily pass my entry filter and make
it to an interview. But after that, I’d want to talk to you, not sit at my
computer looking through your portfolio.

~~~
ChrisMarshallNY
I've done a lot of hiring, too. I managed a team of C++ image processing
engineers for 25 years. All my coding was on the side, as open-source. I did
it to keep my dev chops up. That's a big reason I have such an extensive
portfolio.

I learn faster, and much, _much_ more comprehensively, these days, than I ever
did when I was younger (I suspect because of the vast context I got from
experience). The main reason I'm doing my own thing, is because I love
learning so much, and I see there's a whole world of stuff to learn.

StackOverflow is a critical tool for me, but only a reckless madman would
stock a majority of their code from there. I use it to solve occasional vexing
problems, from time to time, and _always_ modify the (usually tiny) snippets I
may glean from it.

All the rest is mine. I've been writing original code, often far ahead of its
time, since the 1980s.

I would have been happy to work for a fraction of the salary a lot of folks
far less capable would have asked; simply because I love doing this, and the
challenge of the job would have been the most important coefficient.

But that's water under the bridge, these days. Once I accepted things the way
they are, and just started doing what I wanted, on my own, I became much
happier.

~~~
dahart
You do sound like you're in a great spot, congrats! I've tried to do the same
thing and haven't made it there yet. I did start my own company hoping it
would turn into a lifetime of being able to always do exactly what I wanted,
but it didn't end up working out that way. It was a ton of fun and a ton of
work, and I had to sell it and take a job so I could feed my family.

Would love to hear a little about how you're making ends meet and still doing
what you want on your own. Are you selling software, doing contract work,
making money some other way and doing software on the side...?

~~~
ChrisMarshallNY
Not especially a _great_ spot; an acceptable one. I have enough invested and
working for me that I don't _need_ to work again, but I won't be flying in my
private jet anytime soon.

I also have two corporations, one with restrictions, but decent assets, and
one with few assets, but a lot of flexibility.

------
christiansakai
There is no other sane and effective way to filter the insane amount of FAANG
applicants, only DS&A.

Other non FAANG/Unicorns that don’t pay as well as FAANG can drop the practice
of asking DS&A questions. But for those companies that pay really really well,
there will be insane amount of people that are willing to get a job there, and
DS&A is a “May the strongest win” filter (although luck play a very strong
role as well, yes there are stories where a junior job applicant get 4 Hard
Leetcode out of 5 questions). I happily oblige. I happily will get through
1000 Leetcode and roll the dice (apply multiple times) if I need to in order
to get that salary. No I’m not willing to get lower salary than
FAANG/Unicorns, that’s why I’m doing this.

For companies that don’t pay as well as FAANG, just drop your DS&A interview
practice, or just lower the bar, otherwise it is a waste of time for either
the companies or the applicants.

EDIT:

TL/DR. The whole answer to this DS&A debacle is only 1 thing: SALARY. End.
Period. No other factor matters.

You lower the salary, no one will bother with DS&A. You increase the salary,
every single person on earth and their dog will study DS&A 24/7 to get that
FAANG salary. Don't believe me? Head to Leetcode forum and reddit
cscareerquestions. Actually we don't even need to go that far, just look at
this topic on HN every single time. It is all about SALARY. Full stop.

~~~
peter_d_sherman
But there is a way to filter the amount of FAANG applicants!

It is as follows:

Offer ridiculously low pay, such that only basic expenses could be paid for,
like basic housing...

Then, see who shows up.

Whoever shows up... really wants a job.

You don't hire them yet.

You implement your own corporate bootcamp, where you give then coding
assignments. These start easy, but progress, over a number of weeks, to those
that are similar in form and difficulty to the type of work that the
corporation does...

A supervisor or group of supervisors reviews their work after every week.

People who do not meet expectations are let go.

What you're left with after that process is your new hires.

That's how you cut down on frivolous resumes.

That's how you weed out the casual job seekers from the purists.

The purists don't care about money as much as working with the right people.

It's not for everybody.

People who need salaries obviously, beyond the most basic of living expenses,
would be unable to apply...

~~~
christiansakai
Sorry, this won't work. 1\. Too arduous for the FAANG company 2\. If the end
result is $250k/year salary, then absolutely insane amount of people will
stick it until the end. I know I do. Heck, I will live at FAANG office
24/7/365 if I need to, and I know a lot of people will do it. See the current
state of Leetcode forum and reddit CS career questions to get the feel of the
type A people who flock there. It is go big or go home. Bleed and get up
again.

Hypothetical scenario, tell the startups/VCs to pay more for software
engineers, just a little bit lower than FAANG, then two things will happen:
1\. Either FAANG will even increase their salary even more to attract type A
types 2\. A huge number of applicants of varying quality will flock to CS as
an industry lowering the overall quality, forcing companies to do hard DS&A
questions to filter applicants.

~~~
peter_d_sherman
I agree, it probably wouldn't work for the FAANG companies...

I posted what I said as a note to my future self, if/when I run a software
engineering company... if/when that happens, then that's how I'm going to
handle hiring...

~~~
wanderer2323
Out of curiousity, why do you think that your intake from the `minimal salary
barely enough for living expenses` job posting will contain any talented
candidates at all?

~~~
TuringNYC
They will attract _desperate_ candidates, which some companies often want.
Then they carry the person on a leash.

This will differentiate companies looking for true partnership with an
engineer vs those who need hamsters in a wheel.

------
gavinray
Is it really that rare that companies have legitimate hiring processes and
realistic interviews?

Take this with a grain of salt, because my experience may differ from many
here (never worked at FAANG, I spent a lot of time at smaller startups in
Boulder and am currently in Miami) but I have only been put in front of a
whiteboard one time during many dozens of interviews and it was a generic
logic puzzle to see how I performed under pressure.

Having been on both sides of the hiring table now many times, there is only
one approach that makes sense to me:

1\. Speak to them over the phone to make sure they are decent human being,
verify again in person.

2\. Be upfront with general compensation ability and expectations so that
neither of you waste the others time.

3\. Do a pair-programming exercise where they build a small piece of software
that mirrors something that would be working on as a day-to-day there. Make it
clear that finishing is not important, you just want to see their thought
process and how they communicate. Ask them to refactor parts of it at some
point to see how coach-able they are and how they respond to criticism.

This strategy has worked exceedingly well for me, and when I was on the other
end of the hiring table the companies whose process generally looked like this
were great places to work with good people.

Algorithm questions are a hazing ritual, and so many junior devs get sucked
into wasting hundreds of hours practicing them when they could be building
real-world skills. This practice has got to stop, IMO.

[https://github.com/poteto/hiring-without-
whiteboards](https://github.com/poteto/hiring-without-whiteboards)

~~~
PragmaticPulp
> Is it really that rare that companies have legitimate hiring processes and
> realistic interviews?

In my experience, the gap between the HN comments section and the real world
is massive when it comes to hiring practices.

In the world of HN comments, most people tend to identify with the candidate
rather the interviewers. The interview candidate is the hero, the underdog,
and the person we're supposed to root for. The interviewers are bumbling
fools, drunk on power and dead set on abusing their power to find flimsy
excuses to reject candidates.

In the real world, most of the senior engineers I know have spent considerable
time on both sides of the interviewing table. At different points in their
career, they've been the ones asking questions as well as the ones being
interviewed. This leads to a lot of cross-pollination of interview techniques
as well as different perspectives on what works vs. what doesn't.

We can all agree that interviewing and hiring practices aren't perfect, but
it's much harder to suggest better alternatives. At one point, I tried
directly asking candidates how they'd prefer to be interviewed in a way that
best highlighted their talents. A surprising number of people defaulted back
to standard interview practices, but I also had a number of "just trust me
when I say that you should give me this job" type answers.

These online discussions inevitably skew one way, because no one wants to be
the bad guy defending the current imperfect status quo. Even the author of
this article artfully dodges any request to suggest alternatives, instead
falling back on the safe and secure "we have a lot of work to do" response.

~~~
ScottFree
> most of the senior engineers I know have spent considerable time on both
> sides of the interviewing table. At different points in their career,
> they've been the ones asking questions as well as the ones being
> interviewed. This leads to a lot of cross-pollination of interview
> techniques as well as different perspectives on what works vs. what doesn't.

I'm one of those engineers. The company I currently work at has no problem
finding and hiring competent engineers. I also have no problem suggesting
something better than what most companies do. And yet, whenever I interview at
other companies[0], the most common interview experience I still have are the
horrible ones described time and time again here.

The sort of "cross-pollination" you refer to is not widespread.

[0]: A few times a year, just to keep my feet wet.

------
inertiatic
I don't know, hiring seems inherently broken.

Not just the algorithmic part, even the part leading up to it.

You have to impress a recruiter or an HR drone by listing all the buzzwords
that are currently trendy.

Then, even after the algorithmic questions and interviews where you prove you
can DO the job, you get rejected.

Every company I've worked for had trouble hiring.

I'm working for a company that also has trouble hiring right now. Last week,
the person interviewing our latest candidate told me that despite the
candidate doing perfectly fine, he couldn't come up with something that he
felt excited about doing in his current job, which was a red flag for him.

I tried explaining that perhaps that's something you shouldn't expect from
someone who's at that point switching jobs. We're still discussing how hard it
is to find good people.

Most of the companies I've interviewed for also have trouble hiring, yet I've
been rejected for the most asinine reasons. These companies have the same
positions open years later and not due to growth.

All this rant is to say, we're mostly doing this to ourselves.

I don't have a better way of doing things, but I can't just blame a handful of
big corps for this, as if their technical interviews weren't designed by
technical folks themselves.

~~~
PragmaticPulp
> I don't have a better way of doing things

This is my least favorite part about discussing interview techniques.

It's taboo to say anything other than "interviews are broken", as if there is
some alternative perfect practice that companies are voluntarily choosing not
to use.

If no one, including the author of the linked article, can think of anything
better, doesn't that mean that companies are already using optimal practices?
At least from our current knowledge of interviewing practices. I always have
my eyes open for new research, new suggestions, and new trends, but it's
getting old to hear the constant chorus of "interviewing is broken" with zero
attempt to suggest improvements.

That doesn't mean current practices are perfect or that we should stop trying
to improve them, of course. It does feel a bit like politicians going on
record saying that they're "deeply troubled" by something without proposing
alternatives, though. It's the safe thing to say.

~~~
hakfoo
I wonder if a sensible option might be short term contract-to-hire scenarios.

You have three promising candidates? Instead of trying to extract signal from
gimmick interview tactics, hire them all and put them on a 3-month contract
with the opportunity to renew to full time. Then you're giving them real weork
instead of easily crammed questions, and remove some of the anxiety affecting
interview performance.

~~~
bigtunacan
That would be fine for new college graduates and other unemployed developers,
not so well at attracting talent that already has steady employment.

~~~
perl4ever
If you have a steady job, then there may not be as much social utility in
optimizing things for your situation.

------
klenwell
Glad to hear he hasn't given up. I agree with his basic thesis that much of
software engineering hring is a cargo-cult shitshow. But I haven't given up
hope and have worked on developing a hiring process that is human, efficient,
and effective.

I've outlined it here before. Been using it and tweaking it for the last 3 or
4 years. I keep bring it up because it's a tested alternative to the usual
death marches and dumpster fires and it has been a success for the teams I've
led and our applicants.

The principles I've defined to guide our process[0]:

\- Hiring cycles will be structured and as short as possible.

\- When we start a hiring cycle, we will finish it by hiring the most
qualified applicant who accepts our offer.

\- Every applicant will receive a response within 48 hours and be updated on
the status of their application at each step asap.

\- The hiring process will be as transparent as possible.

\- Objective and fair-minded measures will displace biased and bigoted ones.

\- Every applicant will appreciate their experience, even the rejected ones.

\- The process will be agile and adapt over time to improve and meet the
specific needs of the organization.

\- Onboarding will begin with hiring.

One problem I'm confronting at the moment. As our company grows, we've brought
on a new HR lead who wants to jam the process we've been refining over the
last couple years into a new ATS (Applicant Tracking System) that could
significantly screw up our meez. We'll see how that works out. I'm doing
everything in my power not to let it fall apart.

If you have the power to improve the situation, please do so.

[0] For an outline of the process, see
[https://wiki.klenwell.com/view/Hiring](https://wiki.klenwell.com/view/Hiring)

~~~
andrewflnr
How do you design your coding challenges? Can you give examples?

~~~
klenwell
Sure. We start by noting in our job description that there will be a coding
challenge -- on a laptop, not a whiteboard.

Most of our work is on web applications, primarily Rails. So, for that role,
the challenge is to fix an issue in an implementation of Fizzbuzz on our
sandbox Rails app. We give the candidate about an hour to work on it. It's not
as trivial as the common Fizzbuzz exercise but it's a pretty representative
sample of the kind of work we do.

As part of the phone screening, we check to make sure the candidate
understands there will be a code challenge involving Rails and that they're
cool with that.

There's a handout we present before we turn over the laptop that explains the
issue and clearly defines requirements (e.g. create a branch with this name).
We read a brief intro section then give the candidate time to review the
requirements on their own and ask them if there are any questions. Candidates
are reminded to read the README included with the project and encouraged to
use the browser to Google stuff.

One tweak we made was to add check-in stages to the challenge to make sure
candidate doesn't get stuck for a half-hour trying to open up the text editor
or something. Every 15-20 minutes, a team member will check in with candidate
and if they haven't hit a certain milestone (e.g. has started local server or
had reproduced issue), we'll assist them in getting to it. At the second or
third check-in, it usually turns into more of a pair programming exercise and
at the end we'll review the solution with candidate so they understand why the
problem is relevant to the job.

There's not a definitive pass or fail for the challenge. The candidate's
performance gets scored on a simple 1-5 scale alongside the other competencies
we're evaluating as part of the interview. We're pretty thorough about
preparing the code challenge and consider it a good example of our "onboarding
begins with hiring" principle.

~~~
insomniacity
I like the milestones/check-in idea - will have to use that next time around.

------
skizm
Honestly, I think until FAANG start doing something else, the vast majority of
tech/semi-tech companies will just copy them. A few smaller companies might
branch out and try some other stuff, but most people hiring at mid and large
size companies are just trying to minimize risk more than go grab that great
diamond in the rough. If the big guys are doing X, the medium guys are gonna
keep doing X also.

~~~
zozbot234
I'm actually rather unconvinced that these interviews are positively _good_ at
minimizing risk (false positives). This whole 'whiteboarding' thing has
degenerated into 100% pointless trivia, with many elements of a popularity
contest - I just don't see any reason why we should trust this to yield 'safe'
candidates.

Even sticking to the pure 'trivia' aspect, there's just so much of it that
people are missing altogether. (Sure, maybe you can write out a nifty
algorithm on the whiteboard, but can you sketch even a _very_ rough proof that
the algorithm is correct? I don't think many people can do anything like this.
I'm not even sure that the topic of correctness comes up all that much in a
CS/SE curriculum - which is surprising, since we _are_ supposed to be doing
engineering. And yet, someone who _is_ familiar with what provably-correct
code might look like in practice will likely be a lot more productive as a
result.)

~~~
wutbrodo
> This whole 'whiteboarding' thing has degenerated into 100% pointless trivia,
> with many elements of a popularity contest - I just don't see any reason why
> we should trust this to yield 'safe' candidates.

People blindly and dumbly implementing any practice is going to yield bad
results. I've interviewed for Google, for a small company with a crappy
pipeline and a low need for talent, and for my current job, which needs
Google-level talent across multiple specialties[1]. Whiteboarding has played a
critical role in all of these. The goal isn't to have them answer trivia
questions in marker, it's a basic test of their ability to think critically
and program. Naturally, the exact questions differ based on the role: for the
second job, it was basic processing of data structures, while for the third, I
got a question that involves some degree of spatial reasoning. But in general,
this is a pretty fundamental way to test a pretty fundamental set of skills.

I even was lucky enough to get a negative example: I ran the tech org for the
second company, which had two non-technical founders. We hired a candidate
with no engineering experience on my recommendation because he did very well
in his coding interview: this guy ended up being the most reliable, clutch
engineer in the company. I also rejected a candidate on the basis of failing
the simple whiteboard problems, and the founders decided to hire him anyway
based on his years of experience. The founder ended up having to bounce him
around from task to task, leaving a trail of destruction wherever he went. His
code would bring production down, he'd create weeks of work for others in a
couple of days, he utterly destroyed devops during his brief tenure there,
etc. He was very sweet, hardworking, had a great temperament... But the
inescapable fact was that he was just kinda dumb. The whiteboard interview
handily caught this, _which is what it's supposed to do_, and all the HN
sniveling about whiteboard interviews only being useless trivia contests
doesn't erase that fact.

[1] You can imagine how hard hiring is for us right now...

~~~
zozbot234
> I also rejected a candidate on the basis of failing the simple whiteboard
> problems

OK, but this topic is not about "simple" whiteboard problems. (People can of
course disagree wrt. what's 'simple', but a rule of thumb is that anything
where the average dev would _need_ to train and memorize whiteboard trivia for
an extended period in order to perform satisfactorily is far from simple.)

~~~
wutbrodo
Sure, I don't disagree that it's possible to do whiteboard interviews badly,
but it's possible to do bad interviews of _any_ form. My comment is pretty
explicit about the fact that I'm pushing back the popular opinion hereabouts
that whiteboarding itself is useless, on the basis of these poor
implementations.

------
chad_strategic
I have always hated software engineering interviews. This is a popular topic
on this site, but nothing ever changes. Not sure as I would call them
dystopian, I generally thought they were a chance for a senior dev to parade
his ego. I could tell stories... (As I'm sure everybody else...)

I used to take interviews and I always knew the outcome. "Sorry you are self
taught, we only want people with CS degrees." "Or you don't know how to
reverse a list." "You don't know what a bubble algorithm is" Why did I keep
punching myself in the face?

Well I decided to make a change in the last 6 months, I wanted off the hill,
the ski lift or what ever ski metaphors your want to use. It's summer and I'm
going surfing. (also we both live in Colorado, it's getting little crowded on
the hill and the traffic to the slope is bad.)

I changed my attack, why was I interviewing for these horrible jobs that I
really didn't want anyway. So I changed my pitch.

I now write algorithms for futures/stocks/options, I work for a company that
have a ownership stake in. My code is good, but it might not perfect. No ego
or code reviews. Because the true worth of my code is not how many classes I
use it whether it returns profits. I didn't get into coding to so I could
debate OOP structure or MVC models. I write code so I can make a ridiculous
amount of money. Nothing more or nothing less. The code is just means to make
more money.

Enjoy the lift ride, but I'm going to Hawaii.

~~~
bitcoinmoney
Can you explain more? How did you find a trading company that hires non
formally trained devs? They seem to be the type to only look at Harvard grads
etc.

~~~
chad_strategic
So what I didn’t mention in my response for the sake of brevity. I have an MBA
in finance and a register investment advisor. With out going into a lot of
detail... I became a programmer/coder in 2010-2011 because having an MBA
didn’t really help your job prospects back then. For some reason stepping away
from my financial knowledge and some life events that alter my career path.

About a year or so I decided it was time to get back to my financial knowledge
of markets and my ability to program. I need to get out of the trap of a dead
end programming job. (I was working in Drupal 8... it doesn’t get any worse) I
already had one stock algorithm so I started working on an options algo. Then
via the internet I ran across a family office that needed assistance with a
futures algo. I’m luckily because I have strong academic understanding of
financial markets and the ability to build algo and write code to api’s.

------
watwut
I think that "apparently very few people actually know how to program a
computer" part is more about how many people have "fake it till you make it"
attitude or how large ego they have. Or how much they dont bother how they
look like during interview and keep trying until they get lucky scoring
position. And that _actually is_ how many get to start programming. As in, one
of common advice is to be self-learner and absent reasonable guidelines on
when you know enough, you get a lot of these - and few people who learn enough
to get junior position and are lucky enough to find company that happen to
have junior positions.

We tend to praise people who take the risk, fake it till they make it are go
getters etc. And possibly these are trying for that.

And maybe it would be pretty cool to see a sociological study about who these
people are. What demographic they belong to, what background they have, what
kind of personalities and value they have.

~~~
rm445
It doesn't seem to be all fakers. The situation as described by advocates of
FizzBuzz and the like, is that large minority proportions of people who have
already held down jobs in the software development field, actually can barely
do things that we think of as basic programming, like implement a very
straightforward function. The implication seems to be that there's just too
many to all be actual liars; that they're doing some kind of cargo-cult, cut-
and-paste, stack-overflow based work to keep themselves in a job, changing
things by tweaking them but not actually capable of anything else.

It seems implausible. It's counter-intuitive. But the idea seems pretty
persistent.

It's an interesting question for me personally. I'm a mechanical engineer who
likes to program a little and I've sometimes wondered whether I could work as
a programmer. I haven't got the right qualifications or experience with enough
popular technologies, so moving fields would be tough. But I know I can
implement basic things from scratch. It doesn't seem like much (and clearly it
wouldn't be enough for the prestigious places with really tough computer
science interviews) but it would be interesting to know if that actually was
enough to clear a certain low bar of competence.

~~~
wutbrodo
> It seems implausible. It's counter-intuitive. But the idea seems pretty
> persistent.

Some of us have direct experience with exactly this situation (see my previous
comment). Hell, Jeff Atwood wrote a whole piece on it a long time ago.

~~~
karatestomp
As a programmer who is for-sure well past "fizzbuzz" quality and has been for
a while now, I can just about guarantee I've left interviewers with the
impression they dodged a can't-actually-program bullet when they rejected me,
a couple times.

~~~
watwut
How it happened?

~~~
karatestomp
I tend to basically forget how to use a computer when people are watching. To
prep for interviewing I also have to try to memorize a bunch of stuff about
some relevant language because otherwise, without surrounding stuff to crib
from, I'll straight-up forget basic shit about it, and that doesn't always
stick. I'm talking like "what does method invocation look like in this
language?" Under pressure it can and does happen for languages I've been
working in 5 days a week for the last year. And I guaranfuckingtee if I write
more than a few lines I'll end up using the wrong name for some standard
library function I don't use daily—again, I drill these around interview time
just in case, but it doesn't always stick. I'll also get really timid about
using editor features, if I'm using a real computer and not whiteboarding,
because I start second guessing every keystroke.

Further, most interviews I encounter _don 't_ do this and the ones that do
tend to be all goddamn cagey about what to expect so I never know in advance,
so I don't have a home whiteboard to spend hours and hours practicing on and
if I did I wouldn't know which interviews need such prep and which don't so
I'd probably end up not bothering, since it's just a few that do it.

I don't even have significant social anxiety or anything, and I have been told
I come off as very confident and competent—unless the whiteboarding algo shit
comes out, at which point there's a 50/50 chance I'll look like a total dunce
(Nb. I can and do get The Actual Work done, no problem, once hired—that part's
easy)

Since I only interview every few years and, again, this problem hasn't stopped
me from landing jobs at about the same pay rate as the other ones that rake me
over the coals (though not FAANG or near it) I've not spent the significant
time it'd take to fix this. We'd be talking _lots_ of hours to prep for FAANG
tier, and probably a year. Don't care enough to do that. I did spend the time
& effort to improve how I come off in more conversational parts, gradually,
over the years, but that was relatively easy and doesn't rust as fast (since,
you know, _I don 't get to practice interview-type coding on the job_, but I
do frequently have opportunities to practice relating to people).

[EDIT] I don't mean to be whiny or call the grapes sour—I simply haven't put
the work in to (as I posted elsewhere in the thread) turn my efforts at
leetcode from _practice_ to _performance_. And again, for the roles I'm
applying for I'm not losing any money by occasionally being rejected because
they decided to give me a puzzle expecting a recursive & memoized (DP)
solution rather than ask me whether I know WTF recursion and DP are and when
they're usually useful, so the worst they do is waste a day of my time
(honestly, why the hell are places so secretive about what's going to happen
on interview day? Fucking Google's not, Jim Bob's Software Widget factory can
afford to tell applicants the _sorts of things_ they'll be talking about and
the kinds of exercises that may come up)

~~~
juped
This is a really common experience. Work samples were supposed to be the
answer to this, though I've had really awful experiences with work-sample
companies.

~~~
karatestomp
Luckily I've also been doing this long enough that for every one that asks for
a project or wants me to live-code, there are two that chat with me for 2-4
hours and come away eager as hell to get an offer to me before I accept one
somewhere else, so it's not _that_ big a deal. I mostly just wish places were
more transparent about this stuff so if they're gonna whiteboard me I could
either put in some targeted prep work so I (maybe) don't look like an idiot,
or else say "thanks but no thanks" and save us both some time if I can't or
don't want to cram that week.

------
dang
This is surprisingly better than the usual "You won't believe what happened
after my article got on Hacker News" post (yes, that's a genre) so I'm going
to put it in the second-chance pool [1] after turning the knob down on the
title.

[1] described at
[https://news.ycombinator.com/item?id=11662380](https://news.ycombinator.com/item?id=11662380)
if you don't recognize the term

~~~
codetrotter
Interesting post for sure. Glad it got a second chance.

Speaking of the second chance, from the link you referenced
[https://news.ycombinator.com/item?id=11662380](https://news.ycombinator.com/item?id=11662380)

In that comment you said

> I want to turn this system into something that's open to all users who want
> to take time to review stories. We'll make it a form of community service
> that will be a new way to earn karma. However, it's still an open question
> how to pull this off without simply recreating the current upvoting system
> under another guise.

Have you guys looked or thought about this any more since then? I'd love to
see such a community service become reality.

~~~
dang
Still thinking about it, still want to, haven't worked on it yet, will at some
point.

Edit: if anyone wants to be a story reviewer, find 3 submissions that got
posted to HN but didn't get attention, which you think the community might
like and which gratify intellectual curiosity (i.e. aren't interesting just
for sensational reasons). Oh, and which you're not personally connected to.
Then email them to us at hn@ycombinator.com.

For examples, you can see a partial list of stories that were picked in this
way here:
[https://news.ycombinator.com/invited](https://news.ycombinator.com/invited).
Those are ones where we invited a repost because the original submission was
too old to re-up, but the criteria are the same. We'll publish the full list
at some point.

------
LordFast
I've personally seen no correlation between people who can solve problems and
program when watched by another person versus people who can solve problems
and program when left alone with a real problem, and ample of time to noodle
on and resolve it on their own.

The same is true for writers: most are likely not to be interested and/or able
to do their best work when watched over the shoulder by another person.

The /real/ question is this: should software be like a factory job? If so,
let's clearly acknowledge it and define it, so that people can set their
expectations and self-select accordingly.

~~~
PragmaticPulp
> I've personally seen no correlation between people who can solve problems
> and program when watched by another person versus people who can solve
> problems and program when left alone with a real problem, and ample of time
> to noodle on and resolve it on their own.

At most of my companies, we tried moving exclusively to take-home interview
problems for this reason. Short problems that could be solved in 2-4 hours of
time, as benchmarked against current employees during daytime hours.

Inevitably, some candidates hated this so vocally that they'd ghost us, or
some times even take to social media to lambaste us for trying to take away
from their free time. Or we had people refusing to do the toy problem (not
real work, same test for all candidates) unless we paid them hundreds of
dollars to compensate their time.

It didn't matter how much we tried to explain that the entire purpose of the
take-home problem was to grant flexibility to the candidate. A large number of
candidates vocally hated any interview technique that didn't involve company
employees giving 1:1 interview time to them.

We just filtered those candidates out of the pipeline, but I walked away with
a clear understanding that interview practices will never make everyone happy.

~~~
heavyset_go
> _Or we had people refusing to do the toy problem (not real work, same test
> for all candidates) unless we paid them hundreds of dollars to compensate
> their time._

It's otherwise billable time, don't see why you'd have a hard time respecting
that from a candidate.

~~~
ThrowawayR2
> " _It 's otherwise billable time, don't see why you'd have a hard time
> respecting that from a candidate._"

Sure, as long as the business gets to deduct the cost of the interviewers'
time from that. Not gonna work out in favor of the candidate but respect is a
two-way street.

After all, once the candidate (or a candidate, anyway) joins the team, it's
their billable time being spent reviewing and interviewing other candidates
too.

~~~
heavyset_go
> _Sure, as long as the business gets to deduct the cost of the interviewers '
> time from that._

They can at tax time, whereas an employee can't. If an employer requests work
from someone, they should pay them.

------
cryptonector
HOW IN THE WORLD is this guy unemployed?!

(A: Well, he won't be much longer!)

He writes extremely well. He summarizes a great deal of feedback and knowledge
really well. I don't care if he can code -- though evidently he can. Who would
pass him up??

Granted, there's the question of whether he fits any particular job opening.
But still, there must be many job offerings out there that he could fill if
only the people doing the hiring could see that he's got something very
special going on.

If you work in a team, in a large company, you need great communications
skills almost more than anything else. He's got that down pat.

Jared Nelsen is going places. Ten years from now, when I see his name in the
news, I'll enjoy knowing that I saw this a decade earlier.

------
jerf
I think one of the major takeaways here is, _stop asking algorithm questions_
[1]. Everyone. Just stop it.

In my opinion, and modest experience (I've done several dozen interviews, so
there are plenty more experienced then me, but I'm at least not new, plus
nearly all interviews were for my team so I had to live with the results!) it
isn't _that_ hard to come up with small sample questions related to what the
job actually is doing. From there, in addition to the mere fact of whether or
not they were able to complete the task, you can learn about how they did it,
look at their practices, stop them for a moment and discuss the implications
of something they just did. You can add a wrinkle to the task ("what about
unicode?" "what about cross-site scripting vulnerabilities?"). I also find
being this kind of flexible, rather than being stuck on "did they solve this
algorithm challenge in the _proper_ manner" also gives me room to be human, to
take a moment to try to calm the candidate down in what is inevitably a
stressful situation for them (even if it's basically just Tuesday afternoon
for me in my current position in the world). I think of an interview as "I
want to find all the positive I can", rather than as a process of locating all
flaws, and you can't do that if your candidate is frozen in the headlights the
whole time.

Interviewees are pouring forth a wealth of information. The idea that the only
way to find out how good they are is by asking this one narrow set of
questions is absurd.

And the interview _ers_ are pouring forth a wealth of information too.
Consider what message you're sending with a rigid adherence to something we
_all_ know is broken.

[1]: Unless it _really is_ relevant to the job! I expect that if I'm hiring a
senior level machine learning _researcher_ that you better be able to describe
gradient descent to me, for instance. We may not implement it literally in the
interview but I have a reasonably case for saying the researcher ought to
convince me they could get there. But in a lot of cases, what's more relevant
to me is that you know the _characteristics_ of algorithms rather than exactly
what they are. You can know the runtime and weaknesses of quicksort or RAFT
consensus even if you can't spew the actual algorithms on to a board.

Actually, my parenthetical here almost makes me want to rewrite this whole
post, although this thought is still fresh and I'm still chewing on it. Is
that perhaps the error we are making? Are we conflating _knowing_ the
algorithms for knowing the _characteristics_ of the algorithms? The latter is
legitimately important and I see screwups based on failing to understand
_characteristics_ of algorithms all the time. Knowing the literal, actual
algorithm to the point that you could simply open up a terminal and bash it
out yourself is rarely important in this era.

~~~
mikaraento
Full disclosure: I work for Google and like it

I left Google in 2009, quite unhappy about the difference between a startup
and corporate politics. After that I worked at 3 startups (5 years), 1 telco
(1 year) and at McKinsey (3 years).

I ended up interviewing at Google again in 2018, after deciding that a) I
liked programming more than management consulting and b) my comparative
advantage was in programming. I definitely could have felt entitled after 1)
passing Google interviews once before, 2) having had three somewhat successful
startups and 3) proving I can also handle the corporate side.

I was asked multiple questions that could be interpreted as 'algorithmic' (and
I have to admit that after 3 years of not coding I was nervous about them).
However, they can also be interpreted differently, more charitably. They all
followed the structure of: 1) give a reasonable but not completely defined
problem - you should be able to clarify enough of this to show you can deal
with some ambiguity; 2) turn that into an algorithm - you should be able to
articulate an easy algorithm and be able to discuss improvements to it; 3)
turn your algorithm into code - you need to show you can actually program. I
definitely didn't have to memorize and regurgitate textbook solutions.

I acknowledge that a) the above may optimize for rejecting all negatives at
the cost of some false positives and b) it's still a very basic lower bar and
doesn't predict who will perform highly vs. ok. However, I did think it tested
for the core skills I expect from programmers.

I've also set up interviewing processes at startups. I did end up emphasizing
ownership and 'getting things done' more than Google does. I do think startups
should test for different attributes than 100k+ FTE corporations.

~~~
philjohn
You missed a big one - giving them an idea of how you approach a problem and
work through it. That's the biggest take away.

If someone just spits out an optimal solution straight away that's not
actually a great sign. It doesn't matter if you struggle a little, or need a
few hints, but showing you know how to break a problem down into smaller sub-
problems and work your way up is an invaluable signal.

~~~
watwut
This is incomprehensible for me. If someone happen to see your question before
it is bad sign? And also, what exactly about my internal process are people
trying to learn from "how I approach a problem and work through it"?

I think I tend to make good impression on these ... but I am aware it is
interview skill where I somehow picked up social signals I am supposed to
send. I am adjusting what I am saying to how interviewer looks like (happy,
annoyed, bored, etc). It is social skill, but not same social skill as pretty
much anything I do in actual work. In actual work, people are not interested
to listen to me work out problems in front of them.

It is even more useless if you know the answer and then proceed pretend to
split it into smaller problems and then work your way up or down. That neat
thought process is neat precisely because I know the answer and I am
performing idealized problem solving process.

In case of actual real problem, you don't do that so nicely. You have at least
some bad turns, random guesses, break it multiple times badly and so on.

~~~
philjohn
I’ve been in interviews where I’ve seen the problem before, and know the
solution. I’ve always said so if that happens and the interviewer either
continues and delves into why it’s an optimal solution, or switches to a
different question.

------
rekabis
The “hopeless list”, no. 3:

“If you run into an asshole in the morning, you ran into an asshole. If you
run into assholes all day, you’re the asshole.”

This pretty much sums up my impression of these hiring managers that crank the
bar sky-high: they are assholes through-and-through, and are full of shit to
boot.

If you crank the bar sky-high, all you will get are two kinds of people: those
that interview/test well, but fail at the job, or those who can do both but
will put a crater a mile wide into your payroll due to their high demand
garnering an equally high paycheque.

Anyone who isn’t quite at nosebleed levels of competency can grow into their
roles and skill sets. Yes, they won’t be able to hit the ground running, and
yes, they will have a higher than comfortable drag-to-thrust ratio, BUT THAT
CLEARS UP IN TIME, WITH SUFFICIENT GUIDANCE AND MENTORSHIP.

~~~
scarface74
But while they are getting guidance and mentorship, they are not being a
productive member of the team, taking time away from experienced developers
and as soon as they level up they will change companies and the next company
didn’t have to invest training time.

I know everyone has to start somewhere but from the company’s perspective,
hiring a junior developer doesn’t make sense.

~~~
no_wizard
In my experience a great way to hire and train juniors is to have them do
tasks that need to be done but you can’t over allocate or reallocate an
existing engineer for it. Like refactoring existing code.

Why? The only guidance then a more senior engineer would need to give is
during code review and where they may have questions. It’s a great way to get
them familiar with the code base and train them up. I haven’t seen this be a
productivity killer.

Also, with the shocking frequency I’ve seen, code based need more tests. Have
them write tests! That’s a fast way to get up to speed.

One other point: senior engineers in one code base may have an uptick if a
“junior” in another depending on existing quality, circumstances etc.

I think organizations are lying to themselves that they can only hire seniors.
It’s a myth. Just like 10x developers.

I need hard data to be convinced otherwise not anecdotal evidence. All the
hard data I’ve seen points in the opposite direction of any anecdotal
information I’ve come across.

There are so many volumes of books devoted to these topics alone that I think
most ideas around developer productivity without the firm backing of numbers
are mostly hand wavy and myths we tell our selves to feel better

~~~
scarface74
How would a junior no what to refactor and not make it worse? In my experience
it’s harder to refactor existing code than to start with green field
development.

~~~
no_wizard
You give them tasks with frames of reference. Not all refactored are monsters.
It does require some guidance though that’s kind of the point.

These are just some things I’ve been apart of. I’ve gladly been apart of this
before.

You can as I said also have them write tests or as others noted have them
write smaller features or other things in isolation.

Also how green are we talking is another question entirely. Some tasks are
better fit for people with maybe practical experience in another tech stack
but need to get up to speed in a new language etc.

My overall point which may not have been clear is that there is always a way
to get an engineer up to speed without killing velocity. It’s a management
failure to say you can’t hire junior engineers.

It’s one thing to need someone that’s a domain expert, but often I see “senior
engineer” === “No ramp time” and I think that’s just a lie management tells
themselves to justify not coming up with a good on-ramp plan for new engineers

------
sjc33
Honestly having an interview process that is highly standardized and teachable
+ learnable is a good thing, so I'm not sure why people complain. You know
exactly what sort of questions you will be asked from company to company, and
can spend nights and weekends over a couple weeks studying for it.

Most jobs are not like that, and then you get extreme variance in expectation
with little communication on how to prepare, which is a waste of time for both
the interviewer and interviewee if the interviewee has no clue what will be
asked or expected ahead of time.

~~~
monoideism
The problem is twofold:

1\. False positives: you get folks who do really well at DS&A yet who are
really bad developers. I mean _really_ bad. I wouldn't have believed it if I
had not seen their interviews and then subsequent performance. I'd wildly
guess that it's about 20-30%.

2\. False negatives: you get folks who are really good developers, and yet for
whatever reason, perform badly on DS&A algorithms despite practicing. I think
this number is higher than false positives, probably around 50% or more.

If you're a FAANG company, you can afford to play these odds. If you're not
FAANG, then you're killing yourself by requiring DS&A interviews, almost
inevitably.

Both are contributing to destroying the profession for huge numbers of people,
IMHO. I mean, that's good for me, because I'm almost certainly sticking around
and generally do OK on DS&A interviews with adequate practice (which is a
waste of time, since anything beyond a broad knowledge of the performance
characteristics of various DS&As is totally unneeded for 99% of us). But it's
not right, and I really don't like it.

~~~
christiansakai
Where did you get all of your numbers? My experience dictate otherwise. Plenty
of people who don’t know DS&A and are bad coders, and call themselves senior.

------
winrid
When I interviewed at Google for a front end position they didn't ask me a
single CSS question. It was all algorithms and easy JavaScript questions. It
was just really weird, like at least ask me how to center something. They
bothered to ask me how I'd deal with diversity issues if I was in HR, though.
I probably didn't get the job because of my answers there...

~~~
deanCommie
> They bothered to ask me how I'd deal with diversity issues if I was in HR,
> though. I probably didn't get the job because of my answers there...

Strange postscript that suggests you hold some problematic opinions that
indicate you can't play nicely with others?

Did you fail to get the job because you didn't have the tech chops or is it
because you said something wildly inappropriate on the behavioural questions?

What did you say?

~~~
BurningFrog
This kind of question _can_ be heard as a dogwhistle for

"Are you a leftist? We only hire leftists."

~~~
deanCommie
That's true, in our industry it seems that only leftists aren't assholes.

So if you don't want to hire assholes who think "diversity" is a dog whistle,
you hire leftists.

~~~
BurningFrog
You seem real inclusive :)

~~~
deanCommie
[https://en.wikipedia.org/wiki/Paradox_of_tolerance](https://en.wikipedia.org/wiki/Paradox_of_tolerance)

Inclusivity does not mean having to include those that would exclude others.

~~~
BurningFrog
I don't mind excluding the odd violent extremist.

But if you exclude all non leftists, that's about 2/3 of all Americans. And
that looks very tribal to the rest of us.

The mandatory brilliant essay on this:
[https://slatestarcodex.com/2014/09/30/i-can-tolerate-
anythin...](https://slatestarcodex.com/2014/09/30/i-can-tolerate-anything-
except-the-outgroup/)

~~~
deanCommie
How much of that 2/3 is college educated in the software industry, and is
technically competent enough to pass the bar at Google?

But that's being overly provocative.

Ultimately this started with you saying that a question about diversity could
be heard by some as a dog whistle that only leftists are welcome.

I simply don't agree with that premise. I do think there is a percentage of
people who think diversity is a left-only issue, but I don't think that's
2/3rd of Americans. Then again, Donald Trump hovers around 50% approval rating
regardless of what he does, so maybe I have too high an opinion of Americans.

------
jorblumesea
I wonder how much lost productivity exists in the industry of people who could
be spending their time working on side businesses, or actual work, and are
instead grinding leetcode. I've caught numerous coworkers grinding LC and
working through problems with each other, at work. While obviously unethical,
it's gotten to the point where to get a job, you need to be studying 6 months
out and spend significant time to do so. To the point where you feel so much
pressure that you cut into work and other time to get there.

This is almost certainly to the detriment of employers.

I think if employers understood the true cost of their actions, they might
radically change the interview process. Everyone wants the best talent, until
you consider that your talent is actively studying to become someone else's
"best talent".

------
bit_logic
Whether you like leetcode interviews or not, can we all please agree on one
thing: no more writing code on anything but a computer.

I think this really explains much of the mystery of the 20 years of experience
engineer who can't pass fizzbuzz. Writing code on paper/whiteboard is
completely different from a text editor.

Just think about how you write code. You write a few lines. Run it in your
head. Notice a mistake, add a newline, remove some brackets and it's all good.
Oh wait, you just noticed this can be simplified. Ctrl-A delete all, reduce
entire 20 line function into 5 lines.

None of this is possible on paper/whiteboard, especially in a timed interview
setting. Paper/whiteboard is effectively immutable. You get one chance to
write it down correctly and that's it. There's just no time and it's too
difficult to even add a newline somewhere.

So you put a 20 year programming veteran in front of the whiteboard and they
can't do fizzbuzz because writing code like that is so foreign to what they
do. They can't just write something and fine tune it, which is how software is
written. It must be perfect on the first try. they freeze up and fail.

There is zero excuse for companies to not give a laptop for interview coding.
Even if it's Linux boot CD with nothing but vim and nano, that's still so much
better than whiteboards. And these days companies use hackerrank during the
phone screen. Just use the same website on a chromebook during the onsite!

Writing code on whiteboard is just really stupid. Can we all agree on this at
least?

------
avetisk
I never ask, few exceptions aside, any challenges from the developers I
interview.

When hiring 40+ people for a neo-bank, I did what you should have experienced:
listen to people and get to know them.

The key point of success in a team is of course their skill set, but also the
potential synergy.

Lots of developers are very bad if not terrible at presenting themselves, be
it on a résumé or during an interview. And this has no relation to their
actual skills.

So I always try as hard as I can to actually extract information from them.

First, I let them feel at ease, telling them that this is not a challenge but
a time to get to know each other (which is actually true).

Then I ask a lot of questions about their experience, both in the technical
sense, but also human one.

I try as much as possible to understand how they think and feel, what do they
value, aspire to, try to achieve by joining the company.

I’m not a hiring manager but a 15+ yrs of experience developer. Yet, I find
that hiring developers by actually being one goes much smoother than when
you’re not.

Last but not least, I think that this crazed interviews are becoming more and
more common practice because developers agree to pass them.

If you want to change this, then don’t go through them. There are thousands of
other great companies that do no torture their candidates.

------
jrockway
> Not a single person out of several thousand emails and messages came out in
> defense of the current state of interviewing processes

I thought I was defending it:
[https://news.ycombinator.com/item?id=22332336](https://news.ycombinator.com/item?id=22332336)

------
trashface
Hiring is broken, but so is all of software as a profession:

1) Terrible Algorithmic interviews, AI-based evaluations, whiteboard coding.

2) Hey you are hired! Now move to $BigCity, with expensive real estate,
schools, transit and everything else.

3) So, welcome to the job. You'll be maintaining this shitty old python 2.4
CRUD app that multiple people have tried and failed to upgrade. And one of the
web guys wrote his own UI framework for it, kinda based on Backbone but with a
lot of custom stuff. Yeah he doesn't work here anymore. Anyway that part is in
coffeescript, no we can't change that, too expensive to rewrite.

4) But don't mind that, because you'll spend half of your time in Agile
meetings! How are you with story point estimation?

5) Hmm also we're behind on the schedule. You don't have a problem with 10-12
hour days right? And no we can't cut back on the Agile meetings, that would
hurt productivity.

6) Open floor plan! We think this will help productivity a lot. But sorry, no
noise cancelling headphones, that will hurt interactions. Also the VCs love it
when they tour. Nothing like butts in seats.

7) Here are some options! But they are probably worthless, because we'll never
be successful. Even if we are, we probably won't go public. Even if we go
public, your share is probably worthless because of preferred shares and
liquidation preference. Oh yeah, there is a 4 year vesting schedule and its
ridiculously expensive to buy the vested shares if you leave the company,
which is of course intentional since we don't want people doing that. Anyway
maybe you'll make enough money for a new car, eventually. Imagine commuting in
some sweet new wheels, 5 years from now!

8) Sorry, only a 1% raise this year. Health insurance costs and all that. But
if you like, goto step 1 with a new employer to try to get a real raise.

9) Yes we are aware that the expense ratios on the 401K are 2%, and you are
only allowed to invest in target retirement 20(fn($YourAge)). Indeed that
sucks, for you.

10) By the way you only have maybe 10-15 years of useful programming life
before age discrimination kicks in. So you better get crackin'

~~~
wutbrodo
I hate to break it to you, but I think you've just worked at shitty companies?
If you think that other fields don't have the same or worse issues, you're
dreaming.

~~~
tonyedgecombe
Or you've been very lucky. When I was consulting I visited a lot of companies.
There were only a couple that didn't suffer from at least half of those
problems.

------
camgunz
There's significant ladder pulling. Tons of engineers work at places with
interview processes they could never pass.

~~~
PragmaticPulp
> There's significant ladder pulling. Tons of engineers work at places with
> interview processes they could never pass.

One person's "ladder pulling" is another person's "raising the bar".

Over time, companies should continue to raise the bar for both candidates and
existing employees. As your company grows, you can and should become better at
attracting more talented and ambitious employees. You tend to have more
resources to compensate new hires better, allowing for more selective hiring
practices. Growth means you've learned how to more effectively identify the
best candidates.

Companies aren't being vindictive or selfish. If they can't hire enough
people, they'll dwindle and die. The bar should be set just low enough to keep
enough talent coming in the door, but no lower.

Companies aren't obligated to hire talent at the same levels they did in the
past. It's not ladder pulling, it's just business.

~~~
camgunz
There's a pretty low ceiling on engineering talent, and an even lower ceiling
on that talent being an important differentiator for your company. If that's
your goal, then it's not hard to see how companies just keep ratcheting up the
difficulty with little to negative gains.

------
ChasingReturns
_Not a single person out of several thousand emails and messages came out in
defense of the current state of interviewing processes_

That's largely due to the position taken up in "The dystopian world of
software engineering interviews". Had the article been a defense of current
interview practices, you would have received sentiments to the opposite
effect.

Here's a comment on the original thread doing what you said "not a single
person" has done:
[https://news.ycombinator.com/item?id=22332023](https://news.ycombinator.com/item?id=22332023)

~~~
PragmaticPulp
> Not a single person out of several thousand emails and messages came out in
> defense of the current state of interviewing processes

I agree that this was a cheap shot from the author.

The current zeitgeist of hiring practices is that we're all obligated to chant
"interviews are broken" without ever suggesting alternatives. Suggesting
alternatives is dangerous because someone, somewhere will come up with a
reason why your suggested practice is bad. Even the author of the article
avoids suggesting any alternatives.

It's the equivalent of politicians saying that they're "deeply troubled" by
something, and then proceeding to do nothing because they are secretly okay
with the status quo.

No one is dumb enough to go out of their way to publicly argue in favor of the
current hiring practices in this atmosphere. Yet when we're put in the hot
seat on a hiring committee, we all fall back on the tried and true methods of
interviewing for a reason.

~~~
perl4ever
"we're all obligated to chant "interviews are broken" without ever suggesting
alternatives"

Nah, there's somebody who hates everything, but there are plenty of things
that _somebody_ likes. I'd be happy with both take-home problems at a moderate
effort level, and Fermi problems. Clearly many people go out of their way to
declaim how much they hate those things, and I don't know where to find
companies that hire based on them and pay a lot, but it would make me happy.

------
somerandomqaguy
I'm just a QA but it makes me wonder if perhaps part of it is because software
engineering is so young that we don't really know what a good software
engineer should be. Or perhaps it's more that we're still trying to figure it
out. Compare it to civil engineering or medicine that has had centuries if not
millennia of accumulated knowledge, and who's principles haven't changed much
since over time. The Hippocratic oath for instance is nearly 2300 years old
and yet is still foundational to modern medical ethos. Computers have been
around for the last 50 years, in every day use in the last 30. Barely a turn
of the head in terms of length of human history.

I wonder if then at some point we see computer engineering becoming more
standardized like the others, with a bar that someone must meet before they
are able to call themselves a computer engineer with all of the responsibility
that entails. I wouldn't say that it should restrict someone from programming
professionally without this accreditation, but rather it would be a symbol of
proof that someone has at least been judged by their peers to be at a given
level of skill and knowledge. What this would look like ultimately or whether
it would come to pass, I haven't the foggiest idea though. Like I said, I'm
just a QA guy, not an SE.

~~~
watwut
I am pretty sure principles of medicine and engineering changed a lot over
years. Even Hippocratic oath does not have all that much in common with
ethical expectations in medicine. Most of what is in not is not expected
anymore and most of current medical ethos is not in it.

No doctor is expected to share money with his teachers nor is expected to
teach sons of his teachers. Abortion is allowed and lately euthanasia too.
Current doctors can perform operations and are not required to treat all sick
people.

------
wdb
This week I had a five hour on-site interview and then few days later be told
they won't give a job offer because they think I will get bored within a few
months at the job. Thanks for deciding for me :/

~~~
perl4ever
That means "overqualified"?

------
kbrisso
This is a great article this is _exactly_ where I am at in my life. I have
almost 20 years spent at a company doing all kinds of different projects,
working on many different systems, and continuing to teach myself new skills
all the time on my own time. I'm currently converting a huge legacy Weblogic
Java J2EE project to TomEE. I want to leave so I am now studying algorithms. I
had an interview at a job I really wanted and blew one part of the technical
part because I was a little unprepared. It sucks because I know I could have
added value to the company because I'm a grinder and love what I do. They have
a killer product that would have been awesome to work on and the people seemed
great. I know algorithms are important so I will study on but it sucks in an
interview one stupid question you haven't worked on will cost the job.

------
ScottFree
From TFA: "“WHAT HAVE YOU DONE!?!?”, my inner monologue screamed. My thoughts
spiraled out of control: “YOU’VE JUST RUINED YOUR CAREER! WHY DID YOU HAVE TO
COMPLAIN ABOUT IT ALL!? THEY ARE ALL GOING TO JUDGE YOU TO NO END! YOU FORGOT
TO DOCUMENT THAT ONE FUNCTION YOU ARE REALLY PROUD OF IN THAT ONE GITHUB REPO
AND THEY ARE ALL GOING TO SEEEEE IIIIIITTTTT!!!!”"

Haha, that reminds me of the old days of Slashdot, immortalized is this early
00's webcomic:

[https://www.pyrocam.com/files/images/clanbob.dundundun.dontt...](https://www.pyrocam.com/files/images/clanbob.dundundun.dontthiefau/strip_102.jpg)

------
username90
> There were quite a few admissions by hiring managers at surprisingly well
> known companies that the ability to pass algorithm challenges does not
> correlate with success on the job.

There are a lot of anecdotes like that, but the statistics I've seen has clear
correlation between performance on algorithm interviews and performance on the
job. I don't think there are any public studies done on this though so if you
don't work at a company where you can view it internally you just have to
trust that someone has gone through the numbers at these big data-driven
companies.

~~~
rossdavidh
Well, I can say from personal experience that there are interviews when I've
aced the algorithm question(s), and other interviews when I haven't. Not
hugely different in time interviews, either. So I can say from personal
experience that it doesn't correlate all that well with my own performance, or
it would be constant.

I expect, though, that the issue is that the degree of correlation measured
will depend on the population you're screening with it. If you are wanting to
screen out fraudulent or otherwise utterly non-programmer persons, it will
show a good correlation. However, among those who are actually programmers, it
will show much less correlation, and if you're in a condition of developer
scarcity, the false negatives could be more costly than the false positives.

~~~
username90
> Well, I can say from personal experience that there are interviews when I've
> aced the algorithm question(s), and other interviews when I haven't. Not
> hugely different in time interviews, either. So I can say from personal
> experience that it doesn't correlate all that well with my own performance,
> or it would be constant.

Do you even understand what correlation means? There is a significant random
element to it, yes, but that doesn't mean that there is no correlation, and
the random parts from the same individual can be mitigated by doing many
interviews after which you have reasonable correlation. Most interview styles
has close to zero correlation, so even if we don't reach anything remotely
close to 1 it is still pretty good.

Edit: About the points that it is enough to weed out people using simple
problems, that isn't true either. There was significant correlation between
job performance and interview performance even among those who did well. The
statistics showed no signs of it capping out either, so for all we know we
could make them even harder, just that there wouldn't be that many left that
could pass them then.

------
amadeuspagel
Shameless self-promotion: I launched hirecontributors[1] yesterday, which lets
you search for people who contributed to several of the open source projects
you use.

Shameless nonself-promotion: The Discord "Credentials + Meritocracy"[2]

[1] [https://hirecontributors.com](https://hirecontributors.com)

[2]
[https://discordapp.com/invite/s7bGAQM](https://discordapp.com/invite/s7bGAQM)

------
rustybolt
In my experience, once you have a _very_ basic sense of 'how to program', your
programming skills don't matter a lot anymore. If you work in a team that
underdocuments and underspecifies their project (which is practically every
team ever), communication and motivation are much more important than knowing
how to reverse a linked list in-place.

I have masters in two STEM degrees, which most employers seem to value at
exactly nothing. They are very enthusiastic about hiring me. At the same rate
they would hire someone without a degree, that is.

The thing they want, is multiple years of professional experience with a very
specific set of 4-8 technologies. These are 'must-haves', and then there are
probably 4-8 'nice-to-haves', which are even more exotic demands. And then
companies complain 'that there are sooo little people skilled people in IT'
and 'the IT people have such ridiculous demands!'. In my environment, I see
people with a lot less experience make a lot more in other fields.

(This is how it goes in the Netherlands, at least.)

------
dep_b
> No Software Engineer seeks to become only somewhat proficient and stay there
> for the rest of his or her career.

About 80% of them actually, roughly estimated

------
svartkanin
I've worked as a SE for 8y, in 4 different countries and in both product
development and consultancies.

As it had been pointed out here by most people interviewing sucks. It sucked
in every country for me (some more than others). The process was superficial
and usually didn't give the employer a decent picture about my skillsets nor
did I get a decent picture of the company's environment/tech/culture, meaning
a "we want to implement a new data analysis platform and ML on top of our web
app" was only a nice attraction statement.

Both parties tend to tell some fairy tales what they think the opposite would
like to hear just not to miss out on a possible opportunity. It's a bad habbit
that I've done myself in the past because I don't have employees knocking on
my door every day with a contract in their hands.

One of the issues is probably that a company doesn't know the person who is
being interviewed. Just because someone got hired by 5 companies before and
has 10y experience doesn't mean they know their stuff and therefore everyone
has to go through the same tidious process again and again.

Couldn't there be an evaluation of someones problem solving skills and ability
to built systems, that has a value for all (or certain years) of upcoming
interviews? Lets say I take a test, that evalutates my "can solve problems"
and "can built awesome cloud tech" skills and provides a certificate for it
which is valid for 5y. Of course you'd also able to update your skills
whenever you've learned something new!

So every company looking for a new employee searches in that pool of
professionals with pre-evaluated soft and hard skills for a suitable match.
Not like LinkedIn where you can claim whatever you like but rather evaluated
by other professionals who will vouch for you.

------
jknz
Criticism of interview practices is very common. However, I can't imagine that
large companies that hire in the hundreds/1000s every year (say, FANG) don't
have enough data to have optimized their interview practices.

These companies know in the last 10-20 years who interviewed who and the
performance of everyone after hiring. With enough data you can:

\- A/B test which interview questions better predict future performance

\- how much each interviewer's feedback is correlated with future performance
of the interviewee. Some interviewer's are likely terrible and they should not
interview. Some interviewers at good at predicting future performance and they
should interview much more if not full time.

\- which interviewer provides biased feedback (women, minorities, etc)

Either these companies are not analysing this data and the interview practices
may indeed be garbage. Or FAANG companies are analysing this data and
otpimizing their interview practices accordingly and the process/results are
actually as fair and good as it can be.

~~~
username90
Laszlo Bock found that interview skill is pretty homogeneous, so it doesn't
really matter who does it as long as you just do enough of them. But if you do
4 algorithm interviews you have pretty good interviews.

> Four meticulously orchestrated Google interviews could identify successful
> hires with 86 percent confidence, and nobody at the company—no matter how
> long they had been at the company or how many candidates they had
> interviewed—could do any better than the aggregated wisdom of four
> interviewers.

[https://www.theatlantic.com/business/archive/2016/04/the-
sci...](https://www.theatlantic.com/business/archive/2016/04/the-science-of-
smart-hiring/477561/)

------
zoomablemind
I found this a thoughtful and sure therapeutic writing. Also moving to help
and to encourage!

At the same time, a great deal in this is the level of expectations about the
"greats", finding the right job place at once. I believe adjusting these
criteria might open up a lot more chances to get to doing the craft, be on the
team, well, interview the others too.

Good luck!

------
dehrmann
> I am completely depressed because I can’t get a job”, “I will never succeed
> in this industry

I thought there was a shortage of software engineers right now? Although I
just got an email from Glassdoor with estimated salary (in the Bay Area) being
5-10k lower than the last email, so who knows.

~~~
wojciii
There is a shortage where I live. It has been like this for last decade.

Perhaps you should stop flocking to one location in the states and go
somewhere else?

~~~
dehrmann
There's been a shortage in the Bay Area, too.

------
imafish
I have had one good experience with a technical interview that included a
challenge.

It was a two-part interview, each part lasting around one hour. First hour I
just talked with a single senior developer. About previous experiences,
education, interests, etc.

Second part was a “technical” challenge. I was given a loose specification of
a simple fullstack web application, and then asked to produce wireframes for
the frontend, an architecture drawing for the entire system, a database schema
and a project plan with estimates.

There were no detailed technical questions or exercises. My answers were
nowhere near perfect or realistic - but that was also not the point. The point
was, they wanted to see my thought process when approaching a real software
project.

------
shapiro92
Why the freakishly long post.. Is there any job that doesn't have interview
procedures that fail? Isn't half of the system if not more broken? Taxes,
education, housing..

Why we engineers whine so much about it?

~~~
1MachineElf
Probably because engineering partly about obsessively getting things right,
and so that's the kind of personalities you have opining on this topic in
these spheres.

------
Glyptodon
My big question is whether doing a specially constructed in-person code review
might be more effective than coding some challenge? You could make some sort
of application with a limited size code base but various parts altered both
obviously and subtly for discussion and deconstruction during an interview.
And then after doing a live discussion and review of the codebase instead of
coding, at the end you could discuss architecting a new feature of some of
kind at a diagram and psuedocode type level. Seems potentially more pleasant.

------
deanCommie
I got to the last thread too late for a comment to make a difference, but I'm
exactly the person most of you want to talk to or hate.

I'm an interviewer at a FAANG company with >500 interviews in the last 5
years, I teach multiple internal courses on interviewing, and I think the
system makes a lot of sense for companies at our scale.

Ask Me Anything :)

I currently have a toddler on my lap, but I'll edit this post later today to
address some common criticisms and misunderstandings, but also point out which
concerns I think are valid and where we should do better.

edit:

Okay, let's go through the most important points

1) I'm a Software Developer. I interview other SDEs. I ask them problem
solving coding questions, algorithmic coding questions, data structure
questions, and whiteboard architectural design (not at the same time, but it
could be any of these)

2) Our process is REQUIRED for a company of my size. You would not believe the
amount of candidates we get. We have a high bar for hiring, but fundamentally
we have to be efficient with our time. That completely removes as an option
superior interviewing techniques like "spend a day with the dev team working
on a small real task" or "do this take home test over the weekend and then the
interviewing team will review it with you". Both of these are better at
uncovering good candidates than a whiteboard coding interview, but don't
scale, and are themselves controversial in the industry from candidates who
are unhappy of the time they require.

3) A common criticism of "algorithmic" questions (leetcode) is that they don't
reflect the reality of day to day work. If a lot of people even at FAANG are
working on typical 3-tier front-end-back-end-database systems, utilizing the
tools and systems other employees built before, why bother evaluating if the
candidates could build the next generation of such systems if asked.

Because once these people are inside the company, we'd like to think that
everyone passed a similar tech bar. That means that if a new database or
distributed system does need to be purpose built for a high scale system, and
someone applies internally, you can be flexible with the kind of interviewing
process you put an internal transfer through - you already know they passed a
high technical bar, and are likely qualified to work on the hard stuff.

4) another common misconception is people underestimate the complexity of
"typical" systems inside the FAANGs of the world - compared to their prior job
experiences. A payment processing integration at Amazon scale is not a payment
processing integration at your company's scale. An internal CRM build at
Google scale is not an internal CRM build at your company's scale.

The 10,000 foot view is similar, but the expectation would be that the system
would be 1/ built out faster, 2/ built out better, and 3/ scale better than a
comparable project on a less technically strong company.

5) Coming back to the interview process. What that means, is that when we ask
a candidate to solve a hard algorithmic problem on a whiteboard in 20 minutes,
or deep dive into the inner workings of a complex data structure, or show how
they could combine multiple data structures to solve one problem, we are not
validating "Can this candidate write an algorithm in 20 minutes on the job at
their desk"

What we're checking is "Can this candidate do something really hard,
ambiguous, and time-sensitive in the Computer Science domain, when prompted
to." The real life challenges will be different, but if they CAN do the first
one, they'll likely be able to do the second one.

Of course we miss out on candidates who are terrible at these skills, or can't
code on a whiteboard, or are overwhemled by the interview stress and can't
perform. But we are willing to do that because of Point (2) above. We'd rather
say no to a "maybe" candidate than hire someone who can't perform.

Despite what people state that ability with algorithmic performance on a
whiteboard does not translate to on the job success, that is not my
experience. Remember - I'm not looking to see if a person can spit out A*
search algo on a whiteboard from memory.

I'm looking to see how they approach a problem they haven't seen before, how
they break it down, what kind of assumptions they make, what ways they
simplify it, how they consider ideas and tradeoffs, and finally how their
ideas translate to code (fluently or not)

6) The majority of people I see cannot execute that last paragraph well enough
to join a team at my company and be productive. Sorry, hackernews readers, but
that's just the case. This isn't a "can't solve fizzbuzz" level of
incompetence - these are good engineers who are likely stars at their smaller
companies, and who can be relied upon to get the job done. But they would not
thrive at a FAANG-level company because they lack some ability - either
clarity/coherence of thought, or ability to understand their techncial domain
in depth enough, or because they just aren't fluent at translating ideas into
code.

edit2:

7) All this to say...if you're not FAANG++(Dropbox, Salesforce, etc I don't
know)....stop copying us. You don't need this process.

Your company has fewer candidates, and you both can't afford to be as picky as
us, and you don't NEED to.

Each of my previous companies (in the 200-500 person range) had a process of a
simple coding question onsite, followed by a take home test that a decent
candidate (and I don't mean decent for FAANG, I mean decent across the SDE
community) could complete a reasonable solution in ~2-3 hours. We set
expectations as "you could do it in a weekend" because certainly some people
took closer to 8 and got hired.

~~~
throwawaytousan
I’m a former interviewer for a FAANG competitor that had a successful IPO. I
had to do over 1,000 interviews in 5 years. The VP of Eng told me I was
“highly accurate.” We used leetcode-like programming questions.

I don’t think the FAANG-style coding puzzles have anything new to add to the
conversation here. The reason big companies do that is because the questions
are prompts are simple to write explain (hence interviewer has to do very very
little), the answer space is generally well-defined (so it’s easy to grade,
and easy for a Hiring Manager to check if the interviewer screws up), and they
almost exclusively select for completion time (which is key in a high-pressure
feature house company).

Most of the discussion here seems to be interested in alternatives. Through my
experience, I can’t agree enough with the article author who posts:

Not a single person out of several thousand emails and messages came out in
defense of the current state of interviewing processes - I’ll let this one
stand on its own.

The only people I’ve seen to defend the current process in public are ex-FAANG
people who were actively monetizing their experience (e.g. Gayle Laakmann).

~~~
deanCommie
> FAANG-style coding puzzles

These are not "puzzles". That makes it seem like there is some trick or clever
concept the candidate needs to grasp that show "lateral thinking".

There isn't.

These are (or supposed to be) fundamental problems of computer science that
require good understanding of algorithms, data structures, code performance,
and can be solved in <30 mins on a whiteboard.

Yes, these exist, and there are plenty of them. A pretty common and well known
one is "HEAD to TAIL" \- where you have a dictionary of 4 letter words, and
given an input of 2 words find a connecting path between them changing one
letter at a time. This isn't a puzzle. It's a problem to solve and approach
from different angles and allowing for a large number of solutions of
different performance characteristics

> Not a single person out of several thousand emails and messages came out in
> defense of the current state of interviewing processes - I’ll let this one
> stand on its own.

Means absolutely nothing. Most of us are not interested in ruining the day of
someone who is unhappy with the hiring process by revealing the truth that
most likely it just means the person was not good enough. That seems cruel.
I'm kind of going further here though because this is the second time this OP
is coming up on the front page of hackernews

~~~
throwawaytousan
The questions are indeed puzzles; that's why Gayle Laakmann and others have
made a living publishing books of the questions themselves. And the puzzles
are distinctly different from the content in the majority of CSE curricula.

What's more is problematic is that the construction and evaluation of the
puzzles is highly subjective and nearly everywhere lacks rigor. Completion
time is a key metric while quality of communication is most commonly either
ignored or not assessed at all uniformly among interviews.

(Aside: what's frustrating is that companies make candidates sign NDAs for on-
sites; these prevent candidates for disclosing or _selling_ the information
they might glean in the process, which very rarely happens. In actuality, it's
the former interviewers who violate protections for "confidential info" and
copyright when they go and monetize their experience post-job, or even on-the-
job e.g. Rooftop Slushie).

> Most of us are not interested in ruining the day of someone who is unhappy
> with the hiring process

That's only true in so far as you, as an employee, are paid to achieve
positive sentiment among candidates, no matter how shallow that sentiment may
be. That's indeed cruel, and it's well-established that interviewers are
widely unaware of the consequences of the current hiring process. That's why
we get articles like those from the OP.

A true interest in improving the hiring process includes: * Making prep
materials and courses freely available (helps industry candidates) *
Committing time to CSE outreach to better integrate company needs to CSE
(helps new grads) * Finding questions that reflect real tasks on the job
(helps the evaluation have a chance of being predictive) * Closing the
information gap between hiring managers and candidates: disclosure (in
aggregate) of hiring rates, salaries, etc.

Playing along and doing hundreds of coding puzzle interviews is a waste of
time for all involved.

~~~
deanCommie
> quality of communication is most commonly either ignored or not assessed at
> all uniformly among interviews.

Nothing could be further from the truth at my company

> A true interest in improving the hiring process includes: * Making prep
> materials and courses freely available (helps industry candidates)

Recruiters share this with candidates. They ignore it.

> * Committing time to CSE outreach to better integrate company needs to CSE
> (helps new grads)

Go to any university career fair and you'll see companies with booths
clarifying these positions working against the mis information of negative
blog posts

> * Finding questions that reflect real tasks on the job (helps the evaluation
> have a chance of being predictive)

They do. You don't have to agree, but they do. The real task on the job is
"disambiguate a complex problem autonomously, and come up with a plan to
address it." The interview is a 20 minute constrained version of it.

* Closing the information gap between hiring managers and candidates: disclosure (in aggregate) of hiring rates, salaries, etc.

Semi-agreed. I do wish people and companies were more transparent about
salaries. But there is already an entitlement complex from a bunch of
engineers on this site and many others complaining why some dude at Netflix in
California is making 500k, while he is making 80 in Oklahoma writing code for
Bank of America.

------
mchisto
I have learned from an Amazon recruiter that it was a data-driven decision to
focus on algorithms during interviews. Apparently, on average, it has worked
the best for them than other ways of interviewing.

I think the state of despair is caused by companies copying practices from
FAANGs without understanding the intricacies of why those practices are in
place. To the point of asking a UX/UI dev to solve a DP problem.

------
baron816
Potential alternative to white boarding algorithms: have the candidate do a
code review.

I think that would show the candidate’s communication style and attention to
detail, in addition to their technical knowledge, and probably give a better
sense of seniority too. Most code reviews are done in well under an hour
anyway, vs actual dev work on a ticket that takes hours or days, so you’re
doing more realistic swe work.

------
claudeomusic
A word of advice. You spent the time writing this post knowing full well it
would get a lot of hits but it appears you haven't yet updated your resume.
Little details like that go a long way towards winning over a lot of hiring
managers.Good luck!

------
ipnon
We have to recognize the status quo as an opportunity to revolutionize the
software industry.

~~~
dang
Any thoughts about how?

~~~
eternalban
It could be like this:

[https://en.wikipedia.org/wiki/Bar_examination](https://en.wikipedia.org/wiki/Bar_examination)

[https://en.wikipedia.org/wiki/Architect_Registration_Examina...](https://en.wikipedia.org/wiki/Architect_Registration_Examination)

[https://en.wikipedia.org/wiki/Principles_and_Practice_of_Eng...](https://en.wikipedia.org/wiki/Principles_and_Practice_of_Engineering_Examination)

We do interviews in this field like casting calls. Come on over and audition
for this role. So basically we're saying 'software engineering' is a talent
and not a skill.

------
juped
(Gigantic) thread on the previous post:
[https://news.ycombinator.com/item?id=22331804](https://news.ycombinator.com/item?id=22331804)

~~~
dang
An unusually good thread, considering how worn the topic is, and how indignant
people tend to get about it. (Indignation makes for boring threads once the
coals cool down.)

The top comment is brilliant and sums up the brokenness in the best way I've
ever seen.

------
andreyk
Kinda feel like saying, content aside I think both this and the prior piece
are quite well written. So dear author, keep on writing and putting stuff out
there :)

------
wdb
Sometimes I wonder when you have such a long interview process what the point
is of those super long probation periods.

------
non-entity
Every time this topic comes up, I realize I need to get the hell out of this
industry.

------
zzzcpan
FAANG won't stop, as they put people through hell on purpose. They want them
to dread interviewing and switching jobs, so they can have them for themselves
for longer and pay them less.

~~~
dang
Please don't take threads in this nasty direction. It leads to predictable and
tedious discussion. We all know the situation is broken, but the quality
needed to discuss it interestingly is curiosity, not bile.

If you wouldn't mind reviewing
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)
and posting more in the intended spirit of the site, we'd be grateful. Note
this one: " _Assume good faith._ " That's not because people do always act in
good faith (of course that's not so), it's because the assumption of bad faith
leads to crappy HN threads and the assumption of good faith leads to better
ones.

We detached this comment from
[https://news.ycombinator.com/item?id=22393019](https://news.ycombinator.com/item?id=22393019).

