
Things I Learned from a Job Hunt for a Senior Engineering Role - fuzzygroup
http://fuzzyblog.io/blog/jobhound/2018/04/24/ten-things-i-learned-from-a-job-hunt-for-a-senior-engineering-role.html
======
jandrewrogers
To take a more nuanced view, I think there is an important distinction,
frequently lost, between "can't code" \-- which is all too common in practice
-- and "can't easily code a stream-of-consciousness solution to a synthetic
problem unrelated to anything I've ever built". Or its close cousin "can't
easily code a toy solution to your toy problem since I've only worked on
massively scalable versions of the same problem". Something I keep in mind
when interviewing candidates is that there is that good understanding of the
general design of algorithms does not imply that they should be able to throw
together an _implementation_ of an arbitrary algorithm with minimal effort
unless they've needed to do it in the recent past. Expecting people to
spending many days practicing the _implementation_ of arbitrary and often
irrelevant algorithms is unreasonably in my opinion. I am more interested in
figuring out if they _could_ given adequate time.

A valuable practice, which surprisingly few tech companies do, is to ask
candidates about diverse and orthogonal problem domains, or alternatively,
allow the candidate to pick from a diverse set of problem domains. In the
former case, you often find that candidates have difficulty writing even
simple solutions for some problems but on others they instantly and fluidly
can code up a good solution. Because they've had to do it in recent memory and
still have the "muscle memory" from doing it previously. You often see bipolar
results across the problem set this way.

For senior engineers with deep domain expertise in an area, there is an
additional trap in that they use more sophisticated and often very different
algorithms in their day to day lives than are applicable to the toy problem
domains. Graph algorithms are a good example of this, and they are popular in
interviews. The representations most engineers know (e.g. adjacency list or
matrix) don't scale but the extremely high scale algorithms operate on a
different set of principles that aren't trivial to code and aren't relevant to
non-parallel cases; coding up an adjacency list graph traversal algorithm is
going to be very unnatural to a software engineer used to doing the same on
trillions of edges in real-time. It would be crazy not to hire an engineer on
this basis but I've seen it happen, ironically because their expertise caused
them to show poorly on the coding exercise.

Interviewing for technical skills is intrinsically difficult but I think that
as an industry we are much worse at it than we could be. For all the claims of
companies that they only hire the "top 10%" or whatever of engineers, the
interview process is often optimized to the benefit of the median engineer.

~~~
thegayngler
Most engineers would not hire themselves. That has been apparent to me for
awhile now. I’m not sure why they expect people to be to be better than they
were when they were hired. I don’t expect engineers to be better than me. I
have but one qualification. Can they do the job? Are they strong enough that I
can guide them into the position I need them at if it is required.

So much focus has been put on 10x this and high performing that. Companies
waste lots of engineering talent and company money looking for 10x when 10x is
mostly situational in nature. Set the scene. In one scene the engineers are
not producing. Change the scene and now they are 10x.

Instead of looking for 10x, that time would be better spent making incoming
and current engineers better at their jobs and creating 10x situations.

~~~
jasode
_> I don’t expect engineers to be better than me._

I respect your opinion but I find this strategy very strange. (Or maybe I
don't exactly understand what you're saying.)

In my view, it would be a dream scenario if the next 10 programmers I hire
were _all superior to me_. If I was the _worst_ programmer on the team, that
would be an ideal outcome. Yes, I've been programming for 30+ years but I'm
also self-aware of my limitations. This gives me the ability to recognize
better programmers and learn from them. If I'm not hiring interns, I do expect
(or at least hope) that they are better than me.

Am I competent enough to write a "do/while" loop and knock out FizzBuzz in 5
minutes?!? Sure, but that doesn't mean there aren't better programmers than
me. I would consider it a great business skill if I'm able to consistently
attract superior programmers -- either to work _with_ me or _for_ me.

Larry Page attracted programmers better than him (e.g. Jeff Dean). Yes, Larry
earned a masters degree in computer science but his java programming (the
rudimentary 1996 crawler) wasn't considered very good. His employees rewrote
the whole thing in C++ and made it scale for billions of pages. Bill Gates
hired superior programmers. Mark Zuckerberg hired superior programmers. Etc.
etc.

~~~
reinhardt
You actually agree with each other. You're saying "it would be a dream
scenario if the next 10 programmers I hire were all superior to me"; it's an
ideal outcome, even if unlikely. The parent's "I don’t expect engineers to be
better than me" merely points out the unlikeliness, you point out the
desirability.

~~~
ljw1001
When I was at one company (later acquired by Google), one of the developers
created a model to show just how unlikely it was that every new hire would
continue to raise the average level of competence for the team as a whole (as
our hiring traditions espoused). After years of hiring very good programmers,
it just wasn't going to be possible to hire many more who could pass that
test.

~~~
andai
Could you elaborate on the hiring process? Was it calibrated to hire people
more competent than X% of the current engineers?

------
falcolas
I have a theory of why most of these changes in the job hunt came about:
people became afraid of firing. I further theorize that this is an indirect
consequence of primarily technical folks filling management roles.

How does a fear of firing impact hiring procedures? If you are afraid of
firing, you're afraid that you won't be able to get rid of a toxic individual;
that a single individual will act as a poison to the morale of your entire
workforce. Thus, you want to make damned sure you don't make a bad hire in the
first place - even when it means you leave a position open for a really long
time.

This fear of firing has gotten so bad that FAANG-alike companies directly
espouse how bad the impact of a bad hire is, how they would rather give up on
99 good candidates than hire one bad candidate.

But that's bullshit.

That's letting the fear of interpersonal interactions drive business
decisions. The impact a bad hire can have on a work force is pretty minimal
when caught and addressed quickly; it can even provide an overall boost to
morale to know that the company is willing to address real problems in an
adult way. Even a perfect initial hire can turn toxic after a few years: what
will you do then, if not fire them?

Do you have 10 positions and 10 potential candidates? Hire all 10 folks, and
fire the one bad person; your company will be better off for the decision.
Much better off than it would be if you instead overwork your existing team
because you haven't found your unicorn hires yet.

~~~
hoorayimhelping
I agree that it's related to firing, but I don't think it's fear of
interpersonal drama.

The simple explanation is that it's really expensive to fire someone without
cause. It takes months because the company has to produce a paper trail
proving they fired the person for a valid reason to protect themselves from
litigation. That's months of paying an individual who may be incompetent or
toxic, months of paying people who put together the paper trail, all the
morale damage the individual causes, the damage that might arise from firing
someone, even if it's someone no one really liked.

All of those things are costly, probably much more costly than not hiring the
right candidate. At least so the reasoning goes.

~~~
ojbyrne
The simple explanation is that many employers believe that. In fact I don't
think it's that hard.

1\. As another commenter pointed out, most jobs are in "at-will" states.

2\. Many companies require arbitration instead of litigation to settle any
disputes as a requirement of employment.

3\. It's just as expensive for the fired employee, probably more so, since if
you litigate, you're unlikely to ever work again.

~~~
uiri
Every state in the US is an "at-will" state. That is a US based vs non-US
based employment distinction.

------
pg_bot
Number 2: No One Believes Anyone Can Actually Code

It's surprising to see the number of people who interview for lead technical
roles that cannot code, or whose work is exceptionally sloppy. Incompetence is
more commonplace than the author believes, even at the highest level.

~~~
haskellandchill
I feel like this is a myth, what do you estimate the figure is? I think under
10%, maybe under 5%. I have significant experience interviewing senior,
junior, and mid-range candidates. 99% of my candidates can code, as in iterate
over collections, write case statements, and call functions. I've only had one
junior candidate who couldn't code at all. Sloppiness is rampant, but sloppy
code that gets things done is what my company wants (not me personally).

~~~
spamizbad
We set our in-house recruiter up with a coderpad question that screens
candidates with a simple question:

"Write a function that counts the number of vowels in a string"

Candidates are allowed to run it multiple times and just have to produce a
correct result within 10 minutes. It's not a trick question -- the test case
in place makes sure you pay attention to case.

Success rate for mid to senior devs? Only 60%.

~~~
1812Overture
I applied for an analytics position that unexpectedly had me take a Python
coding test like this (I know a bit of PHP and Java but no Python) and I was
able to google everything I needed to pass the test in the time limit.
Apparently I got one of the higher scores too. Got the job. It has not
required me to write a single line of Python, lol.

~~~
rajacombinator
Googling stuff to copy is one of the most important skills for programmers. I
was appalled when a middle aged senior programmer at my first internship told
me this, thinking he was lazy and unethical... (people are paying you after
all!)... how naive I was!

------
geebee
Thank you for writing this post. It was informative. A few comments from a
fellow software developer who is approaching 50...

I don't think the coding test isn't there because people think you're lying,
it's there because we have no industry wide, respected entrance exam.
Actuarial interviews don't (to my knowledge) contain a whiteboard vector
calculus exam, but this isn't because people just sort of believe actuaries,
it's because you have to pass a rigorous exam on these topics to become an
actuary. I sometimes wish we had something like this in our field (not
necessarily a legal requirement, just something that is widely recognized as
legit). I'd be happy to put the time in and really study for a proper exam,
but I'm not as interested in doing this over and over for companies that may
administer and conduct these exams frivolously and in secret.

Also - I actually do agree that it's bad if someone can't write fizz buzz, but
every interview exam I've taken has been vastly more difficult than fizz buzz.
It's "find all subsets of a set of integers that is divisible by the sum of a
different subset of integers". At a whiteboard, in 45 minutes. These aren't
impossible problems, but they're much tougher than fizzbuzz.

I am saddened, angry, and relieved to hear of your problems with homework. The
response you got back makes me realize that the two times I've done a homework
assignment were probably pretty typical. I won't do this anymore, and I do
accept that this will limit my career options. It does anger me, though, when
the companies who do this complain about a shortage of engineers.

True story: I did an on line exam and take home homework assignment, waited
over a month (crickets chirping) to hear back, pinged the recruiter politely
now and then, and finally got a one liner "we've decided not to continue at
this time.' A few weeks later, an article with came out with a picture of the
CEO of this company standing next to President Obama, who nodded gravely as
the CEO talked about the desperate shortage of software developers.

~~~
s2g
> it's there because we have no industry wide, respected entrance exam

So you think the person with 30 years experience might be, whats the word...
oh right. Lying. You think they are lying.

Quit trying to dress it up. Coding tests are exactly you saying you don't
believe the experience written on the resume.

~~~
zip1234
I use a coding test not only to see if someone can write basic code, but also
to assess general intelligence and see/hear their problem solving process. A
resume definitely doesn't tell you all you need to know and experience does
not necessarily mean effectiveness.

~~~
geebee
I actually do understand why people administer these tests in our field.
There's so little to guide you otherwise.

The problem is that it's kind of awful, and I personally really do believe
that it's driving people away from the field.

Here's my take (I've posted this on HN a few times). Many people find in
person, at the whiteboard exams quite stressful. This is fairly common, many
people describe exams to be among the more stressful events in their lives.

Over time, I believe that institutions that conduct exams evolved a bill or
rights between institution and applicant. Exams are used, but they are
administered consistently and fairly, the topic and subject matter will not be
a huge surprise (questions are kept secret of course, but their nature should
be predictable). People who pass or fail will receive an answer, and often get
a score and feedback to know how they did. The people who grade the exams are
provided training to ensure they evaluate people fairly, consistently, and
without bias, and are expert in their field.

Now, I know that universities, medical boards, bar exam reviewers, don't
always live up to this, but it is the intended goal. I believe that our field,
software, subjects people to exams repeatedly, but without any of the bill or
rights I descried above.

For example, how do you grade? Are you qualified to assess general
intelligence? Can you understand that someone might not be eager to submit to
your general assessment of their intelligence?

Now, if you want to say nobody is entitled to a job, I certainly agree. But
the industry seems to think it's entitled to workers, and they just seem
utterly blind to how off putting their practices are. And in an industry with
concerns about gender, racial, and age discrimination, double secret
assessments of people's general intelligence by interviewers of unknown
qualifications is about the worst thing you can do.

~~~
orangecat
_This is fairly common, many people describe exams to be among the more
stressful events in their lives._

Interviews are always exams, whether it's writing code on a whiteboard or
trying to figure out what the interviewer wants to hear about where you see
yourself in 5 years.

~~~
geebee
In a way, yes. But by blurring this distinction, you make it impossible to
distinguish between an hour at the whiteboard solving a data structures
problem, and an hour answering questions like "tell me about a time you
overcame a challenge and what you learned".

Because people outside our field experience interviews in the second way more
often, I think they don't fully understand what goes on in google style
interviews. This is why I would call what we go through "Exam-style
interviews", drawing a distinction between the two - even though I agree with
you that they have elements in common.

------
larrik
I've been involved in hiring senior engineers for a while now, and here's a
few counterpoints:

1) Ruby is hard to get a job in, so you are off to a rough start.

2) A lot of people with lots of experience actually can't code for crap. Do
you know how many python developers I see that don't know the difference
between a tuple and list? Like, how could you be a real dev if you never even
wondered why sometimes you use [] and sometimes you use ()?

3) These tests and interviews aren't intended for you to get some certain
score. Usually we make them way hard to find out what you do to handle that.

4) That said, you should know how to write code that isn't super slow and with
a data model that isn't insane. You should also know how to articulate that,
since as a Senior dev, you WILL be mentoring junior devs, and communication is
not optional.

5) Every company's process is different because every company is different.
Heck, my process is often different _per applicant_.

~~~
lifeisstillgood
I think the main point from a candidate perspective is that long, unusual or
difficult interview processes are fine as long as we have already decided we
really want to work for you (that is you are Trello or SpaceX or some amazing
startup we love)

otherwise, just as you are faced with picking a rose from a faceless mass of
candidates so are we faced with picking a decent place to work from a faceless
mass of mission statements and "100%code coverage" blog posts (if we can find
any)

And 2) yes I can believe it - that's what fizzbuzz and its ilk are for. The
number of companies offering hackerrank/codility tests and justifying it as we
only hire the very best has left the lake woebegone test way behind.

There has to be some middle ground - where someone can pass a basic capability
test to weed out the crap without demanding several hours of coding. I mean I
spent two evenings recently polishing up a "Oyster card system for TFL" as a
hurdle for a government department I have been angling to get in for a year. A
no-name corporations wanting CRUD development can take a running jump if it
thinks my evenings come cheap.

(amazingly at the turn of the century I used to use "has listed Python on CV"
as a marker of "worth an interview" \- it was rare enough and indicated an
interest outside of corporate mainstream. Maybe Erlang today??)

Edit:

So my compromise suggestion is for companies to say "We have an OSS project
(or even recommend one of the bigger ones). Take any of these 5 bugs and
supply a pull-request"

At least then the evenings work is not totally wasted and you get to see an
important skill - how fast can they come up to speed on an unfamiliar
codebase?

~~~
larrik
We actually only do 2 interviews total, and for some roles a Hackerrank quiz.

The only times we use coding tests, we use Hackerrank to administer them. That
way you have a distinct time limit (we give an hour, which is honestly way too
long) so you don't spend all weekend one something that doesn't matter.

I definitely agree about the difficulty of picking a place to work. We reserve
half of our final interview (and part of our initial interview) to be a Q&A
for the candidate to interview _us_.

~~~
lifeisstillgood
I think that Hackerrank etc are optimising for the wrong question. 98% of the
time as a hiring manager I am not looking for a AAA coder - I am looking for
an A level coder who fits the team and has other soft skills that matter.

At a certain point "can code" stops being "can write perfromant algorithms"
and starts being "can work without direction, can be placed in front of users
without fear, can defend their decisions, is not an asshat."

Ten minutes on a shared screen and we can find out if you pass fizzbuzz, can
make a rational stab at an algorithm question. After that it's mostly cultural
fit.

You cannot automate a test for "is not an asshat" so we get more and more
people proving they can get 99% on programming tests when programming tests
are 5% of the job.

------
matt_s
> No one believes that anyone can actually code.

Is it just our industry where you have to prove you aren't a complete impostor
every time? Basically we treat every applicant like they are Frank Abagnale
[0].

A senior role should be focused on more overall system and performance aspects
of the software, using good practices.

What does writing out a solution for fizzbuzz (or equivalent) prove during an
interview? If they do it easily do you suspect they memorized it (our base
assumption seems to be they are an impostor right)? If they fail, do they fail
the interview?

In the real world if you had a database call in some recursive loop that would
be bad for performance. The number of times I jump to using recursion in a
solution is near zero.

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

~~~
lostcolony
We do a fizzbuzz-like question, but one we created ourselves so it's not
easily google-able or memorizable.

Anyone with basic coding chops should be able to solve it; it would be
equivalent to a CS101 quiz.

It is still shocking how many people fail it. Yes, we have to test for it. My
wife is in digital marketing, her -boss-, who insists on being involved in
every decision, and will override her knowledgeable subordinates based on her
own feelings, knows nothing about digital marketing (and is the reason my wife
is looking to change jobs), but nevertheless managed to impress people above
her (who also know nothing about digital marketing, but to be fair, don't have
marketing related titles or roles) with her resume. Imposters in jobs are
super common; it's just that in development we have easy ways to check for
basic understanding. Unfortunately we try to scale those up to look for expert
level understanding, and that fails (because we're really bad at testing for
expert level understanding in areas we actually care about. That 'implement a
red black tree' is probably appropriate if your company builds a data
structure library as part of their core product, and probably inappropriate
for almost anything else).

~~~
taurath
I wonder what would happen if you asked those that failed the fizzbuzz
question what they DID know and wanted to demonstrate. The idea that there are
flat out imposters who cannot code that have held coding jobs for more than a
few months is ridiculous. Right out of college with no experience, I
understand.

Have you considered that:

1\. People have imposter syndrome, all the time. They're stressed out about
being able to code, when running up against code interviews having nothing to
do with the actual job they're doing. 2\. People have anxiety, and they know
how tough code interviews can be. They crammed and crammed and crammed, and 10
years of coding is now all this big amorphous blob in their heads. They're
ready for some big systems questions. 3\. People have bad days. The
environment might suck. Their dog just died. You're a very adversarial
interviewer, and they only work well and creatively when someone isn't going
to come in and bully them about the response (or maybe they just imagine this)

Of course, you have no way of knowing this as an interviewer. But FFS, we need
a way to inject some fucking empathy into this process. I'd say 99% of the
time people aren't in interviews demonstrating what they know or can do,
they're being asked to demonstrate what somebody else thinks INDICATES they
have things that they know or can do.

I know the response to this is going to be, well yeah, but its Fizzbuzz! And
I'd like to ask those people if there's ever been a point in your life that
you wouldn't be able to write Fizzbuzz. To dramatize for effect, if someone
came up to you and said they have access to your bank account, and for them to
not take every bit of money you've made over the past year, including the
money for your daughter's braces or something important, and in order to get
it back you needed to make as concise and clean as possible an implementation
of his variation on Fizzbuzz, you will not be thinking just of Fizzbuzz. Your
brain is going to be churning at 1000 miles a minute, and you'll be trying to
pull out every trick you know (out of hundreds) to get it as concise as
possible, while thinking to yourself this is my future on the line.

Thats how I feel in interviews at least. I've always passed Fizzbuzz tests,
but I've crashed and burned in interviews due to any of the above popping up
on interview day. If we all could have a bit more humanity and understanding
hiring would go a lot better.

~~~
lostcolony
"I've always passed Fizzbuzz tests"

You just negated your entire point there.

Yeah, you can have a bad day. I get it. We all fail interviews; I certainly
have. Some I feel we really weren't a match (they were looking for a kind of
developer that I wasn't, and don't want, to be), others I felt were unfair
(for instance, interviewing with Microsoft years back, I had a C/C++
interviewer asking me questions that I had been told I was allowed to write in
Java, and then disbelieving me when I told him (String).length is constant
time so it didn't affect the Big O complexity that I had 'for (int
i=0;i<(String).length;i++)', and clearly mentally checking out at that point).
Obviously I don't feel any were because I wasn't, legitimately, good enough,
but I also recognize I am very biased. But the thing is I also am in a place
where I don't need an interview to justify my confidence at this point. I know
I can deliver value. But I also know I will never convince the Googles of the
world that I can, because I am neither a researcher of note, nor am I going to
jump through the hoops of prepping for weeks on end for an interview; I have a
wife, hobbies, and other, better ways to spend my time (even typing comments
on HN! :P)

We first give people a take home. It's at their own convenience, we tell them
it will be an hour and a half, coding, simple questions, to do it at a time
they're comfortable. We don't stay on the phone, we tell them to use whatever
resources they want (except, obviously, please don't try and google for the
answers directly, or get help from others; it's simple enough that those who
have tried to cheat have ended up with it being hilariously obvious, like
leaving source comments that said it was by someone else, or variables for
'cat' when we never asked for anything related to cats, or being caught out
during the whiteboard).

The interview is mostly a conversation. It starts with conversation. We talk
about the position, the company. We ask about what the candidate is looking
for, their resume, that sort of thing. Only after thirty minutes or so do we
get to anything technical. We ask a few questions, and they're intended to be
placeholders for conversation; plenty of right answers, we mostly want to see
that the person is knowledgeable enough to discuss things. Even when we get to
questions that have a right answer, it's mostly to gauge knowledge, and for
the more complicated, even if a person gets it wrong, we'll tell them what the
right answer is, and then ask them for a rational as to why. If they can
figure out the rational, that's just as good as having known in the first
place. Then we have a whiteboard question. It, too, is not hard. We tell the
candidate "If you think there's a library function that will help, but you
just don't remember it, you'd need to Google it, that sort of thing, talk it
out with us, we'll give it to you". We try to help suggest things to get
candidates unstuck. Etc.

Really, it's -not- a particularly antagonistic process. We really, really do
want people to succeed (because, frankly, we want the position filled so we
can stop interviewing and go back to work). So, yeah, if the interviewer
doesn't manage the trivial coding tasks...we're going to pass. We -aren't-
saying "this person is a bad developer", we -are- saying "this person could
not demonstrate that they passed the bar of our interview process".

But there have also been some who have flat out said, even on the take home "I
can't do this". Or those who have admitted when faced with the whiteboard
question that they don't know how; that the take home had been done by someone
else. Etc. Given those situations, yeah, our candidates are being given a take
home, and a whiteboard.

------
brandall10
Been coding professionally since '99 - C/C++/C# until 2012, then
Rails/React/Angular over the past 6 years. I guesstimate I've been on some 50
interviews.

If anything I feel that things have gotten better, although this may be a
difference between my former enterprise Windows-stack life vs. open source
tech life. The main differences I see are:

\- Take homes are more prevalent... but I recall only one which has taken more
than a half day, and that was fair as I was relatively new to Rails at the
time. I actually like doing these for jobs I'm interested in as they give me
an opportunity to flex my skills.

\- There's about a 50% chance that you get a CTCI type interview vs. a more
pragmatic, what-you-experience-on-the-job type domain modeling, write out in
code in Rails (or whatever framework being used) type of pairing. When I'm on
the hiring side I focus on the latter and feel it's quite effective. When I
was starting out you almost always got the CTCI type.

I typically red-flag potential employers who don't sufficiently validate the
skillset of potential hires. I've worked with plenty of people who were
terrible, it's one of the reasons I transitioned to Rails.

~~~
nerraga
Can you elaborate you that last statement? Are Rails developers less terrible
than the C/C#/C++ people with whom you’ve worked?

If so, what are your thoughts on why that may be?

~~~
brandall10
From my experience Rails devs tend to care more about the quality of their
work/impact of their changes on teammates, read dev blogs/books, go to
meetups, care about testing/documentation, ways to source good candidates and
working with good people.

Basically they just care more about doing good work. I must underscore though
that my impressions are tempered by the fact that I primarily worked in
enterprisey Windows-stack jobs, but that's also more typical - you're not
going to find many modern startups going w/ .NET or Java. The tools themselves
aren't really the problem, it's the implied culture.

Why is this? Probably because of the goals of each. .NET and Java were an
outpouring of efforts from the 90s to harness issues of scale on enterprise
systems. It's a pre vs. post information age phenomena, open source folks are
going to be more of a hobbyist mindset.

------
rambossa
Side note/rant: I hate the Cracking the Coding Interview style... studying for
these type of interviews is annoying. Trying to find a good video on youtube,
where they aren't just naively coding up the bruteForce->optimal possible
solutions, especially is irritating. It is literally a landscape of college
kids with thousands of viewers who treat these interviews like the SAT. Even
the author of the book produces videos with very little insight or meaningful
content.

"Find all the subsets in a set that add up to sum" \-- "Okay for this we will
use the sliding window technique and here is how it is done" \-- WTF is this.
I get that they want to see problem-solving skills, but this is on a different
level requiring the interviewee to have studied and knowledge of the
technique, otherwise we are basically trying to develop efficient algorithms
from scratch and in little time. --This makes sense for college interviewees
who have only studied the past 4 years, but for a professional with experience
why is this adequate??

~~~
pm90
They are not just testing your analytical skills but also, I believe, your
ability to self-study for something, even as "annoying" as algorithmic coding
problems.

I kinda agree with you that it doesn't make sense much of the time if you have
to specifically prepare for the coding interview; stuff you may never use in
your job. But its not a lot of stuff: I bit the bullet and spent some time
solving those questions and now can make past mostly any screen.

Its really not that hard, especially if you have a CS degree. Probably would
take 1 week of dedicated effort to get better at it.

~~~
hfdgiutdryg
How is proving self study ability relevant to a job? Doesn't my resume of
wildly varying projects and my ability to competently talk about them prove
that?

It sounds to me like a way to weed out pesky applicants who have families or
who are simply older.

~~~
pm90
> How is proving self study ability relevant to a job? Doesn't my resume of
> wildly varying projects and my ability to competently talk about them prove
> that?

People usually trust their own assessment of a candidate much more than that
of others. While your projects might help generate interest in you and get you
an interview, the actual interview process is meant to be an assessment by the
Company conducting the interview. So you shouldn't automatically assume you
have the jobs simply based on your past projects alone. I'm not saying I
necessarily agree with how this works; I am simply pointing out _why_ it works
that way.

> It sounds to me like a way to weed out pesky applicants who have families or
> who are simply older.

Perhaps. It seems unlikely since many of the senior developers/hiring managers
at most mature companies are older and have families.

~~~
hfdgiutdryg
_While your projects might help generate interest in you and get you an
interview, the actual interview process is meant to be an assessment by the
Company conducting the interview. So you shouldn 't automatically assume you
have the jobs simply based on your past projects alone._

That's insane. If you brought me in because you liked what's on my resume,
your number one priority should be determining if I really did what I said I
did. Your priority shouldn't be arbitrary, unrelated questions or coding
challenges pulled off some website.

I'm not aware of any other industry that behaves like this.

~~~
pm90
> That's insane. If you brought me in because you liked what's on my resume,
> your number one priority should be determining if I really did what I said I
> did. Your priority shouldn't be arbitrary, unrelated questions or coding
> challenges pulled off some website.

There generally is a component where you're asked about your past projects in
detail. Its just not the only component.

------
znpy
This writing seems to confirm something I've been suspecting for a while: the
STEM shortage is a myth.

Think about it: how can companies be this picky if there really is a STEM
shortage?

On a sidenote: I recently understood why meetups, events and networking is
important: to interact as little as possible with HR.

I've recently a particularly bad experience where the HR person called me very
early in the morning (without asking if it's a good time to talk) and then
proceed with a third-degree interrogatory with all kind of questions, even
reaching the point to interrupt me while I was articulating/motivating my
answer in order to make another question.

That was so rude I got very angry after that call. That is not the way to
handle a phone interview, that is not the way to handle a conversation of any
kind.

~~~
ng12
> how can companies be this picky if there really is a STEM shortage?

Honestly I think it's because mediocre engineers are more trouble than they're
worth. We're collectively not good enough at building software to adopt a
"warm body" approach.

------
bulatb
A: The talent shortage is just awful. _Nobody_ can code.

B: How do you know?

A: They can't pass our test.

B: How do you know it works?

A: Because if they could code, they'd pass. Sometimes they pass, and even some
of _those_ can't code.

B: So nobody can pass your test.

A: That's right.

B: And even if they do, it doesn't mean they're good.

A: Yep.

B: It sounds like you've got neither recall nor precision. Don't you think the
test could be wrong?

A: Nope! Everyone just sucks.

~~~
debt
"A: Nope! Everyone just sucks."

I do think this attitude genuinely limits many startups. Software engineers
will always be the first to take up hobbies like fixing old motorcycles or
building a house from scratch, yet they view mediocre engineers as things that
can't be fixed up in the same way.

A mediocre engineer is actually a really good bargain. Obviously a great
engineer who doesn't know it is ideal but I'd toss them in with the mediocre
engineers for that reason.

~~~
amyjess
Sounds like a good opportunity for mid-size companies to play Moneyball.

------
bcg1
Recently referred a friend for an opening at the company where I work. He
didn't even get an interview because someone from HR has decided that all
developers should have a four year degree (he only has an associates degree
despite 15+ years experience). Maybe this would be fine for entry level
positions, but it is straight up age discrimination for senior level ones
(since there are still talented people in the workforce who went to school
when CS programs were much less common).

One theory I have is that HR depts are pushing back against the upward trend
of developer salaries; if they create an onerous process that tries to make
candidates feel inadequate, it might make it more likely that they can land a
low ball offer with whoever is desperate enough to stick it out. Also, if the
HR department itself is incompetent and not capable of attracting talent, they
can always point to their tests etc to "prove" that there are just no
qualified candidates in the workforce.

Also, what is with all the coding tests etc? That stuff is obviously useless.
Why don't hiring managers just ask candidates to read some code that is
similar to what they will be working on, and observe how they approach
stepping through it and how quick they can understand it? That is far more
similar to what real work looks like most of the time.

------
laichzeit0
Don't people get job offers anymore from someone they used to know that moved
to another company and then like "hey I know this really great guy who works
at XYZ, we should definitely get him here"? That is literally how every job
I've moved to happened, except for the very first one right after being a
student. That's the only job I ever remember having to "interview" for. The
rest were just through established social connections by working in the tech
industry. Surely if you have skills and work hard and other people know about
this, they would be knocking at your door?

It's just weird to me that people go job hunting by "cold-calling" some random
job advertisement where they don't know the company or anyone that works
there. If I were hiring people, I'd go for people I personally have worked
with, or been recommended by someone that I work with, waaaaay before hiring
some random person that showed up at an interview.

~~~
eastbayjake
You're way ahead of the game, OP. We talk a big talk in our industry about
hackers and meritocracy, but this is still a relationships business -- like
every other business. At most companies if you're cold-applying to a position
on a job board, you're already behind your competition.

I'd like to propose an alternative job hunt:

(1) Start thinking about your next move before you need a job.

(2) Send an email or DM to someone at a company you like, ask to buy them
coffee/beer, and make it clear you don't want anything from them. Ask them
questions -- or even better try to do them a favor... promote a side project,
make a connection, etc.

(3) When you're ready to make a move, reach out again to all the people you've
met and ask if they're hiring. Most people are happy to forward a resume --
especially because so many companies now offer referral bonuses. It's a win-
win.

(4) KEEP MAINTAINING THESE CONNECTIONS EVEN AFTER YOU GET THE JOB!

~~~
volkk
sounds great except now that person forwarded the resume, and you still have
to do the exact rounds that you would have done when cold calling unless
you're applying to a small shop

~~~
efields
But HR will come to the referrer when that candidate bombs their homework and
the referrer, if they can vouch for you, gets a chance to defend your honor.
"Oh, that makes sense. Joan was terrible at that kind of thing but she built
this amazing thing that did this and that and that…"

------
pnathan
I suspect OP is in a space both professionally and physically where the job
market is poor and a ton of cruddy candidates show up.

I relate though, although I'm in Seattle area, which is a great place - I
interview really badly. I strongly agree that hoops are getting added.

However, I have found that great companies do compete on hiring process.
Microsoft remains the Gold Standard for me in how fast they turnaround their
hiring when it gets going.

> The job search takes much, much longer than it used to.

No. I'm picky and I don't practice stupid questions. It's always taken a long
time for me. If you hit the right company and have the right skills, it'll be
under two weeks for a hire though.

> No one believes that anyone can actually code.

Yes.

> Coding Tests Can Trip Up Even Good Engineers

Yep. Probably 10% of the time I have a "frick, I blanked" moment.

> Extensive homework is now normal.

Nope. Find better companies?

> Every company’s “process” is different

Every company believes they are snowflakes.

> Outsourced hiring “services” are very much in vogue

Yes, but I think this relates to competitive hiring spaces with lots of poor
candidates.

> Companies Really Want to Know Your Salary; Don’t tell Them

Sigh.

> Interviews Matter Much, Much More to You Than to the Company

Yep.

> Age discrimination really exists.

I'm definitely not looking as young as I used to and it worries me.

> You’ll never really know why you weren’t hired.

That's because they don't want to be sued.

~~~
warrenm
> Every company believes they are snowflakes.

And yet...on average, companies are "average"

~~~
ljw1001
If only. Many companies hiring this way are Paul Graham's "mosquitos" whose
role in the tech ecosystem is to have a one in 10 (or 100) chance of making it
big, and are largely running on a cocktail of delusions and hype.

~~~
warrenm
They may be _trying_ to be those "mosquitos" ... but they're still - on
average - "average"

------
raarts
> Coding Tests Can Trip Up Even Good Engineers

I recently took the first one ever in my career (in my late fifties). People
tell me they think I'm an excellent programmer, but I did awfully bad. Why?

\- it was my first time

\- in daily life I switch between many languages, devops, meetings, and
research. It always takes me some time to ramp up, especially on syntax:
coming from Elixir, switching to Javascript: how does JS access object members
again? I usually need an hour or two to get up to speed again.

\- the tasks are very much outside the normal realm. If in real life I need to
map some multi-dimension array, I first look for libraries and such, and if
not, approach this as writing a library function: take my time to do it well.

Even though I could rationally understand the reasoning, it still felt
demeaning, given my resume. Also, because I underperformed, it's easy for them
to jump to the wrong conclusions.

~~~
alacombe
Welcome to the club...

~~~
raarts
Also, I never heard from them again.

------
mightybyte
The "No One Believes Anyone Can Actually Code" point is right on the money by
my anecdotal experience. Just a few weeks ago I was asked to implement
FizzBuzz in an interview for the first time in my 15 years of engineering!
This was despite having a large amount of verifiable open source Haskell
projects.

~~~
time0ut
I usually ask a trivial problem like this. Not really to see if they can code
(I have had one or two people fail here though), but more to serve as a
conversation topic. Why did you do this? How would you do that? etc...

~~~
diminoten
But I don't want to talk about FizzBuzz! It's boring! There's a "right"
answer, and not a lot/any real choice or nuance.

Ask me about your current problems, problems the person filling the position
would need to have opinions about. If nothing else, maybe I could crack a
tough issue for you that would have material value.

I've given FizzBuzz, and I've done FizzBuzz. It's hard to do it/get it and not
feel like there's some degree of insult involved.

~~~
pixeloution
I _can 't_ talk to you about my team's current problems, and neither should
anyone else. If I do and you offer up a solution I'm in real trouble ...
because that's a lawsuit waiting to happen.

Try to remember, this is the country where a range check function resulted in
a lawsuit:

    
    
        private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
             if (fromIndex > toIndex)
                  throw new IllegalArgumentException("fromIndex(" + fromIndex +
                       ") > toIndex(" + toIndex+")");
             if (fromIndex < 0) 
                  throw new ArrayIndexOutOfBoundsException(fromIndex);
             if (toIndex > arrayLen) 
                  throw new ArrayIndexOutOfBoundsException(toIndex);
        }

------
hitekker
One thing I’d add: don’t ever check the box that says "Yes, I'm disabled" when
applying to a company. Ever.

Unlike declaring race or veteran status, admitting past or present disability
can only hurt your chances at getting an offer. Some employers may appreciate
the honesty, most of them will automatically and quietly hold it against you
at every step of the hiring process.

And they'll get away with it. Easily. The laws "protecting" disabled
candidates are essentially toothless, since "illegal" reasons for rejection
are often not written down or, at least, hidden from you and the goverment's.

[1] [https://www.monster.com/career-advice/article/disclose-
disab...](https://www.monster.com/career-advice/article/disclose-disability-
on-resume) [2] [https://medium.com/@mshannabrooks/this-is-the-lie-i-tell-
on-...](https://medium.com/@mshannabrooks/this-is-the-lie-i-tell-on-every-job-
application-b4111631ddd8)

~~~
CM30
I'm not sure I'd agree with that. Found I had better results when interviewing
when I mention being on the autistic spectrum beforehand. Possibly because
otherwise the chances that I'd struggle in the interview were extremely high.

Then again, maybe it's different in the UK here compared to the US as well.

------
Humdeee
> As a hiring manager, I’ve given homework assignments to weed out candidates
> from the pack but I always kept it reasonable, just a few hours in length.

"Just" a few hours has always, always been an underestimation when I've tried
these. I've been burned a handful of times now; both from my time and from my
belief that it would amount to something. I'm reminded of one instance where
follow up emails kept coming after submission: "Add in this now." "Okay, now
this." "Handle this." I consider myself an average engineer. I'm not
interested in increasing my sample size to try and average out variance any
longer.

I'm looking outside to one of the first sunny, warm days we've had here in
months. I can't think of anything more I'd rather not do than some arbitrary
company hiring project. I simply pass on these now and politely pull out from
consideration.

~~~
warrenm
>I can't think of anything more I'd rather not do than some arbitrary company
hiring project. I simply pass on these now and politely pull out from
consideration.

Yep. If you're gonna throw crap at me like that _NOW_ ...it's only going to
get worse _LATER_

------
AndrewKemendo
I guess I don't understand why companies do this process.

When I was hiring Senior engineers for Computer Vision and 3D rendering jobs
my process was thus:

1\. Post job and simultaneously search for engineers we thought were a good
fit technically

2\. Reach out to people I thought were qualified based on their specific
previous work that was related to the job I was hiring for

3\. Review submitted applications for relevant experience

4\. If we thought it was a technical fit, we would do a <30 minute team phone
call with some basic work history questions, description of role/salary and
work logistics (remote, dev environment etc...)

5\. If we were satisfied with that, send them a <10 hour total, paid,
production project at an agreed upon hourly rate. If the candidate didn't have
the required IDE etc...it would basically be pair programming

6\. Review code, speed and communication

7\. Send a hire/no hire decision immediately

From first contact through Steps 4-7 it would ideally take less than a week,
depending on the candidate's schedule.

We were only burned on this process twice.

Once the guy kept trying to negotiate salary up over two weeks so that he
could get a higher price somewhere else.

The second time, the guy did well with initial production, but over time he
ended up using local college interns to write his code, who got other jobs and
his commit speed fell off of a cliff.

Since we are a remote team, trust was paramount, and we trusted quickly by
default. Nobody ever had complaints about the hiring process and we had a
higher than average success rate for hiring fantastic developers and getting
quality code into production quickly.

We never asked current salary because it wasn't relevant. I knew what I could
pay and that's what was offered. If they asked for more and were worth it,
then I would try and find money to make it happen, but generally it wasn't an
option.

I would do it the same in the future.

~~~
warrenm
>We never asked current salary because it wasn't relevant. I knew what I could
pay and that's what was offered. If they asked for more and were worth it,
then I would try and find money to make it happen, but generally it wasn't an
option.

Thank you!

Some _honesty_ and forthrightness for a change.

(It's something I put in a blog post
([https://antipaucity.com/2013/03/25/what-to-offer-to-be-
the-b...](https://antipaucity.com/2013/03/25/what-to-offer-to-be-the-best-
possible-employer-ever/#.Wt-MtdPwbgo)) 5+ years ago ...yet have only seen done
once in my career)

------
jetsnoc
> no one actually believes that anyone can code. [..] When did an entire
> industry of people get pre-judged as lying?

I've been hiring recently for a senior developer and I have had a dozen or
more candidates not be able to explain composition and inheritance or the
differences between an Object Oriented or Functional language. One person
started describing how to define functions and another couldn't really explain
inheritance.

For my company, candidates lying on their resume is our experience. A number
of people ARE lying on their resume. we've front-loaded a lot of the "we don't
trust your resume" in to the screening process and the first 30-minute screen
because so many people list the dogs breakfast on their resume, but really
can't do those things. I think a lot of times, someone else on the project
team may have hacked on that type of thing and so they list it on their
resume. There aren't a lot of good answers -- besides validating those
skillsets -- since people can list anything that they want on their resume. I
would love for someone to have an accreditation or certification program that
was widely used so that we could know someone could do the work and most
importantly do the work well since the implementation and the patterns they
will be choosing will be with our company for years to come.

~~~
spirodonfl
I agree with the idea of a certification program. Even a full-on curriculum.
At the end, you walk away with something approved by the industry in general
as something of value. Something that indicates "This person knows how to,
bare minimum, fizzbuzz" or regex fizzbuzz with your choice of wording.

I'm trying to get opinions from developers (myself being one) on what kinds of
things that kind of program would have to include. I'd love to hear some ideas
if you have any.

------
joyeuse6701
Coding interviews hide subjectivity behind the veneer of objectivity. They are
the worst type of interview.

Maybe I'll make a 'fair coding interview'. The candidate and interviewer get a
random coding problem they must solve together. We'll see how the candidate
and interviewer feel about each other after the shared trauma.

------
ChuckMcM
I find the coding thing interesting as well, in part because there is coding
and there is coding.

I suspect it is the difference between "coding ability" and "coding fluency."
In the former a candidate can apply known patterns of a give language to a
problem and with just a few searches on StackOverflow get it working. A person
who has code fluency can create the algorithm in the language of your choice,
pretty much on the spot.

In the music world you meet people who can play a song on the keyboard that is
note perfect, but they can't transpose it into a different key. Its the
difference between playing the keyboard and using the keyboard to express a
musical concept.

Can you speak a language if all you have done is memorize an extensive phrase
book? Yes, are you fluent? No.

The number of candidates who really understand the nature of coding and so
they can quickly adapt to any idiomatic language is still quite small in my
experience.

~~~
cableshaft
> A person who has code fluency can create the algorithm in the language of
> your choice, pretty much on the spot.

I've professionally used each for a year or more C#, Python, Javascript,
Objective-C, Java, PHP, Visual Basic, and ActionScript over the years. But if
you asked me to write a function in anything but the first three languages, I
will almost undoubtedly stumble a bit in producing them (hell, I still have to
look up syntax for Python periodically).

That doesn't mean I couldn't pick them back up in a future job very quickly
again (each job I worked for I was usually contributing to their code base in
a few days, never longer than a week), it just means I don't have them fresh
in my head and I can't store absolutely everything in my head forever.

But you'd still probably think I was incompetent. I've certainly given that
impression before when I had an onsite scheduled by a recruiter and given less
than 24 hours notice for an Objective-C job, a language I hadn't touched or
thought about in over a year, and was handed a laptop by a Junior Programmer
and was told "Code up an app for me." while another interviewer sat quietly
across the table from me and stared at me the whole time while I refreshed on
a years worth of XCode changes and forgotten syntax in real time.

After that wonderful performance they didn't give much weight to the two
employees in their department that worked under me at a previous startup I was
Lead Programmer for and vouched for my skills.

~~~
ChuckMcM
> _I 've professionally used each for a year or more C#, Python, Javascript,
> Objective-C, Java, PHP, Visual Basic, and ActionScript over the years. But
> if you asked me to write a function in anything but the first three
> languages, I will almost undoubtedly stumble a bit in producing them (hell,
> I still have to look up syntax for Python periodically)._

It is for exactly this reason that if I'm interviewing you and want to know if
you can code or not I will ask you to write up an algorithm rather than a
program. I might say, "Show me the algorithm for locating a node in a binary
tree, now do the same for a hash table. Now how would you insert into each of
those?" And then, as many programming languages do, I try to tie one of your
hands behind your back, "Ok so the language you're going to use doesn't have
pointers" or "memory allocation" etc.

But I only interview that way because I see computer programming languages as
an impediment to expressing what you really want the computer to do. And
people who can code, first and foremost understand exactly what needs to be
true for the code to work, then when they run into limitations of the language
figure out ways to express those same concepts given the limitations.

If you were being mean you could add limitation after limitation until you
were down to a minimally touring complete system. And if they can still make
it do what you're asking, then they really deeply understand how to get
computers to do what ever they want them to do.

I agree with every criticism that "coding tests" should not be about whether
or not your syntax is accurate or you have the standard library memorized. I
explained to a colleague at Google once that having total mastery of English
grammar doesn't make you a writer.

 _I_ wouldn't think you incompetent if you didn't have the syntax at your
fingertips.

But here is the rub, if the _interviewer_ doesn't know how to code they can't
reliably test for that ability in others. When I hear or read stories like
yours I wonder about who the company has put in charge of interviewing these
candidates and what biases are they bringing to the situation.

------
LandR
> Number 1: It Takes Longer than Ever to Get Hired

Last twice I've looked for a developer job, I got offered a position and was
hired within 2 weeks.

> No one believes that anyone can actually code.

Quite rightly, most devs can't code.

> Extensive homework is now normal. Not been my experience, I've done some
> homework assignments but none were ever more than 1 hours work (and then
> even the standard of the tests were so low they were really 15 mins work..)

> You’ll never really know why you weren’t hired.

This bothers me too.

> Outsourced hiring “services” are very much in vogue

I hate this. Almost all recruiting I see is done via recruiters who are at
best case flakey and worst case self serving liars who will try to pressure
you into going to interviews you don't want to go and to take job offers you
don't want to take. Sometimes flat out lying to you about the role only for
you to find out at the interview. I had one interview that I went to expecting
it to be C#, the interview was all Javascript (which I don't do at all). Or
the recruiter will tell you that you have to decide right now this minute,
when you don't.

I had one job offer where the recruiter said you've been offered the job but
you have to tell them now if you are accepting it. It was funny how after
telling the recruiter that I want to think about it over the weekend and if
that's not an option than I would like to decline the offer, well now all of a
sudden the company were completely willing to let me think over it for a
couple of days...

I _hate_ recruiters.

~~~
logfromblammo
At times, I have tried to press a contact from a job lead on what I could have
done better in my interview. They will not give you even a single bit of
feedback--a seemingly innocuous yes or no question is met with dissembling or
equivocation, always.

What bothers me most is that employers don't seem to be showing equal
commitment to the interviewing process. They will ask you to do hours worth of
homework for them, but then can't be arsed to discuss it with you for five
minutes. They will ask for your salary history, but clam up if you ask them
what they pay other developers in the same position. They will take your
application as a senior developer, then ask if you'd consider being an entry-
level tester. They spend hours grilling you to prove your worth, then spend
zero minutes trying to sell you on their company.

~~~
SmirkingRevenge
> They will ask you to do hours worth of homework for them, but then can't be
> arsed to discuss it with you for five minutes.

This has been my experience with homework assignment interviews (Though I
still prefer them to whiteboards).

In no cases, has any interviewer reviewed my homework before the interview. So
the homework critique/qa sessions end up being more like a presentation or
walkthrough of your solution, like a presentation for a meet-up, even though
they are often described as more of a code review/interrogation about your
choices.

Which I don't mind honestly. If you know that going in, and are prepared - its
an opportunity to impress, if you can be polished.

Talk at them about your solution for the allotted time or until they make you
stop :P

------
pascalxus
It's official. We now definitely have a vast oversupply of engineering talent
available in the marketplace.

This post is a great report and a must read of all engineers.

~~~
alacombe
Not necessarily, if there is one constant in the jobs I've been in is that
even if we've got the funds we're pretty much constantly under staffed (ie.
overloaded). HR is the broken link.

------
mixmastamyk
Nailed it. Despite the “shortage” (haha) Been underemployed for quite a while
due to the these ugly practices. It’s very frustrating to have misguided folks
in control of what you are allowed to work on and hellbent on wasting time.

One interview was for a Java Spring position, advice says study! But study
what? I studied spring but interview was dozens of database questions instead.
Could be CS, lang, framework, db, metrics, platform, OS level. No one knows
all of these subjects completely.

Companies are so skittish that I recently could only get a two-week trial at
low pay after crushing a call/homework. Hopefully they won’t be offended when
I show up without sockhat and beard. :p

------
maxk42
I'll throw it out there that I think coding boot camps are partly responsible
for this situation. Yes, there were several very reputable ones, but there
were also a lot of shady joints operating as little more than diploma mills.
They were churning out thousands of unqualified candidates and as a senior
developer in charge of hiring it suddenly became apparent that the quality of
these candidates was much lower than I was used to. When they couldn't get
jobs easily they may have began seeking employment at lower wages and it looks
like the wages have definitely been dropping industry-wide in my location.

------
gimmeDatCheddar
Welcome to a job market where there are hundreds of other qualified candidates
competing for the same job. This is why government officials and company
spokespersons peddled nonsense about there being a shortage in tech - it was
to saturate the market with so much labor that they could start doing this and
eventually paying less since they can just hire someone 5% better at 75% less
pay.

------
CM30
I think the issue here (and the one that's causing all this pain and
confusion) is that the level of expertise needed for an engineering role
depends significantly on the company in question. For instance, a company like
Google (or the other ones in the same league) need someone with a lot of
programming experience and knowledge of various algorithms, whereas your small
agency or company with a web development team might need someone who can
install/maintain the CMS and upgrade the plugins every now and again. What's
more, the two companies aren't necessarily paying a different wage for said
work, so it's entirely possible that someone with far less coding experience
is getting paid a small fortune and someone with lots of experience is on the
brink of poverty.

The problems we see in interviews (assuming people are lying, awkward
technical tests, etc) all come from this mismatch, and people either not
understanding what they're capable of or confusing things deliberately. A
senior engineer at a small company might be classed as a junior at a large
one, and when question time comes, that causes issues.

And I'm not sure what the solution is there. I mean, the needs for each
company are different, and there's always certainly a place where a developer
of any standard could find a job. If they can do what their employer wants,
does it matter if they don't know fizzbuzz or can't write a multiplication
table? Probably not.

The real question is likely about how you distinguish between what a
junior/midweight/senior developer/engineer is, in a market where those roles
could apply to virtually anyone in the industry.

------
exelius
Yeah, the entire HR process at most companies is so incredibly broken for
technical candidates.

One of the problems IMO is that HR doesn’t know shit about tech, and dev
managers don’t know shit about HR. A dev manager who needs a person tells HR
“I want to interview 10 people for this open job req” — which is likely just
some bullets vaguely describing job responsibilities.

HR, having very little idea what any of the bullets on the list mean, do their
best to filter resumes. Because they’ve had to do this a lot in the past, they
engaged an outside firm to issue coding tests to make sure they don’t pass on
shitty candidates to the dev manager (they got dinged last year on their
review for that!)

So hence all the bullshit _before you even get to the guy who posted the job_.
Part of the problem is that the dev manager just expects to be able to throw
this over the fence to HR.

One way I’ve solved this in my teams? I don’t expect HR to do resume screens.
Sure, I have them do a basic screen for candidates who don’t even mention
development anywhere on their resume, but I really don’t expect HR to be able
to detect bullshit.

The key is to treat hiring a new team member like any other task you have to
deal with. But the days when engineers can sit heads-down and code are all but
over; because the situation described in the article above is what you get
when you try to do that.

~~~
slgeorge
> "HR doesn’t know shit about tech, and dev managers don’t know shit about HR"

This is the cause of a significant amount of waste, friction and general anger
for both sides in my experience. Technologists are well-known for their TLA's,
and HR teams have their own obfuscating discipline-specific terminology,
assumptions and values.

The incentives for external recruiters are obviously a problem and even for
internal recruiters they are mostly measured on seats filled rather than long-
term retention or the candidates performance.

Hiring managers themselves are often extremely poor at describing or even
understanding what it is they are trying to hire. They often struggle to
provide clear and actionable feedback that can change the search.

Figuring out that collaboration is definitely worth while!

~~~
exelius
Right to all of these; which is why you have to make it the hiring manager’s
job to be _very_ involved with the process. HR should be involved for
governance purposes, but the manager and the team need to be involved with
hiring new team members.

Part of the problem is that no matter how careful you are, it seems whenever
you bring in 10 candidates to interview, 1 is obviously overqualified and has
higher salary expectations than you can offer, 2 are about right (but likely
also have other offers), and the other 7 are varying shades of “sorry, not
right now...” to “why did we even let you in the building?”

It’s entirely normal to interview 10 candidates, make 2 offers, and get no
accepts. That’s a huge waste of time on everyone’s behalf. But I have yet to
see anyone find a way to significantly improve on this process, because as the
OP states, everyone figures out to just start googling the answers to the
questions.

------
golergka
> When did an entire industry of people get pre-judged as lying?

That's the kind of thing that happens when people lie. Everybody who's ever
hired engineers knows from experience that a simple Fizzbuzz test is still,
unfortunately, a very usable candidate filter.

A lot of candidates with years of real work experience simply cannot write
code. How else can we find this out?

~~~
Klathmon
A few years ago I was approached about a new opportunity, and through the
course of the interviews I was given a generic fizzbuzz-like coding challenge
and I completely bombed it. I got flustered, I got stuck on something trivial,
and I ended up running out of time with not much to show for it.

It was in a language that I had been using for 5+ years at that point, using a
framework that I had just finished architecting a whole application for, had
multiple open-source projects in, and the challenge itself was something that
I genuinely felt should have been extremely easy, but I miserably bombed it.

I'm almost positive to them I looked like a giant fraud, and to be honest I
felt like one too, but after some thinking I really feel that it was just a
bad day combined with being uncomfortable without my editor/tools that I use
in my day-to-day job that ended with me getting stuck and failing horribly.

I don't know a perfect solution, but when I was later in a position to hire
new devs, I avoided coding challenges because of that experience. I feel that
you can get MUCH more insight into a developer by just having them talk about
what they have done, go into details about problems that they solved, or how
they would approach problem X without any writing of code anywhere except
maybe some drawings on a whiteboard if necessary.

Coding Challenges to me test 50% "knowing the syntax and not making mistakes"
and 50% "knowing how to solve the problem". We have tools and compilers and
linters and syntax highlighting and good editors to solve the former in most
cases, it's the latter that I'm looking for in a good developer, so why would
I use a test that evaluates both of them equally?

~~~
mrfusion
I think this is most people who “can’t code”. Just nerves

I’ve been in that situation myself.

~~~
yojex
I'm really glad that you and the parent posted these comments. As someone with
pretty bad anxiety, this kind of thing prevents me from even going for
interviews. And, unfortunately, after browsing this thread it seems that this
possibility isn't even on most peoples' minds.

FizzBuzz-style filters not only don't prove that someone can code, they don't
disprove it either. I'm not sure what the answer is.

~~~
mrfusion
Honestly if it’s really bad I’d let them know before an interview. Just say
something like.

I have social anxiety. It doesn’t interfere with my work in any way but I’m
wondering if you could accommodate me in the interview by doing x y z.

It’s worth a try, right? I’ve thought about doing that.

------
nopacience
"That’s almost two months start to finish! And today that job remains on the
company’s web site – they still haven’t hired anyone."

That probably shows HR is just "working" and doing interviews. Not necessarily
to hire anyone.. they might just be gathering data. Maybe harvesting the
people available on the market. Checking if you are up to doing homework and
not getting paid. Checking what your salary is. Telling you make some ranking
challenges. Building a profile about you.

Your profile might get a price-tag and shared on the HR black market. I
suspect there are even black lists by segment shared on some HR black markets.

Then, there is also a big mafia/network that makes people only hire friends,
recommended or known persons.

------
bojo
I absolutely detest homework assignments, so much so that I don't use them
when I hire people for my team. It's a waste of the applicant's time, and as
other people have pointed out it is narrowly focused, sometimes not applicable
to the entire skill set the applicant can bring to the table, and is typically
trainable level material anyways.

I highly prefer to engage the person about their previous projects. Through
building good rapport it's easy to determine what they've done and where their
passion is focused. If they can't tell me the details of building an X app
with Y interfaces and Z databases, then I can figure out they are a
bullshitter with only 15-30 minutes of total time wasted. If we can get past
that step then we can start talking about more interesting things, like
optimizations, scaling out, and our favorite unrelated technology stack and
its merits. It's shocking to me that companies feel they need to do more than
this these days.

To be fair I work in an At-will state, so if by chance someone does sneak
through the process we have a 3-6 month probation period where we make sure
they can really do what they say they can. To date this has never been a
problem.

------
StillBored
Just to add to this a couple days late..

All this focus on coding in interviews is actually completely misplaced. Early
in my career I had no problem writing anything you asked, but reading other
people's code, and having a deep understanding was something completely
different.

Now 25 years later, I can still code, and given greenfield development, or
just larger pieces of work that by itself is somewhat isolated, I can make
features appear in a shocking short time. Similarly debugging my own code,
even once its reached into the hundreds of thousands of lines is usually
better done by thinking about what in the code base would case the given
behavior.

OTOH, the skill that really matters is the ability to debug problems in a code
base written by a team I wasn't originally part of. That is still really hard,
I'm fairly reasonable at it, but it probably takes me longer to understand
someone else's code that it would have taken me to write it.

This also means my bug fixes tend to take a few days if the bug is in an
unfamiliar piece of code. But, it also means that I can usually come up with a
fairly trivial fix (frequently just a couple lines of code). Vs a lot of code
reviews i've been on (which is similarly hard piece of software engineering)
where there is a ton of noise and some 1/2 fix that fixes a particular case
but fails to solve the general problem.

All that was a long winded way of saying that I suspect that software
engineering is in levels, there is the first level where you learn to code,
and there is the second level where you learn to understand all the different
ways other people code, and then there is the third, where you can analyze the
latter alongside a problem to determine not only does the solution solve the
problem, but is it covering all the edge cases. A 10x programmer is frequently
someone who avoids the second case, and fakes the third case by only reviewing
code which touches subsystems they wrote. Interviewing solely for coding
skills rather than coding skills + ones ability to read analyze other people's
code is missing the most important and hardest part of quality software
engineering.

------
rajacombinator
For a senior position, if resume + talking for a few minutes can’t verify that
the person is potentially qualified, it means you suck at interviewing people.
From there it should be a discussion to learn about thought process,
architecture experience, and people skills.

------
pkteison
I have interviewed a lot of people with great resumes who literally could not
fizzbuzz, or even write a simple for loop. And then if they can write the for
loop, most fail when it's a nested for loop. And I don't mean got the syntax
wrong - I mean just can't even start, on the simplest of tasks.

I hate that I have to question whether candidates can code, but as near as I
can tell, a lot of them truly can't. It leads to an interview process that I'm
embarrassed to need to use, but it seems reckless to skip it. I've worked with
people who really can't code, and don't want to be back in that situation
again. I'd love to have a better interview process, and I'd love to spend more
time talking about higher level concepts, but most of the process seems to be
stuck just verifying that the things on your resume are really things you did,
and not just things you were on the team for but didn't actually do, or
outright fabrications.

~~~
gnulinux
After college, I was interviewing with the company I eventually ended up with.
This was the second technical interview (and we eventually had a third). The
very first question I was asked was to write a function that prints out a
triangle like:

.

..

...

....

At the time I thought this was an attack to my honor. I literally felt
terrible, and thought the interviewer was mocking me, for some reason. I also
thought maybe I couldn't make my resume clear. Anyway, this was only a few
moments, since questions gradually became harder. Needless to say, after this
interview I was really curious why would they ask me such a simple question,
which is nothing more than 2 lines of python code.

But then I started learning about this mythical men, who have good resumes but
can't even write for loops. I guess I was naive and assumed everyone with a
degree in CS would be competent.

~~~
dte22
no offset for the triangle, not too bad

------
mooreds
Wow, I recently went through this experience and totally agree with all of the
points. My only addition would be to ask someone on the inside for feedback,
if at all possible. That was the only way I was able to get any tips that
helped me improve.

Also, I interviewed with a company called Jumpcloud in Boulder. The interview
process itself left some things to be desired but I'm writing to give them a
huge shout out that they actually gave me real, concrete feedback on how my
homework assignment wasn't up to snuff. Thank you Jumpcloud!

~~~
mkoryak
+1 on feedback.

Last time I was interviewing, the first place I interviewed was at a company
where I knew the director of engineering from a previous role. I went there to
have an informal talk with him and some devs. Later when I sent my resume I
was rejected right away. Luckily for me he told me that I came across like a
know-it-all crappy dev. He told me why I came across like that and I realized
that he was right. It probably saved me a ton of grief in later interviews
because I knew what things I needed to do and not do.

------
newssucker
From the article

"The general thing that I saw from everyone that I talked to is that no one
actually believes that anyone can code. At every stage in the interview
process, you’re going to need to prove that your resume isn’t a lie and that
you can actually do what you say you can. I find this ludicrous because it is
like interviewing an attorney and then saying to him “Please prove that you
can cite a Supreme Court precedent”. When did an entire industry of people get
pre-judged as lying? Don’t we exist in a country where the default assumption
is innocence not guilt?"

This is, IMHO, due to the fact that for years new grads would apply to jobs,
and the new job required: 7 years programming in X? YES, 4 years writing
scripts in Y? ABSOLUTELY, etc, etc. These new grads all had the attitude of "I
will learn that on the job, no one has 7 years in X". And now we have a world
of companies that don't think anyone can code. Don't know where they got that
idea.

~~~
dragonwriter
> I find this ludicrous because it is like interviewing an attorney and then
> saying to him “Please prove that you can cite a Supreme Court precedent”.

They don't need to do that for lawyers because the bar exam handles that (and,
for those with traditional legal education, the highly-standardized law school
curriculum.) The programming “profession” has neither of those features.

------
danbmil99
Actually now that I think of it, if I'm being cynical, the process described
in the article is precisely what I would come up with if I wanted to be biased
against older experienced people without admitting that was my motive.

8 hours of homework for the person with the kids who won't have time for it,
check

Tests optimized for people with young, facile minds who are recently used to
cramming random data into their heads spitting it back out, check

Complete disregard for domain level knowledge, specialization, or the value of
experience, check.

~~~
danbmil99
This process doesn't filter for competence. It filters for people with
fanatical enthusiasm to jump through hoops. It filters for people who will be
young, impressionable, and prone to being exploited.

------
deedubaya
Technical hiring is very much broken.

I took a stab at improving it, but found that tech has a very extensive
workforce built around it being broken that doesn't want it to change.

Sure, they want tools that help perpetuate the junk show they've built up, but
not to make the process quicker/more effective on both ends. Most that I
talked to openly disliked that idea.

------
toadi
Actually weird differences in culture. I'm from Belgium and this is a
contracting environment. You just hire engineers on contracting basis. Easy to
fire them if they're not doing a good job. The reason why we like it is
because it pays much better then being an employee.

Because it is so easy to cut bad engineers the hiring process is much easier.
As long as it pays well I don't mind the insecurity of working on this
basis...

Another upside of working like this is I can leave toxic environments quite
easy too :)

------
taco_emoji
> Number 6: Outsourced Hiring Assessment Services Are Very Much in Vogue

I ran into this a few years ago. I bombed hard when they asked me some
specific terminology question about the stages of the ASP.NET request
lifecycle. I believe I just said "I have no idea" and the call was over
shortly after that.

It was frustrating--why are they hiring based on esoteric trivia instead of
general programming skill? This assessment would've filtered out an
enthusiastic, genius-level Java programmer!

And is that sort of question _actually_ effective at measuring ASP.NET
expertise? I work with ASP.NET every day, and memorizing that information
would offer me zero benefit since A) I rarely need it, and B) I can look it up
whenever I _do_ need it. It's doubly frustrating to think there's someone out
there who believes I'm a weak engineer based on this misguided quiz.

~~~
amorphid
I've done 99.999% of my development on a Mac. I took a coding quiz a few years
ago that asked me where I could find the "ruby" executable on Windows.

~~~
alacombe
"In the PATH."

------
the_arun
The common thing I see is there is an implicit bias from interviewer, who
always wants to hire someone like himself/herself. I also hear comments from
the candidate that - as an interviewee if I interview the interviewer, he
might fail too. If the interviewer stays unbiased, we may see better results.

~~~
AndyNemmity
Absolutely true, but it isn't something that can be fixed.

The interviewer interviewing the interviewee is hilariously true. No
interviewer could answer questions about my domain expertise. Just like I
could never answer questions about theirs.

But they are in control and I am not, so there's no fighting it, just
indifferent resignation to the situation, and attempting to sort through it.

------
miesman
I'm over 50 (55) like the author of the article. As it is often said over and
over again, the best way to find a job/gig is networking. That's how I found
my current job. Having people on the inside pulling for you cuts though the
BS. It took about a week for me last time.

------
nly
Tests can be a great leveler if you have a subpar degree or limited experience
on your CV.

A number of years ago I was insta-rejected by e-mail within 24 hours of
submitting my CV for a role. I was cocky enough to reply to that rejection
email with a 'give me a shot'-type response, offhandedly tossed an online
coding test, nailed it, then invited to interview, and later offered the job.

I never took it, but it was a huge boon for my confidence.

------
notacoward
Maybe the difference in people's experience with candidates who can't code is
that some types of programming are full of BSers and others aren't. In nearly
30 years I've never encountered a candidate who flat-out couldn't code. If you
see a lot of that in your specialty, maybe you should ask yourself what it is
about that specialty that leads to a different experience.

~~~
modbait
That's been my experience as well. In addition, people are generally pretty
honest about where they're at, skill-wise.

That said, I have seen several people who were open about lacking the basic
requirements for a position get hired anyway. So, I wouldn't assume that
seeing someone incompetent in a position means they lied to get there.

~~~
ropeadopepope
What field do you work in?

~~~
modbait
General Linux programming, in a variety of fields.

------
sixstringtheory
I’d love to go into a technical interview where the homework beforehand is:
“pick any of our blog posts and study it for discussion” and then you talk
about it during the interview.

You can drill down as much as you want on any dimension of whatever topic you
choose. I think the choice of topic and how well the interviewee can discuss
it would both be good, and distinguishable, signals.

~~~
warrenm
Not only this, but it shows you're actually paying attention to the company

------
kenoyer130
Number 1: I think this is due to specializing in Ruby on Rails which is
falling out of favor? Or your city location? I know in my location the average
job hunt is 2 weeks.

Number 2: As someone that interviews people alot, this is cuz MANY people who
apply CANNOT code, no matter what their resume says. We have had people leave
and never come back during our console app on site test (read in a text file
and print out its contents with some minor formatting). This is resumes with
10 years plus experience in the language supposedly. And the computer has
whatever IDE they prefer and full internet access!

Number 3: I agree that CS type questions are pointless unless you are doing
stuff like that on the job. We have stopped using those.

Number 4: We now require an onsite 2 hour code project (designed to fit in
that time frame)

Number 5: True

Number 6: We use headhunters to weed people out but that is about it. For one
position the head hunter roughly run 15 people applying for each 1 possible
person to pass to us for the next step. Again, most fail a mind boggling
simple phone interview process for people who claim 10 plus years experience
in coding. Not knowing what the static keyword means in C# when they say they
are skilled in C# for instance.

Number 7: Don't have an opinion on this

Number 8: Again this seems to be your physical location. At ours there is
roughly 3 open positions for each matching person.

Number 9: Our company does not discriminate on age and are desperate for
qualified people with experience. Many times a candidate regardless of age is
stuck in one tech (winforms, MVC, Ruby on Rails (:P)) and we more discrimate
on someone who is not showing growth in their tech skillset. For example, are
you learning the basics of a cloud stack such as AWS/Google/Azure?

At the end of the interview, I would recommend asking "are there any concerns
or issues you would have with hiring me for this position?" and LISTEN to
their feedback. I am sure there are some bad companies but for the most part
it feels like you are not interviewing well for whatever reason. Maybe you are
coming off as defensive or hostile when questioned? I would also reach back to
the company and ask why they did not choose you. Most companies are way to
busy to tell each person why they were passed over, but if you show an
interest they will usually respond.

Anyway good post and good luck to you!

~~~
jiveturkey
> _At the end of the interview, I would recommend asking "are there any
> concerns or issues you would have with hiring me for this position?" and
> LISTEN to their feedback._

At the end of _each_ interviewer. Asking the HR person at the end of it all is
a waste of time for 2 reasons:

1\. they won’t know yet

2\. they won’t tell you

but the tech interviewer almost certainly isn’t trained to keep his mouth shut
and also generally isn’t expecting this question. caught off guard, you can
usually get a close to honest response. you do have to interpret a little
because people generally don’t want to hurt other people’s feelings right to
their face. apply modern day party invite response rules:

    
    
        yes: maybe
      maybe: no
         no: fuck no

~~~
Humdeee
My SO is a HR manager, many times as a screen for tech roles. It's interesting
hearing it from the other side. She's a brick wall with regards to sensitive
job information that lie past her scope of knowledge. She just won't release
it.

She says the same thing as you however: if you want the good stuff, you have
to attack the social vulnerabilities of tech people. They generally aren't
trained to know what to say or not to say past the obvious. With carefully
constructed questions, you can often get the information you're after.

------
AnimalMuppet
> 1\. The job search takes much, much longer than it used to.

Senior positions take longer than junior. There may be other factors in any
individual case, but just as a general rule, the more experience you have, the
longer it takes to get hired. This may relate to...

> 9\. Age discrimination really exists.

In my experience, I haven't seen it. What I have seen is _salary_
discrimination. I'm a pretty expensive guy. I've got 30 years of experience,
I'm way more productive than younger people, and I want to be paid
accordingly. A lot of companies don't want to pay that.

~~~
emodendroket
> Senior positions take longer than junior. There may be other factors in any
> individual case, but just as a general rule, the more experience you have,
> the longer it takes to get hired. This may relate to...

I recently read a thread on Reddit with people making the exact opposite
complaint -- that senior developers just didn't understand how hard it is to
find a junior position now.

~~~
rejschaap
People with very little experience have trouble finding jobs because companies
don't want to train people. People with a lot of experience have trouble
finding jobs because there aren't a lot of jobs that require that much
experience.

Because of title inflation the people with average experience match up best
with the title senior.

------
RomanPushkin
Interesting read. So here is what I've learned if you wanna keep on writing
code and stay competitive:

* You'll be discriminated the older you get. Make yourself ready:

* Career and big names is important. Companies wanna hire ex-googlers. Have Google on your resume. It's better to work in BigCorp for 10 years rather than being contractor for 10 years.

* Improve your interview skills. For engineer it's theoretical computer science knowledge and cracking code challenges on a whiteboard within limited time.

* Have a big thing on your resume. Source code, GitHub, whatever it is.

~~~
fuzzygroup
Hi,

You will absolutely be discriminated against the older you get. Your
observation on being a contractor for too long is likely on point (I was).

~~~
alacombe
Once a contractor, always a contractor. Especially if you remote. You'll get
the condescending "can you work 9 to 5 in a cubicle ?".

------
nebgnahz
> 1\. The job search takes much, much longer than it used to.

This is so true (also in Bay Area). I am still in the process of job hunting.
The first onsite was in mid March. I thought my last onsite would be last
Friday, but no, a few more are still being scheduled (I probably have to
withdraw some applications).

Also the negotiation with HR easily takes weeks. Despite I have offers from
some companies, I just couldn't get to the actual compensation numbers. (I
call this "HR Tai Chi").

> 3\. Coding Tests Can Trip Up Even Good Engineers

I have found that the interaction with the interviewers matters more here. If
you can solve all tests, then fine. But often times you may get blanked or
just stuck somewhere in your solution, and a good interviewer will be able to
guide you through and work out the problems collaboratively. I wish companies
would spend time educating and training interviewers. (I have had bad times in
my interviews where the "obvious" solution just didn't come up during the
interview, however much the interviewer hinted).

> 5\. Every company’s “process” is different

Yes, the good part of this difference is that "some are pleasant", and
obviously "some are annoying". But you get to experience the company culture
and how much they value engineers by their difference.

~~~
ropeadopepope
> This is so true (also in Bay Area). I am still in the process of job
> hunting. The first onsite was in mid March. I thought my last onsite would
> be last Friday, but no, a few more are still being scheduled (I probably
> have to withdraw some applications).

My first job in the Bay Area in 2007 consisted of a single 3 hour in person
interview. That's it. I got a phone call telling me the good news on my train
ride back to SF. It was my 5th interview and they all consisted of pretty much
the same protocol. And yet, some of the top comments on this post say that
hiring hasn't changed all that much. o_O

------
hfdgiutdryg
Every time I read this sort of thing on HN it brings on a wave of depression.

I love software, but I hate the modern software industry.

------
logfromblammo
Every time I see another iteration of this kind of article, it screams out to
me that we need some kind of worker's cartel that can enforce an embargo on
companies that don't meet some minimal standard.

Part of the problem is that companies keep getting more applicants than they
can handle, no matter how hostile their interview process becomes.

~~~
tboyd47
I agree, but the problem is that unions notoriously favor the older,
entrenched generations of a profession over the newcomers. Talk to people from
NYC (a place with still much union influence) and you see a stark difference
between the old folks and the younger folks in how they view workers' unions.

Software development is already so heavily dependent on enthusiastic young
people that I don't see how a union could get enough traction without
completely reinventing the idea of a union in people's minds.

~~~
s73v3r_
"but the problem is that unions notoriously favor the older, entrenched
generations of a profession over the newcomers."

There's nothing specific about a union that does this. The union is an
extension of the will of it's members.

~~~
tboyd47
Union membership rates are highest among workers aged 45-64. It may be a self-
fulfilling prophecy to say that unions are for the older generation, but I
think there would be either non-participation or real resistance from the
younger generations of programmers, if only for the perception people have
about them.

------
toblender
I'm starting to notice this trend as well.

I felt it was much easier to land a job in tech 2.5 years ago when I was last
looking.

Maybe we are reaching a point of too many engineers and not enough jobs?

------
kkotak
I could've written this exact post myself as I'm going through the process
right now. So thank you for taking time to share and building the hound!
Kudos.

As for the presently en Vogue hiring process for senior tech roles, I'd put a
deserved blame on companies like Google, where this bookish and silly way of
hiring was first codified by the founders and early employees who were fresh
grads/drop outs from schools - and that's all they knew about how to judge
who's better in class. And as more and more of people who went through that
process leave and start their own companies, they follow the same process -
thinking that's the best of breed way to hire.

As for age discrimination - it's very much alive and well - specifically in
the SF Bay area. Which is a shame.

------
galkk
It might be lucky occasion, but in my limited experience, I found that
European companies provide pretty good and detailed feedback about interview
performance.

In particular, Skyscanner feedback was outstanding (I've been referred through
one of Who's hiring thread) for both skype screening and onsite.

------
twodave
Imagine a world without dishonesty and deception. That is the only place where
interviewing for a software development job would be more or less straight-
forward. Too many people either flat out lie on their resumes or overstate
their achievements and involvement in order to get a higher-paying job. So
those who are hiring are left to separate the honest from the dishonest. The
only way to do this objectively is by adding complexity to the interview and
testing for the claims made by the applicant.

If you think it's hard finding a job, try hiring 10 programmers in a short
time, and let me know how it goes for you. Try bringing on a candidate who
spins his wheels for months (while you pay him) and who you then have to fire.
It's expensive. Companies are entitled to protect themselves.

~~~
mixmastamyk
> Companies are entitled to protect themselves.

But they don’t do it effectively, only wasting everyone’s time instead. I.e.
Protection has a significant cost as well.

------
blunte
Once you get to the age where they will discriminate (40+, in general), you're
probably better off running your own company or at least doing high value
consulting. And by high value, I mean _value_ (could be money, could be
freedom of schedule, technologies, etc.)

The last two corporate jobs I had, the companies found me. The few clients
I've had as a consultant came to me. Being visible and having a little network
is important, and of course having the current popular technologies is
important.

But really, doing homework, doing dances, building PoCs, and all that other
bullshit is... just bullshit. If a company is going to make you jump through
tons of hoops or begin taking advantage of you before you've even gotten the
job, they can just fuck off and hire the kind of person they deserve (who will
probably fit better into their organization anyway!)

Keep in mind, even if the company has some really awesome people, you're still
just useful while you fit. If their budget changes, or god forbid they're a
public company and are beholden to the almighty quarterly earnings per share
report, then you can be gone a week after you're hired with little more than a
"oh we're really sorry". That last bit is one really awesome reason to work in
countries that still have some sense of labor power. I think Germany is really
good on this, but my experience in Netherlands was... profitable in that
regard. Once you have a permanent contract, firing you typically means handing
you enough cash to sustain you for many months. I'm not sure what the
potential exit compensation is if you're fired due to poor performance, but if
they're just downsizing you'll get a nice goodbye check.

The only way companies will ever change their behavior is if the workers stop
bowing and begging. This is your life; and if you're truly investing your
creativity and giving your all, it should only be for a company halfway
worthy. Most companies are not, and you can tell from the interview process.
Hell, if you look at enough job reqs you can start to tell just from the req.

------
AndrewStephens
I have been interviewing senior engineers extensively for the last few months
while also interviewing at other companies so I have seen the process from
both sides. Different companies handle interviews in their own way but I know
exactly why interviewers ask the questions they do.

Coding tests are an important part of the interview, you would be surprised
how many senior software engineers have been in de facto management or very
specialized positions for 7 years and no longer know how to code. We are not
asking anyone to implement a red-black tree off the top of their heads, just
very simple stuff. I think this is important but anything more than a 20
minute question will not help further gauge a candidate. We tend to not put
too much weight on the coding test since some very good people have trouble
thinking on their feet under pressure.

We also recently started also asking for a simple homework assignment that
tests basic data structures and general C++ knowledge. It should take between
2-4 hours. Personally I hate homework and resisted introducing it but a well
designed exercise is great for separating out the wheat from the chaff and
allows a really great candidate to show some flair with a clever algorithm or
even just nicely formatted code. I would now recommend it.

I was asked to do an assignments during my job search and typically spent 3-4
hours on them. I've heard of companies asking for days worth of work - that is
completely unfair.

Finally, you would be surprised at how much outright fraud goes on,
particularly with junior candidates lying on their resumes. We have had people
on Skype interviews blatantly cheating to the extent that one candidate was
just moving their mouth while someone else off-camera was speaking for them.
"Mr Ed" did not get the job.

I ranted about the interview process last year[0] but now I am a little more
mellow now.

[0]
[https://sheep.horse/2016/10/so_you_want_me_to_hire_you_as_a_...](https://sheep.horse/2016/10/so_you_want_me_to_hire_you_as_a_c++_developer.html)

------
Guthur
The main reason I don't believe people can code from a CV is that in app many
cases they can't. Many candidates are being completely desingeneous with their
experience claims. Quite often it's obvious when you see a laundry list of
languages and technology stacks. I have had candidates come in claiming to
have extensive experience with hadoop, spark and Scala and then don't even
know what a hash map is let alone their characteristics. I had one candidate
struggle to even write a single function in their language of choice and mean
even just the basic declaration and then to my face still claim that they are
suitable for an in depth technical role. It's very frustrating.

------
hashfunktion
Senior level dev here (6+ years). My last job search was brutal. I aced my
interviews but still got a lot of rejections. The feedback included

* the team thinks you’re a great engineer, but you didn’t show enough excitement about the company

* we think you’re a solid engineer but not quite at the senior level yet, it’s ok though, we reject 98% of our candidates

* we do a lot of code story telling at our team (I kid you not) and you weren’t a great story teller about your code

* the team didn’t get the sense you enjoy pairing and we pair a lot here

I actually think the real reason was poor personality match but companies
don’t like being honest about that so they make up nonsensical excuses.

~~~
brynjolf
Code telling? What is that? I'm sorry about the job but that sounds hilarious.

~~~
hashfunktion
It was stupid. They gave me a project to do and during the onsite I had to
walk through the code in the project. I thought I was pretty thorough given
the time constraint. I figured it was just a bad personality-fit and they had
to make up something so they said "not a good code story teller".

------
ntnn
> Number 2: No One Believes Anyone Can Actually Code

It's about the level and structure of your code. They don't think you _can't_
code, they want to know how _well_ you code.

When I'm interviewing people I let them solve a simple problem as well - it
doesn't need to work, it doesn't need to be perfect. I just want to know where
the interviewee stands. Case in point - I've had a young-un just out of school
in for an interview and his code was clean, commented and had structure.

On the other hand I've had an older bloke in with roughly ten years of
experience as a programmer. His code was an absolute mess from start to finish
with K&R-style initialization etc.pp.

That is why I want to see how they approach and what code they produce -
someone may have been writing code since they were born, but if they never
went through a review their code will likely be bad.

> Number 3: Coding Tests Can Trip Up Even Good Engineers

That is true, hence a coding test should not be measured on the completion but
rather on the approach the interviewee took.

> Number 10: You’ll Never Really Know Why You Weren’t Hired

True and bad. I dislike companies who don't give the applicants feedback - or
even worse false feedback. Much like in a review - if all you hear is 'no,
wrong, bad, ...' you won't improve. You need explanations to single out the
issues you can work on (primarily in the short term).

------
dbg31415
> Age discrimination really exists.

Avoid age discrimination by screeners by limiting your resume to the last 10
years and taking the dates off when you graduated.

The last 5-7 years is more than enough in most cases... when I look at a
resume with jobs going back to the 90s... it's just painful. Nobody cares what
you were doing past your last job. Add 1-2 more jobs before that if you really
want to give me background, but as someone who goes through a lot of resumes I
wish they were capped at 1-page, and 3 past jobs.

------
nythrowaway
I don’t understand why getting a degree in cs at a good peogram isn’t good
enough for the proof you can code. I had to write a ray tracer in graphics,
calculate recurrence relations and code them in advanced algorithms analyzing
all sorts of run times, wrote a compiler.

My friends in top law firms hire from top law schools and don’t ask technical
questions to candidates. If they make it through top law schools they have an
extremely high success rate as employees. Should be same for our field.

------
royalghost
I recently did an onsite interview for a company which asked me to do a
homework assignment and make some code changes on the fly. The task was the
most stupid I never heard of, to call a controller method from another class
from a console. They called it "reusable."

After a week, the recruiter called me and told me that I am not selected due
to my lack of skills in object oriented.

This is the most ridiculous feedback I ever received.

------
mathgladiator
I think this and many of the comments illustrates part of the gap.

If you are in the big tech companies doing infrastructure work (and to some
degree, product work), then you need a very firm grasp of the basics because
you will have to revisit them. The reason one has to revisit them in these
companies is because scale will demand taking different evolutionary passes
that are not needed in most other companies.

What this does is create a barrier between jobs that pay crazy and the rest of
the market that just need to cobble together a product. I actually experienced
this many years ago when I assembled a hacker news meetup in the midwest. I
felt rather isolated because most people were assembling some ruby website or
some product while I wanted to build next generation infrastructure and write
my own database.

Now, the problem here is that ex-big-tech workers will bring the same
processes from big companies to smaller scale. Small companies need to pick
their battles, and they need to decide to educate and wield weaker engineers;
most will not because that is expensive.

------
utopkara
The problem is symmetric, and observations will match expectations if you can
treat it as such.

Put yourself in the place of the interviewer, who needs to decide on the
person they will work with for the next two years. Software Engineering is
already hard, and your interviewers are overworked. They are assessing whether
you will be able to pull your weight. Their livelihoods are in this at least
as much as yours, if not more. Interviewing is no different from cases where
you have limited information to decide on a critical issue, like buying a
house, choosing a surgeon, voting for town mayor. You have to separate the
important flaws from the minor ones, assess the risk, and pick the candidate
that is the best investment.

When you are in a technical interview, you are rarely assessed for some
generic software engineer ideal, but for skills that the hiring team have in
mind. The chances are very low that there will be a match with all positions
you apply to, unless you are also very selective about where you apply to on
your end.

------
komali2
>When did an entire industry of people get pre-judged as lying? Don’t we exist
in a country where the default assumption is innocence not guilt?

Well... a _ton_ of graduates can't code. Interviewers are constantly
struggling with people that can't fizz buzz. Hence fizz buzz's existence.

You don't see it until you post and are responsible for a job ad, which is
never for most engineers, and once every year or two for those that do have to
get involved in the process.

Lord forbid it's an entry level, you'll get tons of great-on-paper compsci
kids that never actually pinned down a programming language and aren't even
sure how to hello world out of a c# application (pro-tip, just fucking use
python or javascript lol). For frontend, bootcamp kids usually come out on top
in this scene, because the camps are specifically prepared for exactly this
problem (considering it's their niche - the very reason they exist).

(I've commented on another aspect of the article, but it was long enough that
I felt I should break this thought into another comment)

------
ph0rque
This is almost totally off-topic, but this sentence caught my eye:

> I built it because after I had applied for about 15 jobs, I had no idea
> where I was in the process and I couldn’t give my wife a decent answer about
> my progress because I simply had no idea.

The real reason why people do things is often like this! It was a very hard
lesson for me to learn, but very enlightening when I learned it.

------
web007
This feels spot on.

Having been on both sides of the table, I understand why these are true, but
still don't like a lot of these interactions. The worst one is ghosting,
there's no reason for an interviewer to leave you hanging, at least they
should be following up to say "You're still in contention but..." and do the
same regularly every few days until they can make a decision. The only thing
missing from your writeup is the observation that the hiring process usually
reflects the organization. If your interview and followups were chaos /
overly-complicated / streamlined, the company is probably chaotic /
bureaucratic / well-organized, too.

Also: @fuzzygroup built my job tracking idea! It's fantastic to see that my
laziness has paid off, and I want to hear more about how JobHound works out
for you. Please post a follow-up in a few days / weeks / months of what you've
learned or what you wish you'd done differently.

------
alexhutcheson
> Number 7: Companies Really Want to Know Your Salary; Don’t tell Them

This can easily result in wasting your time interviewing for companies that
will never be willing to meet your salary expectations. Unfortunately, a lot
of companies aren't up-front about how much they're willing to offer, so I'm
not sure what the solution is.

~~~
tropo
They don't know how much they are willing to offer. You wouldn't get much out
of a salary answer like this:

"Each interviewer grades you as 1 to 5. We sum that up, then multiply by
$10,000."

Even knowing the number of interviewers wouldn't help you very much. You'd
need to know how well the interviewers would score you, which won't be
determined until after the interview.

------
kearneyandy
"I got all the way to the end, nailed everything perfectly and then never
found out why I didn’t get it"

"I saw this repeatedly on jobs that I got all the way to the end point on."

"Total Jobs Where You Got an Onsite Interview: 2"

Interesting points, although I would probably want to see more data before
drawing the same conclusions.

~~~
warrenm
You should _never_ expect to find out why you didn't get hired somewhere. But
the answer is _always_ one of the following:

\- someone else was a better fit (tech, culture, attitude, etc)

\- you're actually truly incompetent

\- the interviewers are morons

99% of the time, it's that someone else was a better fit.

~~~
modbait
Unless you're astoundingly good, if companies are interviewing around N
candidates for each position, you should expect a hit rate of around 1/N.
Doing significantly better pretty much requires all three of those to be
simultaneously false.

~~~
warrenm
Indeed -
[https://news.ycombinator.com/item?id=16916575](https://news.ycombinator.com/item?id=16916575)

------
mogget
@fuzzygroup: First, this is awesome. It's a great example of channeling
annoyance at Badness. As someone said, "Better to light a candle than curse
the darkness".

I tend to agree with a lot of your points.

Re: JobHound, can you clarify your thoughts on what sort of privacy users
should expect? Obviously a lot the value to those fully in the hunt will be
using it to efficiently navigate public sites, but there are also private
opportunities and some that might be sensitive. Any thoughts? Obviously easy
to work around by separating job sets, but thought it might be valuable to
others, too.

Thanks again!

------
lkrubner
I try to write up each job interview I do, if it goes badly. Here are two
writes up, the first at Adaptly.com and the second at JustWorks.com:

Embarrassing code I wrote under stress at a job interview (at Adaptly)

[http://www.smashcompany.com/technology/embarrassing-code-
i-w...](http://www.smashcompany.com/technology/embarrassing-code-i-wrote-
under-stress-at-a-job-interview)

The JustWorks job interview

[http://www.smashcompany.com/technology/the-justworks-job-
int...](http://www.smashcompany.com/technology/the-justworks-job-interview)

I agree the job finding process has gotten slower and slower. Personal
connections are becoming more and more important. The industry is not as open
as it was 20 years ago.

~~~
orangecat
_Embarrassing code I wrote under stress at a job interview (at Adaptly)_

I've done about 100 interviews at a large tech company. You did fine. Maybe
not the best but far from the worst, and definitely in the upper half.

 _The guy who is interviewing me has mostly stopped watching, because he’s
already decided there is no chance in hell that they will be hiring me. He is
looking at his phone._

More likely he was bored because he's done this dozens of times and always
ends up twiddling his thumbs while the candidate deals with silly syntax
errors. (Incidentally this is a point in favor of whiteboards, so that you
both can focus on the actual logic rather than fighting the compiler).

 _I think they want someone who can write something like this in 5 minutes_

If an interview session is 30 minutes, the anticipated outcome is not that you
solve the problem in 5 minutes and spend 25 minutes chatting about the
weather. I guarantee that many if not most candidates don't get to the point
you did of having a working solution.

 _Even if they say “Please feel free to ask questions” if you phrase the
question the wrong way, or ask a question outside the bounds of what they were
expecting, it becomes a mark against you._

I obviously can't prove the lack of a subconscious effect, but I've never
criticized a candidate for any question that they asked. Confirming something
that was in the problem description is neutral, asking about something that
wasn't (e.g. "is the input case-sensitive?") is a positive.

------
bsder
> When I was recruiting, in years past, my HR department always strongly
> warned me against administering coding tests on the grounds of legal issues
> / fairness. Now that these are outsourced, I suspect that HR departments
> aren’t concerned at all about legal issues since they come from a vendor not
> themselves.

This kind of crap needs to stop. I think that some level of legal liability
needs to pass through outsourcing companies and land on the company that uses
them.

I also suspect that if legal liability started passing through outsourced
companies, you would see outsourcing collapse very quickly as companies begin
to see outsourcing as riskier than an actual employee.

Unfortunately, I'm not sure that we have the legal precedents to pull this off
without new laws.

------
southphillyman
Interesting perspective, not sure what to make out of it. Maybe the author is
having trouble due to location, or skillset, or maybe.... it's really just his
age. Recruiters are constantly contacting me and ex coworkers regularly ask me
for references so I just assume(d) the market is still red hot.

Last time out (3 yrs ago) I took about a month to land several offers and I
didn't really do the whole CTCI preparation or anything. I even received an
offer from a company whose take home code challenge I completely ignored
because I didn't feel like being bothered. This time around I think I will do
the full CTCI and leetcode regimen a I do agree it gets harder the more senior
you are as the compensation and expectation raise.

------
rs999gti
> 2\. No one believes that anyone can actually code.

>When did an entire industry of people get pre-judged as lying? Don’t we exist
in a country where the default assumption is innocence not guilt?

The coding tests and whiteboard sessions are necessary because there are no
standards in the software development industry.

There is no license, no standardized test, no nothing for me to judge if
you're a liar or the greatest thing to show up for an interview. There is no
professional developer license like a professional engineer license and exam,
which helps me distinguish between you being a beginner or a senior/lead
developer.

Without professional standards, all developers will continue to need to show
who they are and what they can do.

------
expertentipp
The numbers from „who am i” overlap with my last job search for a senior dev
role, even though I’m good 15 years younger. In the EU an additional obstacle
is that in radius of 400 km they start speaking completely different language
not knowing which significantly limits one’s options. Now, I’m happily sitting
at this one position at the end of the pipeline and have to relearn everything
and most of it will be useless in 5 years. These Angular/react/redux/etc
„communities” still think they are cool by reinventing and rewriting from
scratch a wheel. What about creating an up to date, consistent, search engine
crawlable documentation - it’s not cool enough for you, eh?

------
partycoder
Competitive programming is interesting, but it is very different from what you
get to do at work.

"Cracking the coding interview" and similar books are really about competitive
programming, which is what you get to do at contests like ICPC and such.

------
commandlinefan
I just can't wrap my head around how prevalent this sort of thing seems to be
- even as we hear, every day, that there aren't enough programmers to be
found, anywhere, even when you expand the search to include the whole world.

------
nickthemagicman
Job Hound is seriously cool!

If enough people start using it a database could be built on companies hiring
practices, what percentage of applicants is accepted/rejected, coding test
type, and all kinds of other potential big data about companies.

That data would be super valuable to us as a tech community applying to jobs.

Also, love the browser integration that populates the forms!

If you get enough help to work on it/funding a mobile app would be killer.

Could you show the job description on the page after clicking on the
bookmarklet?

And also on the show job page?

At first I thought it wasn't populating and it's super useful info because if
a job is removed it's nice to have visible!

Awesome job!

------
sigi45
While i do hate some hirigin practices, i will obey to get that one cool/great
job :|.

I do like programming / what i'm doing anyway and it is not that far fetched
to expect someone to write code or know what ACID means exactly. It is more
like 'sharpening your skills' and i like doing it.

I do hate homework. At least google and other companies do that together with
you and investing equal amount of time for it. When i get a homework, there is
often not much effort on the other side.

What i do is always ask for feedback because of that time i spend on the
homework.

------
Zaheer
I recently also built a tool in the job hunt space for engineers feeling very
similar frustrations. One of the most frustrating aspects for me was how
blurry the various career ladders translate across companies. Some people may
end up with a very different scope of work than they originally thought if
they weren't familiar with the leveling system of the company they applied
for. To this end I ended up building
[http://www.levels.fyi](http://www.levels.fyi) with a friend - do let us know
if you have any feedback!

------
sateesh
In my opinion the interview process for senior position should not be solely
focused on the technical aspects and coding alone. Coding is indeed a
necessary requirement, but as one gains experience it is important he/she can
not only code but mentor junior devs, instill good development practices in
the team, can effectively take a high level spec (say from Product management)
and break it into tasks facilitating an iterative development, and can
communicate well. Though it is a technical role, as one gains experience these
aspects become all the more crucial

------
funkdobiest
Wow, This really hits home. Senior Engineer here currently seeking a job. I
had a really interesting test project -
[https://gist.github.com/cmerrick/d0d8812f1c31e625adfd3333263...](https://gist.github.com/cmerrick/d0d8812f1c31e625adfd3333263fb8ff)
that was given after the first interview. I liked it way better than a test. I
will say the majority of interviews have been fairly high level when
discussing prior work and projects. Hopefully it will happen soon.

------
rjk2008
In our department we have made a concerted effort to eliminate "ah-ha" type
questions. We focus instead on questions that start with a straightforward
problem and lead to a series of deeper design-oriented questions.

We also, sadly, have found that a large portion of our interviewing time is
devoted to "fraud detection" as many candidates simply cannot do the things
that their resumes indicate they should be able to do.

------
ggregoire
What about the people who can pass the whiteboard/fizzbuzzs tests, but are
complete lazy asses who work 2 hours a day once hired? How do you detect these
profiles?

~~~
modbait
As a partial solution, carefully describe the reality of the work they'll be
doing. For example, "We're building a bespoke web server using our own in-
house programming language based on COBOL. The project has already been
cancelled, but for political reasons, we need to produce another million lines
of code on it over the next nine months." Etc.

In the face of such frankness, many lazy asses may decide to exclude
themselves. ;-)

------
stratigos
I agree in full with this article. I too have been freelancing for > 4 years,
handling whole startups' software needs myself, and am faced with the exact
same gauntlet of perplexing steps. My experience parallels the author's
perfectly. Now we just get asymmetrical experiences on 1) number of highly
qualified candidates for a job and 2) job creators' belief that not enough
qualified candidates are available for the job.

------
Myrmornis
> no one actually believes that anyone can code....When did an entire industry
> of people get pre-judged as lying?

Unless the author has never attempted to hire programmers, I don't understand
this attitude at all. It's extremely common to find resumés vastly
exaggerating the applicants skills in programming languages and technologies.

------
poulsbohemian
This topic of interviewing and hiring practices has become a regular weekly
showing here on HN, so I wrote my own thoughts on it:
[https://www.jeffstrickler.com/best-way-to-hire-software-
deve...](https://www.jeffstrickler.com/best-way-to-hire-software-developers/)

------
pjdemers
I'm not sure his lack of job search success is technical. I see several jobs
at VP/CTO level on his resume. As a hiring manager, I would pass on him as a
senior engineer, unless I was planning on promoting him fast. For guru-level
hands-on engineers, I want people who chose to make that their career.

------
wufufufu
I've seen senior candidates fail coding interviews, get hired anyway, but then
do OK on the job as far as I can tell. I believe it's more likely for new
college grads with a few internships to pass coding interviews than senior
candidates.

------
paul7986
Loved to see a Hacker News Poll

How long did it take to find your last job and break it down by demographics.

------
vemv
The process described in Point 1 is the most important takeaway. Probably HR
departments have all adopted this process following some best-practice which
surely arose in the last few years.

Maybe there is some blog post (from HR specialist) explaining it in detail?

~~~
jcberk
HR views recruiting as a funnel process, similar to sales. There are a set of
screening steps testing different skills, and at each step you lose a fraction
of candidates, until you get down to the set who accept offers.

E.g. [https://www.jobvite.com/recruiting-process/7-benchmark-
metri...](https://www.jobvite.com/recruiting-process/7-benchmark-metrics-to-
help-you-master-your-recruiting-funnel/)
[https://www.glassdoor.com/employers/blog/4-tips-for-
hiring-t...](https://www.glassdoor.com/employers/blog/4-tips-for-hiring-the-
elusive-software-engineer-infographic/)

That's a reasonable model, but it works best if all your filtering steps are
effective tests for the things you care about. Getting that right is
demonstrably hard, between some hiring managers who don't know or don't
communicate what they're looking for, some recruiters who don't understand
what they're looking for or how to recognize it, and some job-seekers who
don't communicate or demonstrate their skills through the hiring process. And
so everyone sees and resents flaws in the funnel.

------
amyjess
One thing I've observed is that the more experience I build, the less the in-
person interview matters.

By the time I get past the coding test and the phone interviews, I'm as good
as hired, and the in-person interview is just a formality.

------
ryanpcmcquen
Number 7: Companies Really Want to Know Your Salary; Don’t tell Them

So true. Do not tell them!

~~~
kp1234321
It's now illegal for companies to ask this in California.

~~~
warrenm
It's not illegal to ask in most places ...but it's stupid to answer :)

------
TheBaku
"Track your overall job hunt metrics - how many jobs you applied for, what
percent got to interviews, what percent got to second interviews and so on"

Oh please dont show me that. Im afraid

------
gain_sky
This article is weird. His resume looks impressive and it looks like he has
done some solid work but from the article he sounds like he feels entitled
because of it. Also I find it annoying how little he mentions about the kind
of companies hes applying to or even what country he's in (apart from one
reference to a company in California so I guess we can assume he's in the
USA).

> If an HR person says to me “Oh and we administer a coding test” then my
> first response is “I’ve taken a bunch of those, which one do you use?”.

If I was hiring and a candidate said that to me on the phone I probably
wouldn't invite them for an in-person interview.

------
dfjliasjg
When did an entire industry of people get pre-judged as lying? Don’t we exist
in a country where the default assumption is innocence not guilt?

Fucking LOL. I demand tests not to see whether you can write a for loop, my
wife has an art degree and can do that. I demand tests to see if you bothered
to comment your code, use version control, use tests, and actually put in some
custom logic instead of boilerplate CRUD. There are so many people who fail
those basic tasks, its unreal. Plus, programmers SUCK at interviews, so why
even bother giving it any weight? Show me talent in the homework and I'll hire
you.

~~~
ngngngng
Maybe it's still enough of an employers market for you to get away with this,
but I have enough interviews that I don't have to put up with long homework
assignments or horribly buggy leetcode tests. The company I most want to work
at usually ends up being the one that doesn't use these annoying interview
methods.

------
jiveturkey
sounds like a naive candidate to me. surprising (but not shocking) for someone
with so much experience.

if he’s 50 yo, assuming same career since graduation, his first mistake is
applying for senior roles. senior is 5-7 years experience. he should be
applying for staff roles at minimum and up to principal.

i guess you’re not supposed to slam posts here but this article is more of the
same old same ole.

i would like to see an article from the hiring manager POV.

~~~
nathanaldensr
In my experience, getting hired for those "post-senior" roles is even _more_
ridiculous than for senior roles. You often run into biased, judgmental, and
insecure directors and vice presidents who seem to be terrified that you know
more than them. I say this as a 37-year-old with nearly 20 years of
experience. Sometimes, people don't _want_ to believe that you know what
you're doing.

~~~
jiveturkey
yes, it is very, very challenging. please keep in mind it’s not that you have
to have technical chops, which you certainly won’t even be entertained if you
don’t, you also have to be a _very_ good culture fit.

------
ianhowson
> Number 10: You’ll Never Really Know Why You Weren’t Hired

Add to the hurdles:

* Salary negotiation

* Contract review/negotiation

* Reference check

* Background check

* Getting a work visa

There's still lots of work to do once you complete the onsite interview!

------
futurechan
Well, my company is hiring. I've been a part of the interview process
repeatedly, and I feel it is straightforward and fair.

------
opportune
So the author is complaining about coding tests and being doubted for knowing
how to code... yet converted 15 technicals into only 2 onsites.

~~~
positr0n
Could just be age discrimination. I've worked with more than a few people who
are very suspicious of people over 40 who are "still just coders," saying that
it shows the candidate lacks ambition or they must not be that good since they
never advanced to a more senior role like very-senior-principle engineer or
management.

~~~
maxxxxx
This is such a weird industry. Most current devs will be still coders when
they are over 40. Only a few can make it to management or high level lead
engineer roles. There are not that many openings for that kind of role. I used
to work as mechanical engineer and there it was totally normal to have
engineers who were 60 years old.

------
komali2
>Total Jobs Applied For: 82 >Total Jobs Where You Got an HR Interview 25
>Total Jobs Where You Got a Technical Interview: 15 >Total Jobs Where You Got
an Onsite Interview: 2 >Total Job Offers: 1

From a recruitment standpoint, this guy's "sales funnel" is remarkably
efficient. I'm more used to seeing a ration of 100 applications > 10-15 phone
calls > 5 onsites/technicals > 1 offer. Needless to say he blew the initial
phone call / interview numbers out of the water, though it did eventually
narrow down to about the expected number of offers.

I don't like the current state of recruitment and job hunting. In fact, I have
literally never met _anybody_ that did. Recruiters whose living depends on it,
our managers, the engineering managers we pitched to, our candidates, fucking
_nobody_ is happy with it.

Nobody has solved it though so now that we can all it agree that it sucks, it
would be irrational to sit around and complain about how it sucks instead of
adapting (and fixing it when you're not trying to figure out how to get health
insurance before yours runs out and you gotta spend 400 on COBRA):

It's a number's game. You must send a fuckload of resumes because sometimes a
resume for the perfect job will fall off the recruiter's desk or get lost in
their email, or get lost in their spam folder, or the recruiter just won't
understand what they're looking at, or there's a candidate slated for the
position already, or somebody didn't like the formatting of your resume and
got frustrated and threw it away. Or 50 other reasons.

That same randomness applies to each of the up to 10 steps (usually 3-5)
before you get an offer. They couldn't get you scheduled for an interview in
time. You came in and somebody thought your shirt was stupid or too casual.
You came in and somebody thought you were dressed too well and a tryhard. They
gave you a dumb algorithm that had nothing to do with a job and it created
salty feelings on both sides. I mean, there's just so many variables.

So in this system, your best bet is to increase the resolution as high as you
can. That gives you realistic access to the greatest number of opportunities
you'll actually like, and the luxury (or burden, I suppose) of choice.

Until someone fixes this systems. Lord alive, somebody please fix this fucking
system. The best progress I've seen on this front has been by coding test
websites that hyper-tailor your profile to companies with specific needs, i.e.
completely useless for every other job in the world. Beyond that your best bet
is to just align yourself with a god-tier recruiter that actually cares about
their relationship with you and their candidates (the established ones that
don't have a manager breathing down their neck to randomly spam out resumes
cause their numbers aren't high enough).

~~~
munchbunny
The only thing I've found to help with this sales funnel is... to know a lot
of people, and to invest time in networking. It sucks because in a
meritocratic system it shouldn't work this way, but it does.

I'm neck deep in my job search, and I'm getting to the HR interview at rates
around 30-40%, but that's because I'm getting to the HR interview at rates
near 90% where I was able to get someone to refer me or send my resume
straight to the hiring manager. For non-referrals, I'm seeing closer to
100->10-15.

I think that's just insane.

~~~
warrenm
HR is filtering - in my experience - 100s or 1000s of people for a single role
(or small handful of roles).

That _you_ are seeing 30-40% HR interview rates shows you've got _something_
on your resume (or your referrals) that's pushing your resume higher on the
stack.

~~~
munchbunny
Oh for sure, I was just pointing out just how drastic the HR filter can be. I
might have thought referrals would make a 2x difference in rates of getting an
interview right? But no... it's much more stark than I personally expected.

------
JJMcJ
I can remember older times when many jobs didn't even give tech screens.

Your skills were verified by the reference checks.

------
sjclemmy
Check out the jobhound link and check out the screenshots: “I got 5 out of 6
right but was given a 62%. Damnit!” Haha.

------
happyruss
nice article. I came to similar conclusions on my blog as well, searching for
a dev job in boulder: [http://www.gunkyfunky.com/blog/my-boulder-tech-job-
search-jo...](http://www.gunkyfunky.com/blog/my-boulder-tech-job-search-
journey)

------
lifeisstillgood
\- Companies are less willing to hire than I’ve ever seen

Is this true for other people ?

~~~
magduf
It's definitely not my experience in the DC area. There's certainly a lot of
pickiness, but I had no trouble getting multiple offers here recently, the
main problem was that some of them didn't want to pay much. I ended up going
with a company that's on a hiring spree and beat my asking price by a good
bit.

------
WrtCdEvrydy
Weird thing.

JobHound Sign Up Works, but the login link takes out of outside the page.

~~~
joekrill
Worked for me. Not sure what outside page you are referring to. Although there
was a weird problem when I tried to logout. It didn't really seem to work
right but eventually I got redirected to the login page again after clicking
around a bit.

------
emodendroket
This is pretty different from my own recent experience.

------
austincheney
I took a look at the list and I have to say the job outlooks must vary
considerably by primary skill. I would say that if, in the current market,
finding a senior development job is a challenge you are doing something
horribly wrong.

In my case I am a senior JavaScript developer who doesn't like the
straightjacket stupidity that is popular large monolithic frameworks. The
demand for this skill is stupid ridiculous. If you want a new job simply put
your resume online in one of those job boards like CareerBuilder or Monster.
Within 2 weeks the recruiters will discover it and I expect to get 6-8
responses eagerly pushing me into interviews once my availability is
"discovered". After those initial responses I might get another 10 or so
serious asks for my time.

Most people who do web work, in my experience, actually cannot code. If you
are a strong coder the interviews are largely a meet and greet, because you
probably have a strong answer for everything in your comfort zone and
immediately shut down questions about areas where you are weak.

You have to consider that web jobs are generally considered low barrier to
entry and so half the people that apply are grossly under-qualified and many
that are qualified are just learning to code and incredibly far away from
"senior" level. As a senior, an actual senior, expect to enter the job jumping
potholes and dodging landmines from the incompetent code already in place.
This doesn't mean that I think highly of myself, but rather many companies
don't know how to develop or hire strong web developers yet, in the meantime,
they still expect work to get done somehow like a mistake mosaic.

As far as salary goes I have generally made more time I have gone somewhere
else. Because the demand for senior web developers is ridiculous stupid many
employers suspect if you are interviewing with them then you are probably
actively interviewing with 3 or 4 other prospective employers, and so if they
believe you are a competent senior there is a rushed hurry to get a hiring
decision back to you as soon as possibly, often in the same day you
interviewed. With that rush comes high salary offerings, which I guess is an
effort to outbid the suspected competition.

If you are interviewing in the corporate world and actually are at the senior
level age is irrelevant and the preference skews a bit older. Nobody is going
to believe you are actually an awesome senior developer if you are under 24
years old unless you are a brilliant child prodigy who has been inventing new
software techniques for the last 8 years. I am on my way out of my thirties
and my age has not hindered any demand for me.

As far as interviews go what has done me well is honesty. This means telling
prospective employers things that might make them throw up in their mouths. I
don't like large blunted frameworks and so I prefer to get much of the
nonsense out of the way early on. If the disdain for the safety scissors is a
deal breaker then don't waste my time and I won't waste yours. Since the
demand for seniors is ridiculously stupid I am fortunate to be less afraid of
being so blunt and immediately honest.

------
shinryuu
amazing!

------
erikb
Can't fully agree in quite a few points. I understand how the author got that
feeling tho. Doing interviews is always eating away at one's confidence, no
matter who you are.

1\. no one believes anyone can actually code - I experience quite the
opposite. People expect others to be able to code just because they are
currently employed as software developer. That's not true at all. Sooo many
people can't.

2\. Coding interviews are not about findign the solution but about showing
some skills, showing how you handle things under pressure, your ability to
explain what you do etc.

3\. homework assignments are not done in professional environments.

4\. interviews matter more to you: I agree and really hate this. You need to
give 120% before you even get to the point where you can choose what you want.
And at this point you suddenly have 90% of the power and often not enough
energy anymore to make anything good out of it.

5\. And yes it's even part of the job of the company to NOT let you know why
you weren't hired. Still, I think you often know after the interview how it
seemed. Good feeling = chance, no good feeling = no chance, weird feeling =
usually weird job as well.

PS: One side note. A senior coding position might feel age discriminatory
because senior is for talented ~28 year olds to mediocre ~40 year olds. A 50
year old should be architect/manager or not switch jobs.

~~~
smsm42
> A 50 year old should be architect/manager or not switch jobs.

Why? What's wrong with coding when you're 50 if you like doing it? That sounds
like completely prejudiced and baseless claim.

~~~
erikb
Well I don't create the rules. Think of someone who does Judo for 20 years and
still only wears a yellow belt. It seems like this person has no skill. The
first impression is already negative, if one has a 20 something and a 50
something competing(!) for the same position.

Also the lowest level of each money-making hierarchy is usually where the
unacceptable stuff happens. In IT it's this huge amount of new languages, new
frameworks, new patterns that a 50 year old usually can't get into that easily
anymore, to some degree because he knows it's just a hype that will be over
soon. Even being 32 years old I get that feeling quite often already.

And let's say you really want to just code. Why didn't you spend the last 25
years of your career building a network and now simply do consulting work for
$300+/h instead of working as employee for less than half?

Now that I said all of it, I have to say that I actually even agree with it.
Everybody should have a plan how he builds and spends his career. And "I do
the same thing for 30 years" is neither a plan nor a smart thing to do in IT.
You could call it the disadvantage of individualism. You're free to do what
you want, but that also means you are responsible yourself to find a way that
works with the reality you face.

~~~
smsm42
> Think of someone who does Judo for 20 years and still only wears a yellow
> belt.

This assumes developing software is somehow an inferior practice to
management. Nothing could be further from the truth.

> if one has a 20 something and a 50 something competing(!) for the same
> position.

If a person with nearly no experience and a person with 30 years of practical
experience compete for a position, you'd choose one with no experience? Odd
decision.

> Why didn't you spend the last 25 years of your career building a network and
> now simply do consulting work for $300+/h instead of working as employee for
> less than half

Again, you are assuming than developing software is somehow inferior practice
to management. Again, this is baloney. And why one would want to trade doing
what one loves (development) to messing with contracts, bills, accounting,
CRM, etc.? Of course, some people might, but presenting it as the only way to
go is nonsense.

> And "I do the same thing for 30 years" is neither a plan nor a smart thing
> to do in IT.

Coding is not "the same thing". Developing software is an amazingly diverse
profession. Of course, you don't have to stay with a profession if you don't
like it anymore, but presenting it as if somebody who does is stupid and has
no plan is a complete nonsense.

