
Senior Developers Are Getting Rejected for Jobs - voltrone
https://glenmccallum.com/2019/05/14/senior-developers-rejected-jobs/
======
ixtli
We need to admit that the interview process isn't about determining the
relative qualifications of the applications in the pool, because we all know
that 3 hours and whiteboard can't tell anything you need to know about whether
or not that person will perform over the years. We need to acknowledge that we
perform this pantomime in order to satisfy layers of management that are
unable to accept that you can't hire for these positions as you would a
traditional sales position.

Further, I think it needs to be said that at smaller companies (read:
startups) whats _really_ happening is that applicants are being evaluated for
whether or not they're cool enough to join the club. We call it "culture fit"
but we're really just trying to vet their personalities.

EDIT: To be clear I do think people's personalities need to be evaluated,
especially with smaller teams. I just think we should drop the pretense that
"implementing" a depth first tree search on a whiteboard tells us anything
other than that they could summon that algorithm at that moment in time with
that amount of coffee and whether or not they had a pleasant morning. First of
all, I want engineers that are good at working with others, and second of all
it takes months to truly evaluate an engineers ability to do their job. We
gain nothing by pretending this isn't the case.

~~~
otabdeveloper1
Absolutely untrue.

Whiteboard problems absolutely _do_ work.

The vast majority of applicants cannot code at all. And I mean that literally:
they're at a loss at how to write a function that adds two numbers or counts
the number of elements in a list.

Worse is that these guys can be employed as developers (even 'senior' ones!)
for years and years in 'serious' enterprises.

How, you ask? By using copy-paste and cleverly navigating their enterprise
processes and dodging responsibility.

Maybe this is what you mean by 'being good at working with others', but it's
definitely _not_ what I want in a software developer.

Source: I've interviewed a great deal of people for lots of positions over the
years.

~~~
thorwasdfasdf
> And I mean that literally: they're at a loss at how to write a function that
> adds two numbers or counts the number of elements in a list.

Seriously, Where are you finding these candidates? seriously.

I've worked at a number of mid-sized companies, and interviewed dozens of
candidates, and I have never, ever, ever come across a candidate that couldn't
write code on this level: "write a function that adds two numbers or counts
the number of elements in a list".

~~~
rootusrootus
Crappy head hunters. I have some outside firms who have sent me good people
very reliably, and then once in a while HR will make me try another company
who probably gave us a cheap quote, and I'll get a series of terrible
candidates from them. I've even been given outright frauds -- people who paid
someone else to phone screen for them.

~~~
vidarh
Cut and paste answers to initial screening questions was my favorite. How I
knew they were cut and pasted? I got paranoid after some suspicious answers
and started doing searches for random lines from the answers.

The included such brilliant things as cut and pasting an answer from a forum
that was followed by a dozen comments of people explaining how wrong that
answer was, and someone who answered what should have needed a short sentence
with two pages from an Oracle manual giving an answer that did not apply to
the question. .

It's not that we expected everyone to be honest about not using Google - it
didn't matter, it was an initial screening question. But we did expect them to
at least bother to restate the answer in their own words if they looked it up.
And get it right..

------
zulgan
I interviewed ~500 people in a fairly large (~2000 devs) company.

Interviews used to take about 6-8 hours of my week, and I was usually
completely destroyed by the context switch. I remember many days when a
deadline was very close, and I absolutely did not want to do the interview,
but had to.

In general some days I was in good mood, some in bad mood and even though I
tried to make the interview as objective as possible, I am absolutely sure I
failed. Keep in mind, one interview has 5 interviewers and guess what they had
bad days too.

From those 500 interviews, I was certain for about ~5 cases, for the rest I
could not say if it was my fault, or the candidate's fault that the interview
went south, in that case I pretty much voted as the majority was voting.

I still feel very bad about people's livelihood being decided in such shitty
process, there is absolutely no way that in 1 hour I can find out if someone
is good. I knew that, my managers knew that, their managers knew that, and yet
we kept going..

I feel that adding more time/people to the process only increases the
variance, adding more structure to the process only increases the bias (like
we get people who can pass interviews, but not do their job).

~~~
adregan
I noticed that my job enjoyment took a hit during a period of heavy
interviewing for new devs for all the reasons you mention.

A one hour interview required a minimum of 30 minutes prep to read the resume,
etc and generate questions. Then at least 30 minutes to write up my findings
in a way that would allow me to participate in the roundup, which could be up
to a month away if I was the phone screen. The roundup itself accounted for at
least another 30 minutes. So you were 2 hours and 30 minutes into it assuming
everything goes perfectly. It's a huge time suck.

But beyond the time that I lost, it's a very difficult and crushing experience
to have candidate fail and have to be the one that says "no" (and that is
happening way way more than yes, especially if you are interviewing early in
the pipeline). But it's equally disheartening to see a spark of something in
an interview, tease it out, imagine that the person can be raised up to become
a good developer only to have the candidate get shot down by all your
colleagues because they didn't have a similar experience.

I disliked losing time during the day, but I really disliked the emotional
burden of interviewing and saying "no." I empathize with the person on the
other side as I've been there.

~~~
zulgan
I really hated the cases were when "no" can not be explained.

In some cases when there is "no" it comes with clear instructions like: hey
you need to know v8 more or understand hotspot better and try again in 6
months, but then there were those cases where the committee was incapable of
giving feedback.

------
mikelanza
I take a completely different approach to hiring, and I've gotten fantastic
results.

Instead of throwing tricky algorithm questions at a candidates, I scour their
detailed employment records for the most relevant experience for the first
project. In other words, I'm looking for relevant experience rather than top-
of-the-head algorithmic brilliance. In the interview, I pose our project
problem, and the candidate who gives me the most impressive proposal to get
that done gets a chance to solve it.

I hire from an international pool, often on Upwork, so I can start developers
on a project basis.

If the developer does a great job, we hire him/her for another project, and so
on. At some point, this becomes a full-time relationship, with stock options
and other perks.

Using this approach, we value experience over "raw intelligence," per se, and
we end up with a team of self-directed developers who are fabulous at
delivering great finished products.

It's amazing how well this has worked out for us. I think there's an arbitrage
opportunity to avoid coding tests and hire on this basis.

~~~
tempsolution
Yeah this is the M.I.T. and Harvard "process". Hire success, instead of
fostering success. Works well for small companies. If you need to hire 10.000
to 30.000 people a year, this approach is absolutely useless.

Also just because someone can't come up with the coolest solution for your
project, doesn't mean they aren't good developers. This is even more biased
than algorithmic interviews, because algorithmic interviews have structure. I
actually CAN solve a puzzle in 20 mins. You definitely can not solve a project
in 20 minutes or even an hour. It is impossible. And the best candidates will
be those who sit back, analyze the problem for days or even weeks and come up
with a good solution for your project. This approach is so infeasible for
general interviewing that I don't even know where to begin. You are basically
filtering out EVERYONE and take the one person who knew enough upfront to
accidentially solve your problem best...

~~~
javajosh
He said "impressive proposal", not "coolest solution".

To me, "impressive proposal" means "articulation of a workable plan", the
components of which are relatively small, actionable, and take into accounts
requirements, and that demonstrates a good understanding of risk. In fact I'd
argue that the ability to do this kind of top-level break-down well is one of
the best indicators of seniority. The downside is that to do it well requires
knowledge of a very specific process, architecture, and technology stack. That
is, if you're good at breaking down problems use stateful Erlang and OpenBSD
running on bare-metal with web clients, you might have an issue breaking down
using stateless C# on Azure with Android native clients. Some combinations are
more compatible than others, of course, but any senior dev in one stack is
going to have to recapitulate the learning curve of another stack before they
can regain this superpower! (We may like to think that only architecture
matters, but it is relatively rare that an architecture rendered in one stack
is actually isomorphic to the same architecture rendered in another!)

------
mimixco
This _is_ seriously f'd up. When I was hired by IBM years ago, they also had a
test called the IPAT (Initial Programming Aptitude Test) but, guess what?,
there was no programming in it! Instead, the test was designed to see if one
had the basic reasoning and logic skills which would be necessary to solve a
wide variety of programming-related problems -- not one stupid, specific
problem in a particular language. That's just asinine.

Making sure that developers have the "needle in a haystack" solution that
you're looking for almost guarantees that you'll weed out the most talented
folks -- the ones who are programming _generalists_ that can reason about and
solve any kind of programming problem.

~~~
mywittyname
So basically, an IQ test.

I believe these run into legal grey areas because they have to be obviously
relevant to the job in question, which likely leads to the tests getting
progressively more domain-specific as time goes on.

Programming does seem to be a field in which general intelligence is a big
predictor of success. Whereas a field like management probably personality and
general intelligence are more equally weighted.

~~~
andrewprock
_So basically, an IQ test._

Well yes. And that is what the current crop of "programming puzzle" interviews
essentially are; the next iteration of attempting to measure people on a
cardinal scale instead of an ordinal scale.

The key to remember is that evaluating on a cardinal scale is much more
efficient than evaluating on an ordinal scale, so companies will do everything
they can to transform the "secretary problem" into one where they measure
absolute metrics instead of relative metrics.

Now, whether those metrics align with business value is a separate issue. All
evidence suggests that they are largely independent of business value.

------
michaelbuckbee
So there are multiple things that are true with people applying for
development roles:

1\. These "dev gate" programming challenges are filtering out senior devs,
talented devs, creative devs etc. people who would be great at the role.

2\. There are people applying for these roles who can't knock out a decent
Fizzbuzz solution (in any amount of time).

3\. For many roles, there's a flood of applicants

Any solutions to this need must address all three of these things
simultaneously which seems astoundingly difficult.

~~~
thomascgalvin
I think my team has gotten pretty good at this. We address the "flood of
applicants" by tossing out any resumes that don't have some sort of CS or
programming on them (about 25%), and favoring, in order, people who have held
a programming job, people who have done programming internships, and people
who have taken CS classes. A decent GitHub profile will bump you up in the two
later categories.

Next is a five minute phone screen. We're a Java shop, so I ask them something
dumb, like "what's the difference between public, private, and protected?"
Something any Java dev would know; I'm just trying to find out if they have
ever actually used the language.[1]

People that pass the phone screen get a Skype interview, where they write code
in an IDE. The first half hour or so is chat and trivial problems like "sort
this array" or "return true of this String starts with a letter between A-Z,
inclusive." They're allowed to Google and use the standard libraries.

Finally, we have a "close to real world" problem for them to work on. It's a
standalone, mostly-toy CRUD application, and we'll ask them to add a feature
that represents the kind of work they'd be doing. Again, they have their IDE
of choice, Stack Overflow, etc.

I don't think we've had a bad hire since we started using this process. Have
we turned aside some all-stars that interview poorly? Maybe, but the team
we've built is really good at what they do, so I'm pretty happy with the
results.

[1] We have hired Senior devs that don't know Java. One of our team leads was
a C# guy for a decade or so, but he was smart and available, so we scooped him
up. Java is easy to learn. Programming well isn't.

~~~
suzzer99
I have a degree in physics and 20 years of programming. Just out of curiosity,
would I be weeded out in the first 25%?

~~~
traek
> any resumes that don't have some sort of CS or programming on them

> I have a degree in physics and 20 years of programming

Depends, do you mention your 20 years of programming on your resume?

~~~
suzzer99
I thought that meant CS or programming _classes_.

I do have Java, Perl and C++ from SF City College - so I guess that counts.

------
lwansbrough
I straight up refuse coding challenges. I code in the open on GitHub quite
often and have built plenty of very high quality (and complex) web
applications which I can go into intricate detail about. If your company can’t
figure out I’m a good hire without having me jump through your hoops then your
process is trash and I have no interest in working for you.

In fact, I’ve been thinking how _I_ would approach interviewing candidates. It
seems to me a much better way to interview would be to have candidates do a
bit of a show and tell with a project they found challenging. Come in, bring
your computer, show me what you’ve built. I’ll do my best to understand it,
then I’ll ask questions about it: which aspect was the most technically
challenging and why, what was your favourite part to work on, least favourite
and why, what would be your scaling strategy and have them go into detail
about that, etc. I’d much rather hear how a person answers questions about a
project they’re very familiar with than have them do a bunch of arbitrary code
problems. What’s wrong with this approach?

~~~
Redoubts
That’s great. But for some reason every github profile I get to review is just
an empty shell or a bunch of one commit Mooc templates. I’ve almost stopped
looking at them.

~~~
TomVDB
You could take that a great filter: if people explicitly lead you to their
empty GitHub account, what does it say about their judgement?

------
5trokerac3
What ever happened to using a portfolio and references? If a candidate is 10+
years in the business and they don't have a long list of products built and
people who can verify the quality of those products, then what information is
a fizz-buzz going to give you?

Most egregious example: I interviewed at a household name company, whose
entire web stack was built upon a technology I created, and they still gave me
a whiteboard test.

~~~
silentsea90
Sorry to hear that buddy :(

------
bastawhiz
I reject senior software engineers all the time. I give interviews on whatever
language you're most comfortable in, I'm not interested in time or space
complexity, I just care about how well you can use your tools and debug.

I'm continually astounded at the number of people who can't sort a list (with
their language's standard library), clone an array, or do basic string
manipulation. I've had a staff engineer at Google ask what the sleep command
is in JavaScript. A senior engineer from Twitter didn't know how to use arrays
("We don't really use arrays in Scala").

I don't disagree that many companies do interviews wrong. But there's also a
huge number of "senior" engineers who simply shouldn't be senior in the first
place. Perhaps it's a result of companies handing out promotions to keep folks
around rather than to recognize talent.

~~~
wahlrus
Lol. At my job, I code in several different languages. Sometimes, a new
project requires me to to learn to write in a new language. It's not a big
deal... Programming is pretty general, so new syntax doesn't slow me down too
much.

But I can't tell you what the sleep command is any of these languages. I look
it up every single time :P

~~~
jxramos
I’m starting to experience that too, where as the breadth of languages learned
widens I forget the language specifics and really keep the generic terminology
keen. Searching questions like how to sleep in LanguageX, how to iterate,
create a thread, whatever need be.

[https://en.wikipedia.org/wiki/Interference_theory#Retroactiv...](https://en.wikipedia.org/wiki/Interference_theory#Retroactive_interference)

~~~
potta_coffee
Me too. But how do you deal with this when you're interviewing? I'm more
skilled and productive than ever but I feel like an idiot without access to
documentation.

------
lalos
Can someone describe what is a 'senior'? This might be controversial but I see
senior title promotions being thrown around just for retention reasons, could
it be possible that once you start looking for another 'senior' role at
another company they have different expectations of that title? Not to mention
you can obtain a 'senior' title by mastering your team's code base and who
knows if that knowledge is transferable to X team and Y company.

~~~
umvi
Most people self-label themselves "senior developers" after 5 years of
experience. However, it also refers to developers at risk of ageism (i.e. over
the age of 40 or 50)

~~~
JudgeWapner
I know this sounds conspiratorial, but I think the leetcode tests are there to
keep older people out. Because the whole "leetcode culture" stereotype of the
junior/senior bachelor's CS student "grinding leetcode to land his Big-N job"
means that younger grads are going to have seen these problems before and know
how to rattle back the solutions without even thinking. Whereas an older dev
is more likely to have a family or be secure in his/her years of experience to
not waste time calculating the Big-O bullshit of reversing linked lists while
merge sorting. They are more likely to have not seen the problem before and
have to run the gauntlet with no practice. The motivation to discriminate is
purely financial: a fresh grad is half the cost of a 20 year veteran.

~~~
cr0sh
> They are more likely to have not seen the problem before and have to run the
> gauntlet with no practice.

The other possibility is that they have seen the problem before, fixed it, but
didn't know it was called "calculating the Big-O bullshit of reversing linked
lists while merge sorting"...

I have 25+ years of experience; in a month I will turn 46. I don't have a CS
degree, nor even a BS. I'm one of those devs who started basically fresh out
of high school, and made a career out of it. I'm not even sure that is
possible to do any longer.

What I don't have is all of that CS knowledge and terminology. That isn't to
say that I could solve all of those problems, or that I have encountered them,
or come up with the correct or practical solutions. To be fair, I am always
learning something new (and I like it that way). Also, to the "example" you
give, I'd have to look up how to reverse a linked list and what a merge sort
exactly was. Hopefully, there's some kind of standard library for both in the
language I was using, but if I had to do it from scratch, right now off the
top of my head, I couldn't do it.

But I would know how to figure out and ask the right questions on how to do
it, and go from there.

And that's really one of the best skills as a developer to have, imho. There
have been times where I have had a problem, tried to google for it - thinking
it was a common issue - found that it was a common issue, with people asking
the questions - but either no solutions, or worse:

[https://xkcd.com/979/](https://xkcd.com/979/)

...and so, by breaking the problem down, figuring out the answer to those
questions (with either more googling, or implementing a custom solution), then
pulling all those parts back into one coherent answer for the initial problem
- that greater issue can be solved.

Then I find a forum or something and post the solution there, so that future
coders can at least have one good reference point, for as long as the forum
exists. Nowadays, I'd probably put it on my github repo or something.

Ultimately - there are a lot of "senior devs" (both in age and ability) who
are currently in my place; people who didn't go the tradition educational
route; people who were coding in their bedrooms on 8-bit home computers in
assembler and BASIC because that's all we had at the time. We may or may not
have run across those CS-level problems. If we did, we didn't know their names
(much like not knowing the names for certain "patterns" \- yet another similar
thing) - but we still may have implemented solutions for them anyhow.

~~~
JudgeWapner
yeah I just grunt and snarl when I google and find a forum post from 2007. I
wish there were an easy way to filter by date.

I have faith in your problem solving abilities. I'm 35 and have a CS degree.
The _only_ time I've needed to know Big-O or how sorting algos worked was in
college and during interviews. I've literally _never_ been in a situation
where the code functionally worked, but ran too slowly because of an
inefficient algorithm (and this is with 13 years as a C++ developer).

As for your situation, I suspect many shops would turn you down because you
didn't rattle back the answer from memory. But the concern isn't that you
aren't smart enough, it's that you're "old" and cost too much. The kid who
memorized leetcode can be bought cheaply and discarded easily if it comes to
light that he/she can't figure out how to solve a tech bug. If you "follow the
money", these interviews could be seen as purely "cheap-but-comptetent people-
filters". Because if an old programmer tried to sue them for age
discrimination, they could point to leetcode as evidence that all the tests
were administered "fairly".

------
llamataboot
Recently went through a process that had 5 hours of interviews, then a take-
home (said 8 hours, took 16), then a full day on-site, then a reference check.
Then not advanced with one sentence from a stranger ("We've decided not to
move forward...") Asked for feedback nicely twice, no response, ghosted.

\--

Been my experience with multiple SV startups now. In some cases went through
back-channels to find out what happened (In one case - whole team loved you,
CTO had your offer, CEO overrode at least minute and wanted a non-US
contractor to avoid benefits pay)

\--

Utterly absurd amounts of time and you still can't be sure!

\--

My proposals -

#1) Companies that want take-home work or multiple day interview processes
after initial screening /pay/ for them. You are already paying for your
engineers to be inteviewing/etc. Pay the applicants. Keeps incentives aligned
(you only advance ppl you really want to see how they work, you don't expect
40 hours + of work from me because I should feel blessed to get the
opportunity to work for you...)

#2) More conversation. You can get way more ideas about someone's technical
acumen by asking them how they know when to refactor, what they think about
tradeoffs around technical debt, how they would think about data modelling
something, etc than writing code. A brand new programmer maybe do some
pairing, a person that has been writing production code for 3,5,10 years? Ask
them the interesting questions and just talk!

#3) Hire quicker/Fire quicker - I think Riot for example will pay you money if
you decide it isn't a good fit and you leave. Everyone is already employed at-
will. I'd rather have a 3 month probationary period than try to find time for
40 hours of interviews while working my day job.

~~~
Topgamer7
It's quickly become common for a company to assign a homework assignment that
will take "2 hours". However the nature of development is often a process of
debugging (even if the end fix is stupidly simple, just difficult to nail
down).

This is a cancer because many hiring managers will assign out these homework
assignments to all the applicants, before doing almost any due diligence or
getting to know an applicant.

If you want someone to jump through 8 hours of interviews and calls, then 8
hours of coding, you should be paying them at least for the coding.

------
cr0sh
In a little over a month, I'll be turning 46. I've been doing software
development professionally since I was 18. I have no formal education in it,
except for a couple classes taken at a CC for C++.

Between hearing things like this, the way the internet is going, the way cell
phones are becoming more closed up and walled in...just everything about the
way the world is going...

...I honestly am beginning to think my best course of action would be to
(somehow) change jobs entirely, move out to the middle of nowhere on 40 acres,
drop off the internet, build my own cellphone (which I've mentioned), and just
go back to hacking on my TRS-80 Color Computer. If I ever accessed the
internet again, it would only be for email and maybe the occasional "telnet
BBS" \- and that would only be after a 50 mile drive into "town".

While I know and understand that despite 25+ years of experience I may not be
at the same level as others with fewer years, that time should count for
something. In my case, what I lack mostly has been any sort of opportunity for
a "management" role; I have never been a team lead, for instance. It pains me.
It does nothing for my self-esteem as a software engineer.

But that shouldn't count against me. Nor should being able to solve some rando
problem concocted as a gatekeeper. I've worked at places for short periods,
and I've stuck around at places far longer than I should have. But lately
things have been hovering around jumping at 3 years, and that time seems to be
coming up for me at my current place of employment.

The thing is - I don't want to leave. I like it where I'm at. I enjoy the
problems. I enjoy my coworkers. I enjoy the development environment. But more
often than not, it seems, outside forces seem to conspire to kick me out
whether I want to go or not.

Maybe I'll get lucky once more and land a new position. Maybe I can use the
fledgling skills I have in ML in some manner. Or I might have to drop my
salary requirements down and take something lesser, just to stay employed?

But at some point in the future - the near future - it feels like it won't
matter what I do or don't do, I won't be allowed to "make the cut" any longer.

Thank $DEITY I have no debt other than my mortgage...

~~~
bob_doggo
My first thought upon reading this was: "If you don't want to quit your job,
then just stay."

So, is it you are working on a project, and when the project is finnished
there is no work left, or do you think thay you will get fired, or what am I
missing here?

~~~
cr0sh
> My first thought upon reading this was: "If you don't want to quit your job,
> then just stay."

Well - that's always what I try to do, but the last several places I've
worked, the decision was effectively made for me, either due to a layoff, or
because the company closed down, or because it was bought out (and I was given
a real stupid offer to stay), etc.

> So, is it you are working on a project, and when the project is finnished
> there is no work left, or do you think thay you will get fired, or what am I
> missing here?

> My first thought upon reading this was: "If you don't want to quit your job,
> then just stay."

Well - that's always what I try to do, but the last several places I've
worked, the decision was effectively made for me, either due to a layoff, or
because the company closed down, or because it was bought out (and I was given
a real stupid offer to stay), etc.

Currently, it's because the client I work for, on behalf of my company (I'm
part of a small team here, but the client is international, and the larger dev
team they have in place is the same), has made a decision to outsource the
work we do here in the USA for a different international team (who likely is
cheaper). We will be training our replacements on how the system is
designed/working. Once they are "up to speed" (we imagine), our team will be
cut loose.

Our boss (owner of the company - it's a small boutique web application
business) has assured us that we have an internal project waiting for us,
which we've been told about and have discussed, for us to continue on with. It
is supposedly fully funded, which I don't have any reason to doubt. The owner
is a great guy, and has been up-front about everything going on, and I trust
that this will work out. I've told him that so long as the paychecks don't
bounce and I still have health coverage, I'll stick around. I really do like
our team and environment. I also like the idea and concept of this new
internal project.

But I've been doing this long enough that even that may not be enough. Things
have a way of turning in business where at one point, things might seem ok,
but then overnight a painful adjustment has to be made and you find yourself
without a job. I've also told my boss as much, not to sacrifice his business
on account of trying to keep us all employed, because I've seen in the past
employers with similar small companies I've worked for completely implode
because they kept trying to make things work and keep their people employed,
when scaling back would have been the better option. It's noble and nice to
know when an employer acts that way, but from a business perspective it really
is the wrong decision at times. So I've let my boss know that I understand
this, because he's that kind of guy - he doesn't want to lose us, we're a good
team (talent-wise and such), but I don't want to see him lose the business
either.

I'd rather he would stay in business, and maybe I could return in a few years
or something when things are looking better.

But so far - there's nothing to indicate that anything like that is going to
happen. We're all still employed by this client. The company I work for,
itself, has other clients (I am part of a small team tasked to work with this
singular client; there are other devs who work with other clients on other web
application projects), and this new internal application could turn out to be
something wonderful for the company, if we play our cards right.

But I worry because our team lead left for a new position, because he has a
family and needed more stability. I worry that the remainder of the team may
take that same option, due to similar reasons. I don't have to worry about
such issues; I don't have kids - but I do need to be paid to pay my bills, and
I need health coverage (more a necessity as I get older).

But there's the possibility - if the rest of my team leaves for "greener
pastures" \- that the internal project may be shelved, or that I can't work
alone on bringing another foreign team up to speed on our current project, or
whatever, and at that point, it may be more beneficial for my employer to let
me go than to keep me (and, after all, I've told him that he should do as
much, right?).

I wouldn't begrudge my employer making that decision, but it doesn't mean I
don't worry about it, either. The one thing that keeps me from worrying too
much, at least in the short term, is knowing that I am "debt free" (except a
mortgage), I have plenty of savings (enough to cover 2-3 years of salary if
needed), and that I don't have to provide for a family other than my wife and
dogs. In short, I can make things work for a while, until I can find something
else or do something else. But it doesn't mean I don't worry about the whole
situation...

------
alexandercrohde
At this point it seems like a tired HN discussion.

1\. Everybody agrees interviews and tests have some signal, some noise.

2\. Some interviews are systematically biased toward skills that aren't a good
sample of what work is. But people just want to whine about it rather than
propose a better solution.

3\. Nobody can agree on what the important skills are for engineering anyways.
Which is natural, since it varies situationally.

~~~
Ancalagon
Actually I would say there are plenty of counterpoints in this thread to your
second and third points.

~~~
alexandercrohde
_shrug_ Seems dubious to me...

Likeliest scenario people say a bunch of vague phrases like "communication
skill" and "culture fit" and "diligence" at each other, forget they had this
conversation, and thread continues to happen every 2 weeks for the next 10
years (I guarantee this conversation has happened no less than 100 times here
already).

Hypothetically not-meaningless form of collaboration that would never happen
on HN -- people form a google doc and come up with concrete questions that
they upvote/downvote to come up with a great engineering interview, and each
new discussion adds to the list.

~~~
Ancalagon
Well I mean even that suggestion you just made for a collaborative google doc
is excellent and is the kind of counter point I was talking about.

The main contention developers seem to have (in my mind) isn't necessarily all
whiteboarding interviews. Its the ones with ridiculous problem complexity and
timelimits of under an hour that require inordinate amounts of study every
time someone begins their job search (Dynamic programming in 45 min comes to
mind). I think there are plenty of good alternatives in this thread: take-home
assignments, paying developers to study and take these exams, github code
reviews, even just restricting the problem space of a whiteboard interview to
less complicated problems are all good suggestions.

The other point I was trying to make was that generally the skills you want to
test for in an interview are those applicable to the job. Others in this
thread have argued that these whiteboarding problems do in fact test some
important subset of the skills needed by most developers. Others have pointed
out that at some point though, its gotten ridiculous, and knowing how to sort
and array in O(nlogn) is not really applicable to all the jobs interviewing
for that knowledge, and it would be a better use of everybody's time to
instead test for some other subset of knowledge (SQL use, CRUD application
construction, etc.)

Finally I just wanted to point out I am an interviewer at my current company.
I do take a lot of these conversations to heart. I have tried to experiment
with the interviews I give to make them better for the candidate, and better
for the company. Anyways, just pointing out I do think these conversations
have an impact :)

------
imroot
I'm in a similar boat -- my educational background is hardware engineering,
but, I've been a Linux nerd/SRE for the last 20 years. Ask me to test an 3x10
LED array? Can do it in my sleep, without even looking things up. Ask me to do
a B-Tree? I'm pulling up documentation. Ask me to do a deployment in AWS, GCE,
or Azure, and I've got the code to make the API calls without the help of
boto...but ask me to do the same in VMWare, and I'm a fish out of water.

I've got a technical interview on Thursday, and they use Hackerrank for their
coding platform. I'm seriously hoping that they have something that's specific
to SRE tasks, because, if they ask me an algorithm question, I'm almost 100%
certain I'm going to fail -- these weren't things that I studied in my EE
degree, but, I've learned how to implement things from my positions over the
last ten years.

I know what I'm doing, and I feel comfortable thinking and looking for
solutions that aren't "inside the box" \-- delivering an OS and DB upgrade to
8000+ stores via a USB Stick -- complete with a dashboard that I wrote,
microservices soup to nuts (meaning: I worked with the developers to make
better containers, and then wrote the ansible playbooks to deploy OpenShift in
EC2) for a major hotel company, web governance/best practices for a top 5
Quick-Serve Restaurant chain. Asking me the difference between a Markov Chain
and a B-Tree isn't something that I've ever needed to do...

On the other hand, when I was hiring in the Washington DC area, the number of
Senior developers that I'd get from government contractors who couldn't count
to 1000 by 5's in a language of their choosing really hurt my soul.

~~~
monster_group
>> I've got a technical interview on Thursday, and they use Hackerrank for
their coding platform. I'm seriously hoping that they have something that's
specific to SRE tasks...

If you want to do well on the interview, you should brush up on recursion,
binary trees and hashtables. If they are using HackerRank, it is almost
guaranteed that the questions will be algorithmic rather than SRE based.

------
samcodes
Required reading on the subject:
[https://erikbern.com/2018/05/02/interviewing-is-a-noisy-
pred...](https://erikbern.com/2018/05/02/interviewing-is-a-noisy-prediction-
problem.html)

I realize that there are problems with it, but I'm a huge fan of take-home
problems that are similar to real problems the candidate would face on the
job.

~~~
stygiansonic
Thanks, that was a great article and well researched. Also discovered a few
other interesting tidbits on that fellow’s site.

------
markbnj
Timed programming puzzles are silly and self-defeating, for the simple reason
that writing software is a creative process, not a production process. It's
the same reason why kloc metrics were dumb and have been mostly and justly
relegated to history's dustbin. These things are dreamed up by hiring managers
to cut their workload, and for the non-technical ones it gives them some
simple thing they can comprehend and make a decision on.

I understand the attraction of simple decision metrics, more so if you're in
the unfortunate position of having to make a technical hire with no experience
of your own to guide you. But consider the referenced tweet that implied 250
resumes were too many to read. You're going to hire someone to do a highly
complex job, spend months getting them up to speed, probably work with that
person for at least a few years, and you can't come up with a way for your
company to at least scan 250 resumes? I mean it's like pretty close to the one
main thing you're there to do: find and hire the right people.

------
alkonaut
A senior developer should have a CV, maybe some hobby code, some references, a
commercial product they can describe or point at. Giving them programming
puzzles is a waste of time. I get that they can be useful to filter out some
bad recently-graduated-from-a-bootcamp developers.

The antipattern here isn't that there are puzzles. The antipattern is using
some external screening service using the same process for all candidates.
There shouldn't even be a HR person screening before the team and hiring
manager is.

~~~
chadash
The problem is that if you don't have any screening, then you get a flood of
candidates, and it takes someone's full time job to sift through them. HR
needs to be well trained on what to look for, but they are often a necessary
gatekeeper in my experience on the hiring side. The goal is to keep the number
of qualified candidates who get filtered out at a reasonable level.

(I completely get that this is unfair. If you went to MIT and have a high GPA,
you are gonna make it past the gate more often. Community college, but an
excellent coder? Unfortunately you will be rejected more often by HR. It's
completely unfair, but companies can't reasonably interview every candidate
who submits a resume.)

~~~
alkonaut
When I get a lot of responses it has been ~100. I have found it pretty easy to
read all resumes and pick 10 or so candidates to interview. Compared to the
amount of time the interviews take, the sifting through resumes is pretty
quick work I think. If there were 500 or 1000 resumes the situation would be
different, but then I’d perhaps use a HR/recruiter person to just give me the
100 that meet the requirements. No phone screen or coding challenge needed.

------
briandear
I despise HackerRank and that ilk. I am a (actual) senior engineer at a FAANG
in Silicon Valley and can barely do those contrived problems but am
approaching my second year at one of the biggest companies in the world
working on “serious” build engineering stuff and never once have had to invert
a binary tree and display my results using STDOUT.

Honestly, command line Linux skills and a take home (<1 hour) “build an app in
<relevant language> that does x” is far more relevant to my work than some
timeboxed HackerRank contrived example.

My favorite screening tools have typically been “here is an app with failing
tests, fix the failures.” I have been screened out of all manner of dinky
companies from these contrived tools. A reasonable oral technical interview to
ensure the candidate can communicate within the domain is far more valuable
than contrived tests of solving problems unrelated to the actual job. I can
learn more about a candidate asking about use cases of SOA than I can by
watching them calculate prime numbers.

------
baron_harkonnen
As an older, experienced developer, this is honestly just a sign of a changing
shift in the nature of software companies, and, like it or not, if you want to
survive you have to adapt.

I started in software over 10 years ago. At that time all of the exciting jobs
where for small startups and the best way to get hired was to have a great
github profile or some cool projects to show off.

But small startups need a hand full of really talented devs who can solve a
variety of problems, and quickly get up to speed on new domains and tech
stacks. A few good developers could make a company. So hiring focused on
individuals who stood out and had something unique they could bring to the
team.

But FAANG companies want to hire engineers that they can treat as replaceable
parts. The "rockstar" talent that was required a decade ago is a liability.
This may sound like a critique but it makes perfect sense from the business
standpoint, and while you can protest this all you want it won't change a
landscape dominated by large software giants to one fill with disrupting
startups.

It's just a different world and if you want to show that your "experienced"
and not just "old" you need to show that you can adapt just as well as a
decade ago. I had a moment of enlightenment when waxing nostalgic about github
profiles to a really talented new engineer doing prestigious work in deep
learning. I told them how much better profiles based interviews where and they
reacted with horror. "How am I supposed to build a profile when I'm so busy
with school, interning on the side and studying for interviews!?"

Software used to be dominated by passionate hackers, and now it's one
increasingly of skilled professionals. The best work people just as hard but
in a very different way.

Like it or not, software is not like it was a decade a go, and if you still
want to be seen as a top tier engineer you're going to have to do it by the
standard of today.

------
cletus
Another day, another "coding interviews are broken" post on HN, the same old
replies. So here's mine.

\- A vast number of people masquerade as "programmers", "engineers" or
"developers" who couldn't code their way out of a paper bag. If you don't
believe me, you haven't conducted interviews.

\- This was the key motivation behind FizzBuzz. Passing it doesn't mean you're
a great programmer. Failing it means you're almost certainly not. So the
ability to turn a super simple "algorithm" into code in [language of your
choice] is an incredibly useful negative filter.

\- Interviewers and companies fall into the trap of thinking "this problem is
too simple; let's make it harder". In doing so you devalue the negative filter
and gain NOTHING as a positive filter. Worse it can turn into a gamble as to
whether you happen to know the particular trick for that problem. Tortoise and
hare or O(log n) bit reversing fall into this category;

\- Taking a problem and being able to reframe it in terms of standard data
structures and algorithms like recognizing it's a particular graph problem is
an incredibly useful skill. These don't always need to be turned into code.

I'll say it again: the biggest problem is people try to make whiteboard
problems "hard" making them a useless signal.

I'll add:

\- I'm dead against "take home" tests. I don't have time for that. This seems
like a great way of getting mediocre candidates. Like, what makes you think if
someone can't do it they won't "cheat"?

\- Talking about robust systems design isn't done often enough;

Here's another thing I've pondered: how much of coding interviews and the
notion of "cultural fit" is really thinly-veiled discrimination? I expect
quite a lot and I expect this to blow up at some point.

------
mgamache
I am sure all these methods were validated as significant predictors of job
success using longitudinal data, right? It's not like the bad old days where
managers and HR people would just ask questions they thought were relevant to
the job (or flip a coin).

[https://www.forbes.com/sites/work-in-
progress/2015/05/21/why...](https://www.forbes.com/sites/work-in-
progress/2015/05/21/why-job-interviews-are-like-flipping-a-coin/#65d73319705d)

------
leeter
Crap like this is why I won't interview with a few larger companies and are a
major turn off when smaller ones pull this garbage. I'm one of the people that
when you try to quiz me my mind blanks. I hate whiteboard programming and
prefer solutioning instead. If you want to see code I have a github I can send
you. Or you can send me a programming challenge I can complete on my own time.
Things like this have actually led me to basically tell at least one large
company to cease and desist all recruitment efforts with me.

------
raiflip
I agree with the basic sentiment of the article, but the question that always
pops in my mind is, based on your real life work experience, what kind of
(simplified) question would you ask in a 60 minute interview to gauge
someone's ability to write, say, a distributed service?

It goes without saying that 60 minutes is too short a time to ask someone to
solve a real life business problem, but real life business problems tend to be
broken up into many small problems, which can in turn be simplified and
presented to the interviewee.

The discussion I've been having with colleagues is how to do precisely this -
eschewing the typical leet code/hacker rank problem, what problem can we come
up with that has high fidelity to real life work, without being too complex
for the 60 minute interview? I definitely think this is possible, and normally
you get to that kind of question by working backwards - what is a real life
feature I'd implement, and how can I ask a version of that during an
interview. One example would be a graph of similar categories. Categorization
is a common issue, and graphs are a common data structure.

Side rant - I've seen a lot of hate for things like data structure questions
and algorithms associated with data structures. It's definitely possible to
have an entire career of programming where all you do is build CRUD endpoints
and design relationships between objects, but sitting down and learning about
these amazing data structures that have been refined over decades of work can
seriously improve a lot of code. A common problem I've seen is people building
rigid object hierarchies (by composition, not inheritance) where a tree would
have been way more flexible and easier to understand.

~~~
mixmastamyk
A simple question can weed out the bozos, but a hard/tricky question won't
select for the exceptional. The reason being that most folks can't solve a
hard problem they've never seen with a gun to their head and no time for
research.

A hard problem with no practice is effectively impossible unless lucky enough
to have faced the exact same on in the last month. Selecting for the lucky at
that point.

Lets dispense with the fantasy we can select the "best" in an hour, and move
toward short contracts instead.

------
losthobbies
This happened to me recently.

I have over 8 years experience as a developer and applied for a Senior .Net
Developer role. I have plenty of experience in the technology stack and worked
as lead developer on some high profile projects in my current role which have
been successful. I'm no rock star but I get stuff done and I work well with
others.

The company liked my CV and cover letter and send out a HackerRank link for me
to work on. My first thought was "sh*t" as I struggle with these things but
also how impersonal it was. The everything was weighted on the HackerRack
test. At least speak with the candidate and get a feel for them. Even a phone
call.

Hiring as they say is one of the hardest things you can do. It's time
consuming and costly so I think they have these tests as away to cull the herd
so to speak but it's obviously not ideal. Basecamp have a podcast called
rework and one of their episodes called "Hazing not Hiring" deals with this.
It's really interesting.

For me, I'm going to try to work on a side project and use this as another
part of my application. Almost like a portfolio. Hopefully this will be enough
going forward.

------
billconan
whiteboard interviewers like to ask dynamic programming, I really don't
understand it. I have asked around and have never seen a single programmer
used dynamic programming at work once.

Other skills, such as multi-thread programming, debugging skills, get less
coverage. Many whiteboard coders who know how to solve dynamic programming on
a whiteboard, don't know how to use mutex and semaphore.

I think the whiteboard interview process is broken.

~~~
mesaframe
People do use dynamic programming. But, yeah debugging skills should be given
more coverage. A lot of people I've seen programming struggle or don't know
how to debug code.

~~~
billconan
sure, I know fast Fourier transform and reinforcement learning use dynamic
programming. but those don't represent most people's daily work. checking
[http://oj.leetcode.com/problems/](http://oj.leetcode.com/problems/) , you
will see that the problem selection is very biased and academic focused.

it's like recruiting warriors based on gymnastics skills. I think it makes
more sense to look for street fighters.

------
lsalvatore
Senior Developers are often running the interviews. If the Senior decides you
need to know a certain set of questions for the job, and you fail those
questions, then they feel you aren't ready for the job. That's not to say
these questions aren't often ridiculous, but we're also forgetting that many
Seniors (such as myself) _don 't_ ask these questions, asking simpler, more
practical questions, and probing for industry knowledge. It's my own finding
that around 50% or more of candidates can't write a single line of code _at
all_. So asking a question like "reduce this array" is sufficient enough to
judge that person's ability for the job that I need most of the time.

------
Townley
I'm a senior developer, and my wife is a corporate recruiter (at another
company). The frustration both parties experience with the hiring process is
palpable, and leads to some of our most eye-opening dinner table
conversations.

On the developer side, whiteboards feel like having to study for the SATs
again, which is doubly frustrating at the senior level because you know better
than before how little these questions correlate to qualification. Irrelevant,
spam-esque LinkedIn messages from recruiters confirm how sloppy the whole
process feels. And you spend the whole time thinking, there just _HAS_ to be a
better way.

On the recruiter side, they have to wade through a horrifyingly-unmanageable
torrent of unqualified resumes with the help of bad tools. When a great
candidate fails their test and can't move forward through the process, the
recruiter is almost as frustrated with the process as the applicant
(management, I'm told, remains unwavering in their commitment to "establishing
a baseline"). Even worse are the candidates who are filtered out from the
process by Applicant Tracking Systems because their resume lists "8+ years of
experience with a wide variety of NoSQL databases" and not "MongoDB"

I think both parties recognize the inefficiencies in the process. Where we've
landed is the following:

\- Developers need to learn to play the game. Understand how much of a black
hole "Easy Apply" buttons can be and not rely on them, optimize their resumes
for the role (including anticipation of boolean searches based on the job
posting), and make meaningful connections with their local tech communities so
recruiters know where to find them.

\- Recruiters need to advocate for flexibility and transparency in the
process. Workflows involving "shoving as many people into the funnel as
possible and use an ATS to sort through the noise" are untenable. Reconsider
systems that treat whiteboards or tests as requirements and not just data
points. Offer up relevant information earlier, with the hope that good
applicants will use that info, and their honesty, to help you figure out if
they're a good fit.

------
signa11
dupe:
[https://news.ycombinator.com/item?id=19915362](https://news.ycombinator.com/item?id=19915362)

------
suzzer99
I wrote up a similar experience a little less than a year ago:
[https://medium.com/@suzzer99/how-not-to-do-a-job-
search-1e99...](https://medium.com/@suzzer99/how-not-to-do-a-job-
search-1e99d96358c6)

I was rusty from traveling from 6 months and definitely wasn't prepared. But I
finally landed a job at a place that was a little more old-school in their
hiring process, and as soon as they could they converted me from contractor to
full time. So I guess it's working out for them (and me).

------
butterpeanut
I failed my amazon whiteboard interview, I couldn't write a flawless binary
search and as a result the guy said my entire CV must be a lie. There was a
bug in the code somewhere, couldn't figure it out without a compile and a
debug run. I've been coding for 38 years and I've built a world class product
but hey, whiteboards don't lie right? Personally I think it was the fact that
I was dealing with a lot at the time, personal stuff, plus I was banging my
head against the wall trying to figure out why my socket server wasn't scaling
properly to serve a large network, and I was nervous as heck.

If you want a developer who can rattle of a computer science algorithm, then
whiteboard interviews are the way to go. I would rather ask the developer how
she would create a password authentication scheme, and in doing so potential
avoid a data breach down the line when they fail to apply proper security
principles. Or I would challenge them on how they normally approach a problem,
so that I could see how teachable they are. People who are not teachable are
bad for business. I would also ask them to share a technique with me to see
how willing to share information they are because IT people who don't like to
share information are equally bad for business.

Lastly 'culture fit' is about finding more drinking buddies, if that's what
you're hiring manager is doing you should fire him asap.

------
spamizbad
We do live coding exercises as part of our hiring process, but we generally
shy away from Algorithm problems and instead ask them to solve problems like:

* Count the number of vowels in a string

* Transform a dictionary that's key'd on file name, with the value as the file owner into a new dictionary with owners as the keys and their value as a list of files.

* Deduplicate an array while preserving order in linear O(N) time

* Solve a simple problem using a closure (You can even google what a closure is)

We go out of our way to make sure the interview is conversational; we talk to
candidates like they're our colleagues. Too often, technical interviews seem
like interrogations and I absolutely hate that.

Candidates can code on their own laptops, ask us questions, and even google
stuff. The only rule is no googling for the problem directly, but if you need
to look up if some datatype has method X or forgot its signature it's not
counted against you.

The point of this is to just to do a basic smoke-test of the candidates
programming skills. They don't need to get them all correct, but they should
be able to solve at least 1 or 2. If they can't, then we politely end the
interview.

The rest of the interview is talking about coding, projects they've worked on,
challenging and interesting problems, wish lists, and for more senior people
architecture/planning, and a mock code review: we give them some bad code and
ask them to give feedback. The entire process takes about 3 hours.

------
maehwasu
When I was involved in hiring at a company, we found some amazing candidates
through code screens whom we never even would have interviewed otherwise. They
were terrible at resume writing, didn’t present themselves well, but could
code well and were very engaging once they got past initial discomfort.

I get the frustration of senior devs at going through this stuff, but the
alternative is a weird form of credentialism based on seniority.

------
HRJ7
Is there a market for a licensing body for this stuff? If you believe what you
read on Blind, the top companies all test the same material: leetcode, CTCI,
design system primer, Designing Data-Intensive Applications, etc.

Why can't I prove that I passed this screen once, then take a piece of paper
to each of my FANG interviews and skip the technical part. Then maybe retake
it every 5 years if I'm interviewing.

~~~
commandlinefan
I think we’re in the minority around here, but I’d like to see something like
a bar exam for professional developers, too. The immediate benefit is that I
don’t have to waste time proving that I know how to program a computer over
and over again and you don’t have to waste time checking, but it would also be
incredibly helpful to know that my coworkers have also passed it, so I know
what I can assume they already understand, and what I might need to explain.
Of course, I've always been a good test-taker, so maybe I'm biased.

~~~
kod
I've passed the bar exam.

It is not a good indicator of competence.

Most people pay a third party (after having paid for law school) to cram the
information into their head in a short period of time.

RHCE for example isn't great, but having passed both I think it's actually
better than the bar exam, since they at least hand you a live broken server.

------
lgleason
An open question. I'm currently writing a book on TDD for a publisher with a
good reputation. Out of curiosity, should I expect to still be run through the
interview ringer, or does that hold enough clout to demonstrate competency and
possibly the ability to be successful at my job. I'm curious to hear peoples
opinions on this.

~~~
kod
Expect to be run through the ringer.

I've been rejected by companies who were using open source code I wrote.

------
ausjke
I'm a senior developer myself.

I have seen too many very senior engineers in the company that is more of a
testing engineer nowadays, they do well in analyzing the issue at certain
level, document them etc, but they're unable to fix anything that is deep and
really complicated in a new code base that is huge(e.g. linux kernel, android
framework), each meeting I kept hearing "I know exactly where the problem
is..." but after many weeks there is still no fix, or the fix broke more
things that it fixed.

A few weeks later a junior guy(not fresh-out though) came in and dove in and
dug in then fixed it in a few days.

Senior developer means a lot only if you keep learning, keep coding, resharpen
all your skill daily, and stay current. Otherwise, the title is a big negative
to many companies, as the performance to price ration is totally unjustified.

------
geebee
I think this is an important essay. The advice at the end is good: these tests
are inevitable, and if you want to stay in the biz by applying for dev jobs at
companies, you must accept that you will retake you college CS exams over and
over for the rest of your life.

Alternatively you could look for a different path in life. Best to get out of
the coding jobs early in your career. Don’t look back.

That said, there _are_ some good reasons to do the coding path. At the high
end, they pay very very well, and there's no bar organization forcing you to
get a $200K 3 year degree. Salaries start higher, and working your way up in
other job ladders can be a grind and take quite a while to get up to SWE
salaries.

I’ll leave the paradox of industry claims of a shortage as an exercise for the
reader.

------
mizchief2
Then the other side is giving you a "small project" that takes the better part
of a day to implement. I just pass on those as well, and i'll do the short
challenges but I don't really take the company seriously after that.

I found the most effective is whiteboard sessions that actually somewhat
resemble reality as if I was the Product Owner and/or Architect with a
problem. Then go through the design process, what database system would you
use, would it have a a web service or be microservices or whatever, dig into
the database design etc. May ask more specific technical questions along the
way that are relevant to the design.

but the main thing is there is almost no actual coding done in the interview
process at all.

------
chad_strategic
I finally have gotten the courage to leave interviews when they throw code
test as me, end the call or just leave. Sometimes I believe that the person
doing the interview (Senior Dev) just likes to quiz people on technical
knowledge and then when the interviewee doesn't know, they like to tell them
and explain it to them. I get the feeling at times it gives the interviewer an
ego boost. I think I have been trained to explore every job opportunity, just
like I have been trained to eat all the food on my plate.

Best example, I have ever had I was interviewing for job about 6 years ago
with a start up. The guy that was interviewing me has a CS masters degree
strong tech stack background, probably lacked personality. He asked me what
polymorphous was and at the time I didn't know. I just told him that I didn't
know. Then he went on to explain it to me. Which I really didn't care about
learning about. It was clear I wasn't going to get the job and that was fine,
it didn't hurt my feelings. However, I learned to code because I have a
background in finance, stocks, and options, before I became a coder. I have
built stock algorithms that are profitable, regardless if they don't use all
the right classes or OOP. So when this gentleman told me that I wasn't good
enough for the job, he followed up with, I really like what you are doing with
stocks and your stock algorithm, maybe we could meet for coffee sometime and
you could tell me how your algorithm works, etc.

So I'm not good enough for your job, but but you want to learn about my
algorithm. (the company went out of business 1 year later.) Pound sand.

The problem that I face is I don't want to be a Senior Dev. I have enough side
projects and work life balance that I'm not trying to hit the CTO career mark,
unless maybe with a start up. Some one mentioned that that they where like a
studio musician. They aren't going be the rock star, but they do well with the
band, etc. That's probably me, I'm more interested in my side projects. But
professional enough to work at a day job.

Whiteboards, interviews, take homes I'm not seeing this get much better
anytime soon.

------
RcouF1uZ4gsC
>But don’t think that you can walk into another job based on market demand and
the number of years on your resume.

The issue is that there are a lot of programmers who have a lot of years and
who consider themselves senior who have very little programming ability. If
you have been with a “senior” developer who had no idea how to program but was
always telling other people what to do, because he was senior, you know the
danger of hiring one of these.

The other thing about this is preparation. It is no secret how these companies
are screening and interviewing. A truly senior developer who really wants the
job, with a few weeks of practice for an hour every night can considerably
improve their chances.

~~~
GVIrish
> A truly senior developer who really wants the job, with a few weeks of
> practice for an hour every night can considerably improve their chances.

Thing is, very good people always have a plethora of options. So a company
that tries to make a talented developer jump through somewhat silly hoops, is
often going to miss out on that person. Google for example will say, 'we're ok
with a lot of false positives' but they are also missing out on outright
brilliant people who can make an outsized impact.

The FAANG companies can get away with it to a degree, because their
compensation is so high. But there are a bunch of companies out there copying
these hiring processes when they can't pay anywhere near what those companies
pay, nor offer anything else compelling enough to make up for that.

So on one hand, yes, if you want to get paid the big bucks to work at one of
the FAANG companies, you play ball their way and jump through the hoops. But
that strategy is not going to work very well for the vast majority of other
companies.

~~~
lgleason
The sad part about this is that the filtering doesn't prevent getting sub
standard candidates through the door. For example, I've been rejected by the
Google interview process...but then shortly afterwords went to I/O expecting
to find loads of insanely smart people working at their sand boxes and office
hours that could run circles around my abilities and teach me things. There
are some that know their stuff, but a lot who's apparent knowledge etc. was
very under-whelming to the point of me knowing more than they did about the
subject. Over time I've come to realize that part of the hiring process at
these companies is political and that the filtering is still not preventing
bad candidates from making it inside the company.

------
thorwasdfasdf
one of the bad reasons for bad hiring practices I've seen is that hiring
managers throw engineers into interviewing situations a bit too unprepared,
often times with very little interview training/experience.

There needs to be a interview training/mentoring period where you have
engineers sit in on interviews to learn how and what questions to ask but
without actually having veto/accept power. this allows them to get experience
without screwing up the whole interview process.

Most inexperience engineer interviewers think you get the best candidates by
having the highest reject rate, and that's simply not true. Only interviewing
experience and training can improve this.

------
oblib
Knowing how to do something before I've done it hasn't ever stopped me from
doing it, or doing it right.

The important skill to learn is figuring out how to do it. Coding is no
different. For example, I've yet to use React to build an app, but I have
taken the time to learn the basics of how it works. If I needed to use it I
could, and would, and it wouldn't slow me down much, if at all.

I think what's important is discovering how adaptable one is. If one gets
whiny about using a specific toolset they're going to be a problem no matter
what you put them on that requires something different than their existing
skill set.

~~~
ronilan
> _”I’ve yet to use React to build an app, but I have taken the time to learn
> the basics of how it works. If I needed to use it I could, and would, and it
> wouldn 't slow me down much, if at all.”_

TripleByte has a very clear process which leads to a two-hour frontend
interview, an hour of which will be dedicated to building something with
React.

Give it a try:
[https://triplebyte.com/iv/NKCtNG2/it](https://triplebyte.com/iv/NKCtNG2/it)

You’ll surely learn something.

I did.

------
zerogvt
That's actually good as long as there are companies out there that get it
right [https://github.com/poteto/hiring-without-
whiteboards](https://github.com/poteto/hiring-without-whiteboards) Avoid the
type of corporations that sleepwalk into that type of interviewing out of
boredom or lack of knowing any better and head for the type of companies that
seem to know what they're looking for. In most cases you'll land in a place
you will actually like rather than in yet another freaking soul-less corp job
that it just pays the bills.

------
beat
I think a big part of the discussion that's being missed here is that a lot of
senior-level engineering jobs aren't about coding. They work at higher levels,
and are often communication-intensive.

I work in DevOps. If I'm interviewing someone, I'm going to ask "Explain the
difference between continuous integration, continuous delivery, and continuous
deployment". A junior person who can answer that well gets a big thumbs-up
from me. A senior who can't answer it will probably be rejected out of hand.

In neither case is implementing Towers of Hanoi on a whiteboard useful for the
job.

------
lgleason
On one hand you have companies bleating about how they can't find enough
developers, while pushing for more foreign work visas etc. in all of the
developed countries. On the other hand you have talented engineers being
turned down. I would argue that if there is indeed a shortage, you would not
being seeing this volume of talented engineers being turned down and they
would be in the drivers seat in the process.

The fact is that business is trying to turn us into commodities and it sounds
like right now they are winning...all that we can do it either adapt or change
careers sadly.

------
pragmatic
My boss had a very simple test he does.

1) create a very small web API 2) CLI the frontend spa of your choice Just toy
examples with some in memory data and filtering Time boxed to an hour.

No crazy puzzles. Just demonstrate you can do the basics. See how far you can
get, discuss as you go...

High failure rate. Even when I'd basically prep the candidates in the phone
screen.

I'd basically tell them what they had to do. Still didn't prepare.

I've been burned on the take home projects and super crazy timed algo puzzle
tests with the terrible instructions. I try to take the stress out of it as
much as I can.

------
sehugg
HN has discussed HackerRank and the like before:
[https://news.ycombinator.com/item?id=15182952](https://news.ycombinator.com/item?id=15182952)

------
la_barba
We need to take this to its logical conclusion. If the claim is that these
kinds of interviews don't work, then what should we be seeing out there? Are
companies that employ these techniques less successful, or less productive, or
less something-else? Because its not easy to tell someone they're doing it
wrong, when what they're doing is working for them and making money. Without
actually showing _how_ these kinds of interviews are detrimental to their
bottom line, its only going to fall on deaf ears.

------
Uptrenda
Hey, looks like some kind person thought to archive this a day ago:
[http://archive.is/5gJqc](http://archive.is/5gJqc)

Now I actually get to read it :)

------
beat
Data point: A friend of mine with 20+ years of experience in programming and
security (she's been a code-level security analyst for the past decade plus)
was asked in an interview the other day to implement a binary tree.

Why the fuck is someone asking a lead-level expert with over two decades of
experience a first-year CS question? Because that's the process? It's a total
failure. Asking senior people to do basic things like that is insulting. Don't
you have anything better to ask?

~~~
atemerev
Why don’t learn this thing for once? It is not difficult, and everybody will
benefit from doing that at least once, even the most senior and accoladed
engineers.

~~~
anarazel
Well, sure, inverting a binary tree isn't hard to learn. But there's countless
interview questions, not just that one. A lot are more tricky - and not
everyone is good at coming up with such solutions from first principles under
interview pressure.

While I'm reasonably good at these style of questions, I'd be very unsurprised
if there were a few that'd just catch me cold, even today. And I'm probably
working in a field that's a lot more day-to-day data structure heavy than most
(RDBMS internals).

------
nathanvanfleet
This is kind of a funny article. It starts off by describing the problem that
is created by these interviews, and then sort of waves its hand saying that
companies like them and they are here to say. It's probably more of a blog
post than a journalism article, but it would be more interesting if they
either got to the depths of why they are failing some people and considered
some alternatives that might work for both companies and people who are more
senior.

~~~
vonmoltke
> It's probably more of a blog post than a journalism article

What gave you the idea that it was anything but a blog post/personal opinion
piece?

------
noomerikal
This is one of the better articles I have read on the subject of hiring
technical talent with approaches to some of the inherent challenges.

[https://firstround.com/review/my-lessons-from-
interviewing-4...](https://firstround.com/review/my-lessons-from-
interviewing-400-engineers-over-three-startups/)

------
isuckatcoding
Mirror? Link seems down as well as the archive.

~~~
maxmcd
[http://archive.is/E5y1N](http://archive.is/E5y1N)

------
piccolbo
Try this experiment. When you get to ask questions in the interview, instead
of being nice and asking tings like "what's your data science stack" or "how
important is testing here" give them a whiteboard. Give your future boss a
whiteboard. But do it only if you don't care about getting an offer.

------
thorwasdfasdf
It was inevitable, that eventually we would end up with an oversupply of
Software engineers. I think we're now getting to that point. No one likes
getting rejected, but, when you have too many applicants and not enough jobs,
rejections are going to happen more frequently regardless of what interview
process you use.

------
degamer106
For those folks who work for companies that ask these puzzle questions during
the interviews, have you guys ever brought on a "bad" candidate? And, would
you say that your colleagues produce better work than the average engineer?

------
LordHumungous
> Prepare for the programming test gates now while you have the luxury of
> time.

Yep. If you're asking for hundreds of thousands of dollars a year in
compensation, then you'd better be prepared to jump through some hoops.

------
pyb
We regularly hear reports like this, that interviews are getting randomly
harder every year. It just goes to show that there is in fact no shortage of
senior developers... rather a glut, in fact.

------
dba7dba
I find it ironic that the upper echelons of startups reject: racism sexism any
other discriminations

But something else was brought in to replace them all. And it's called
culture-fitism and ageism.

------
notTyler
I am not a Senior. Not junior, not senior. I have been interviewing lately
after my company staffed me as the only remote member of a team based in
Argentina. (Live in the midwest USA, don't speak a lick of spanish).

I typically won't do programming challenges. I don't believe it's fair for the
applicant, because if it becomes the industry norm then applying for 10 jobs
means 10 separate programming challenges just for the opportunity to get an
onsite. But, recently, during a phone interview with a shipping logistics
company with a common first name in their name, I vibed with the lead I spoke
to and decided I would give their hackerrank a go.

There was an interpolate json feed into an object question. There was a semi-
complex array sorting / manipulation question. There was a javascript quirks
question. There was a sql question that I probably would have solved using
both code and sql rather than just sql. The solution I came up with was using
a temp table, that hackerrank permissions did not allow. The array question,
my (working) solution timed out because one of the tests used an array with
several million units in it. There was no indication of a certain time this
should run under. It took about five minutes after submitting to realize a way
that probably wouldn't have timed out, but at the time I was happy with my
solution given the whole test was timed and I had written six lines of code to
solve this problem.

The final question of the test, after all of these and a few I won't go into,
was to write an html form field that updated a list via javascript and had
alternating CSS colors. I was so frustrated that they would throw in something
so very menial and time consuming after the rest of the (timed!) test that I
didn't even attempt it. (to be clear, basic javascript knowledge had already
been demonstrated on the prior fizzbuzz).

I had really thought my answers would grant me an onsite, but it didn't. So
yeah, back to not doing stupid timed tests.

This was a month ago. The position is still open and I expect it to be for the
near future.

If anyone read this far, I have given some thought about my various interviews
after some interesting ones recently (another recent time at a .net shop I was
asked to demonstrate sorting a list so i did a toarray() then sort and they
were like no, do it manually).

I'm probably going to put together a blog about my interviews over the years
since I've had all sorts. I feel like as deep as retrospective as I can
remember over my decade of interviewing might give me some insight as how I
should be better.

------
jjluoma
Is this 'invert a binary tree' really nothing but a simple puzzle, solved by
swapping left and right children? There are probably better examples then this
case.

------
anotheryou
Yesterday I got a rejection explicitly because I was "too senior"—for a senior
position.

Guess I was too expensive, heh. The tone of the declination was actually super
kind.

------
theaccordance
I accept the fact that there will be a coding gate with the interview process,
but I dislike the lack of transparency regarding the process and grading
criteria

------
glenmccallumcan
dupe:
[https://news.ycombinator.com/item?id=19910545](https://news.ycombinator.com/item?id=19910545)

------
thorwasdfasdf
has anyone else here gotten the situation where you get a couple of job
offers, but get rejected by the company/position for whom you felt you were
the best fit for?

------
thorwasdfasdf
must be nice getting so much traffic that it brings your server down. Geez.

------
candybar
I've worked in different contexts at a lot of different jobs (full-time,
contract, etc) over the past few years and my overall assessment is that
whiteboard coding interviews do work. By "work" what I mean is that places
that do screen this way have more productive developers on average than
others.

My feeling now is that the fact that it is arbitrary and doesn't have that
much to do with real-life work may be a feature. You can dissect job
performance in a number of ways but I think most people would agree that these
four factors are important: general cognitive ability, conscientiousness,
domain knowledge and motivation. And of those, domain knowledge is already
relatively easy to discern from the resume and otherwise easy to screen for
and if your company is doing anything unique, not as important in the long
run. Almost any process would do a sufficiently good enough job of taking into
account relevant domain knowledge. Thus what makes one process better than
others has more to do with extracting other signals.

Whiteboard coding interviews, by being timed, somewhat arbitrary, yet
something that is widely practiced and easy to study for, implicitly selects
for cognitive ability, motivation and conscientiousness. It's hard enough that
you can't be dumb, it requires enough preparation that you have to be somewhat
motivated. And the process of preparing for interviews is sufficiently
repulsive and it's easy enough to fool yourself that you're prepared enough
when you really aren't, that studying to the point where you're prepared is a
test of conscientiousness. This creates a paradoxical situation where the test
itself isn't necessarily that relevant for the job, yet those who get through
the test are almost always very good.

In short, given that what you need to do to pass these interviews is fairly
widely publicized, the ability and willingness to do what it takes to pass
positively signal that you'd make a good employee. Even if you're great at
software development, if you're neither sufficiently motivated nor
conscientious enough to prepare yourself to pass these interviews, it's
unclear to me why you'd also go out of your way to excel at any given job -
every job requires you to do things you don't want to do, learn what you don't
care to learn and deal with a variety of suboptimal situations constructively.
So while I'm sympathetic to the point of view that this shouldn't be how
things are done, I think the willingness to say, "you know, this is how things
are, so let's deal with reality as it is instead of wishing it away and
ignoring some of the best job opportunities because I don't want to study" is
a positive characteristic. Every job has challenges like that - something that
in an ideal world is kind of stupid, is not at all fun to do and takes a lot
of effort, but doing it is strictly better than not doing it. You want to hire
people who are willing to do these things, not just complain about how stupid
it is.

------
throwaway082729
Interviewing is broken. Whiteboard tests with a bunch of algorithm and data
structures questions are meaningless and have no relevance to reality. If I
ran engineering, this is what I'd have candidates do.

1\. Initial video conf meeting to make sure he/she can communicate well. Talk
about the role. Have a technical discussion covering candidate's past
experiences to evaluate whether they really did what they claimed to have
done. Discuss a technical subject that the candidate is passionate about. If
satisfied, go to Step 2

2\. If the candidate is a strong referral, go to Step 3. Otherwise, do a
technical phone interview where the candidate solves a simple problem (more
complex than FizzBuzz but not the standard algo/DS/string manipulation
question)

3\. Onsite Interview. Session 1 - write a simple service (todo list, twitter
clone, etc) - 2 hours. 4\. Session 2 - Ask the candidate to do a code review
where the code in question has bugs and is poorly designed. 5\. Session 3 -
Candidate does a presentation of some technical topic to the team or at least
a few people in the team. 6\. Session 4 - Lunch 7\. Session 5 - System Design
exercise focusing on testing candidate's depth

Train interviewers to provide objective feedback. Calibrate scores for each
question ahead of time. Interviewers should be calibrated as well. Ideally,
same pool of interviewers for each question.

~~~
neogodless
Presumably you would only hire people for a very high level, very well
compensated role, and those individuals would plan on staying for a decade or
more?

I'm not saying your process wouldn't be effective, but it is asking for a very
big commitment for one interview for one position at one company. (And that
same commitment would have to come from your company and all the interviewers
involved!)

~~~
throwaway082729
Not sure why I understand why this is a big commitment. The first two steps
(manager call and a tech interview) are already happening. I'm changing the
onsite to exclude whiteboard programming and do real hands-on keyboard
programming plus code reviews and presentation which are all things that an
engineer is expected to do.

------
averros
The reason why most coders (who came to an interview) cannot code is simple: a
decent coder gets a job after a few tries. A pretender (in my experience, a
degree from IITs or some other degree mills from the same part of the world
strongly correlates with that) would go to hundreds of interviews only to be
rejected util he hits an equally incompetent interviewers. The pretenders are
way over-represented in the pool, and simple programming tasks do an admirable
job of filtering them out without much loss of time.

------
tempsolution
Sorry but interviews at the big tech companies have become so easy these days,
due to their insatiable demand for "talent", that I can't really hear these
whinings about difficult interviews anymore. The candidates we usually get are
just absolutely inadequate at coding and behavioral questions. This is not
something you can overlook. They just lack the very basic skills to express
themselves in code even when disregarding the correctness of their solutions.

"You can't invert a binary tree". Well doh! Maybe you should go through the
effort of at least looking at some of the basic algorithmic concepts again,
you know just to show that you even remotely care to be hired by the company.
They have a much harder job than you do. They get hundred thousands of
applicants per month and need to filter them out. You are one person applying
at maybe 2-3 companies a month or week.

To me, this sounds like someone who thinks too highly of himself and "he
doesn't need to prove himself to a FANNG company". Well think again, writing
Homebrew doesn't mean anything. Pretty much anyone at a FANNG company could do
that, but not everyone wants to do it. If you want to work at FANNG instead
Homebrew, you need to prove yourself to them, not vice versa...

Is it really too much to ask to spend a few days solving some programming
puzzles on a whiteboard? If few days are not enough, then maybe you really
aren't as smart as you think?

I think people these days really tend to always put the blame on others. What
about starting to look at yourself more critically, think about if you are
really a "senior" engineer? I work in tech for years now at FANNG companies
and "senior engineers" are in a different league. I think I will get there in
one or two years but it has been a long ride. These people are paradigms of
programming that can always give you useful insights and advise. They excel at
a wide range of soft skills and management too.

If you see what most companies (outside of FANNG) consider "senior" you will
know why (1) senior engineer means absolutely nothing and (2) why FANNG is not
interested whatsoever if you were a senior engineer somewhere else...

~~~
PopeDotNinja
> "You can't invert a binary tree". Well doh! Maybe you should go through the
> effort of at least looking at some of the basic algorithmic concepts again,
> you know just to show that you even remotely care to be hired by the
> company.

Who cares if you can invert a binary tree? Who cares if you can write a binary
tree? I know what I've needed to know really well, because when it hit me in
the face, I learned it. If I need a self-balancing whatever, chances are I'm
gonna grab one off the shelf and call SomeBTree.new(args).

The problem with "maybe you should have just learned those simple concepts" is
that there are an infinite number of clever questions interviewers try to ask,
and close to none of those questions matter. The management that wants to have
confidence that applicants can verse a binary tree is also the management that
would not let you budget the time to create a binary tree if you actually
needed one from scratch... "you shouldn't have to worry about that, just ship
it and move on".

Most of my job as a dev seems to be cleaning up the messes of someone that
cleverly coded everyone else into a slow, unmaintainable mess. How
interviewing for that?!

