
What we do instead of technical interviews - kawera
https://be.helpful.com/https-medium-com-fnthawar-helpful-technical-interviews-are-garbage-dc5d9aee5acd
======
DoubleGlazing
As someone who has had to conduct technical interviews I have found the best
way to evaluate technical skills is to just chat. No tests, no whiteboard
challenges, no list of requirements to tick off.

Just let the candidate talk about their career and what they have done. Ask
their opinion of certain things. Ask about how they tackled certain projects
and give them the time to answer and go off on tangents. Treat it like you are
a few friends having an in-depth discussion over drinks.

Technical interviews focus too much on headline points. They want the
candidate to touch on or mention certain things that everyone should know
about the subject. I'm not interested in that, I'm more interested about them
mentioning less obvious things such as known quirks, bugs or tricks about the
subject matter. Stuff that only a regular user would learn about.

The problem with this approach is that for many companies HR insists on
structured interviews. I once had do some interviews for a couple of C# roles.
The interview format was literally the same as the game show Talk About. The
interviewee was given time to talk about a subject and we had to tick off a
list whether they mentioned certain keywords and phrases in the allotted time.
The same format applied to the HR interview. Whoever scored highest got the
job, a very silly way to do recruitment.

~~~
hasenj
That's just about the worst way to filter candidates. You are selecting for
chatty people.

~~~
Mikushi
Competent chatty people.

If you can't express your competency during an interview chat I don't see how
you could be a good candidate (there are exceptions), nothing more damaging to
a team that someone who can't communicate.

~~~
SpEd3Y
How about shy people who have a hard time talking to new people? Who only feel
comfortable after a couple of days and then they become very chatty? Aren't
most developers like that?

~~~
throwanem
Not significantly more than among the population in general, at least not in
my experience.

Being able to simulate extroversion for short periods at need is a useful life
skill for any introvert - I've found it invaluable in plenty of situations
beyond just job interviews.

------
justherefortart
I've found simply talking to prospective employees (be it software or anything
else) about how they work, challenges they've encountered and how they
overcame them and figuring out their attitudes has never failed me in hiring.

The bullshit feeling that everyone has to live and breathe coding is the
biggest nonsense thing I encounter in this field (software development). A
good job with a good work environment is more than enough to get productivity
and results from your coworkers.

99.9% of the issues I encounter in companies as a consultant or employee
revolve around poor management. They don't have budgets. They don't have
plans. They don't have people that understand IT. Their IT doesn't understand
how their products affect the bottom line. Add in about 1000 other "management
doesn't get it" items and you might be close to the realistic picture.

It's quite depressing in practice.

~~~
ekidd
> I've found simply talking to prospective employees (be it software or
> anything else) about how they work, challenges they've encountered and how
> they overcame them and figuring out their attitudes has never failed me in
> hiring.

At previous jobs, I've run into candidates who interview well but code poorly.
They look good at first:

1\. Their resume looks reasonable.

2\. They sound qualified on a phone screen.

3\. They can talk about previous projects.

4\. They seem like great people to work with.

...but when put to the test, they _can 't code_. I'm talking really simple
stuff, like "You have 40 minutes to write (something no harder than
FizzBuzz)." They can use their own laptop, with the language of their choice,
and StackOverflow. Or for a job involving Scheme, we asked them reverse a
singly-linked list. These were almost insultingly easy tests, given the posted
job requirements. But I saw otherwise promising candidates struggle for the
better part of an hour.

But asking people to code can also _help_ them get hired. I remember one
interviewee who was doing poorly until we asked him to code, and then he
solved the coding problems in literally about 20 seconds. We hired him, and he
turned out to be a incredibly strong team member for many years.

I think one fair way to handle these things might be to offer interviewees a
choice:

1\. We can ask you to write code during the interview, or

2\. You can submit a link to a small open source project for us to look at.

That gives both people who can't code under pressure and people who don't
write code outside their day job an option. And it provides the interviewer
with a work sample to discuss in the interview.

~~~
FLUX-YOU
>I remember one interviewee who was doing poorly until we asked him to code,
and then he solved the coding problems in literally about 20 seconds

It's entirely possible that person just happened to have seen the problem
before. Many interviewers would throw additional problems at them if they
solved it that quickly because they would assume this. Especially true if you
pulled the problem directly from a problem site where it has a high chance of
someone seeing it before.

You can get decently far as a programmer in mediocre jobs just knowing how to
write a CRUD app. You'd never use modulo or reverse a linked list in these
positions, yet they pay $60k+ and otherwise deliver products. The org doesn't
care that code is delivered at a bureaucratically slow pace or incredibly
simple because it's dysfunctional in the first place, so delivering a feature
in 3 days which would take a good programmer 2 hours doesn't matter. Lots of
"the user is wrong" pushback when something in the code fails too.
Unfortunately, because of the way we're made to write resumes, these positions
can be made to appear like any other normal position.

I think it's more interesting that he seemed to do poorly until you gave him
code.

This may also sound insulting but I certainly don't mean it to be: maybe your
code base isn't that challenging, which is why he is now a strong candidate.
Are they doing maintenance, or contributing a lot of new code which requires
architectural decisions that weren't previously found in your code (and could
be copied)?

~~~
ekidd
> _You 'd never use modulo or reverse a linked list in these positions_

The position I'm thinking of was a senior developer position that involved
writing large amounts of Scheme code to interface with a video game engine.
Typical Scheme code uses recursion where normal languages would use loops, and
singly-linked lists are the most basic Scheme data structure, used for
everything. So if you can't reverse a linked link in _some_ language, you're
probably not especially qualified for a job as a senior Scheme programmer. Not
everything is a CRUD app.

(And it's basically the first homework question you get in a first-year Data
Structures class, so it's not too much to ask for a senior dev doing low-level
work.)

> _I think it 's more interesting that he seemed to do poorly until you gave
> him code._

I've found that some amazing developers have weak people skills. They don't
necessarily know how to write a resume, and they don't know how to "sell"
themselves in interviews. But they may still be brilliant, dedicated coders,
and excellent teammates.

~~~
fitpolar
_> so it's not too much to ask for a senior dev doing low-level work._

Actually for a senior dev, it is too much to expect low-level work they
haven't used in 10 years. The analogy I quite often give is that you wouldn't
assess a French teacher on their Latin class from 2005.

The bottom line is that you probably asked a useless question that was great
for teaching the CS foundations in school, but that hasn't ever been used once
in their careers. People discard useless information, especially smart people
because they prize the efficiency that their memory can use in place of
useless information.

------
joncrocks
So you still do technical interviews, just long ones that require you to quit
your current job first.

No thanks.

This might work if you're looking to fill a pipeline with 'good enough' junior
people who you can then push into an appropriate role, rather than hiring for
something specific.

~~~
expertentipp
NEVER quit the job for another one where they just want to sniff you. Try to
learn how many people the company is hiring and how many positions long term
they want to sustain.

------
GuB-42
An actual test drive takes just a few minutes, an hour at most. The "test
drives" they suggest take 30 to 90 days... It is not a test, it is a job.

Their suggestion is essentially "you don't need to make sure you are hiring
the right people, because you can fix it later by firing them".

I think the flipside of this strategy is that you won't get the people who are
good at the job and good at interviews. Imagine I am offered a job where 90%
of people pass probation because of a thorough interview process vs one where
only 20% pass. If I pass the interview, other things being equal, it is easy
to guess the job I'll take. The 20% company won't even have a chance to "test"
me.

------
comstock
I knew a company a bit like this once. The CEO would hire people very quickly.
In most cases they didn’t have the appropriate skill set, and had personality
issues. They’d have a massive negative impact on the culture of this early
stage startup.

They’d then get fired. The CEO would say, it will be better for them in the
long term and I’m sure they’ll be happier. This wasn’t true, they had their
issues but actually the CEO has screwed them too by not doing the due
diligence and hiring too quickly...

Honestly the best solution I can think of is to work as a paid consultant for
the company and see how that goes. If the relationship seems to work, then
join full time. Not everybody has the time to take on consulting gigs though
which is a significant downside.

------
thepratt
This approach is so far from reality it hurts. What are you learning in 15
minutes that can inform you enough to make a decision to hire someone for a
minimum of 90 days? Not enough.

You're missing out on other aspects of hiring like recruiter fees. If I were
to hire every idiot that ticked off the boxes but couldn't demonstrate relate
knowledge to something tangible I would've put my current and previous company
out of business.

Your 90-day long interview process (this is what it is, face it) is not only a
financial detriment, but a productivity tumor. Yes, I do agree that the
current wide-spread use of "solve this on a whiteboard", "implement merge-
sort", or some other backwards method of technical ability does not work; that
is why I implement questions, and paired exercises that are tailored to the
position they will be filling and the background they're coming from. The
process I have in place consists of 3-parts: phone screen, and 2 in-person
interviews - this process normally doesn't extend past 3 hours. The interviews
are structured as a conversation to make sure the most nervous of interviewees
can perform comfortably. I'd rather waste 2 hours more per candidate opposed
to ~20-40k GBP for a poor trial, and a decrease in overall team velocity.

~~~
fnthawar2
Great points.

The 90-day interview (as you call it), is the same if we did 3 hours of
interviews (like you do) or 15 minutes. We didn't see a better accuracy as we
shrunk our interviews down from 3 hours to eventually 15 minutes.

I really like your _pairing idea_ espescially if that's close to the reality
of the actual job.

------
Paul_S
That is a real cruel process. You are taking advantage of your position as an
employer - are you at least honest with those people and tell them there's a
90% chance you will fire them in 90 days? Sure, it might be good for you as a
company but it's really bad for the 90% of people who quit their job to get
fired by you 90 days later because you can't be arsed to interview them. I
can't believe you want to be praised for this approach.

~~~
vlehto
If it's really 90% of the people who are left behind, it's probably not good
for the company really.

People in existing teams will be very fatigued from getting to know new people
and then trying to forget them. This is well documented in the military. After
a while veterans don't want to get to know the fresh reinforcements that
arrive into their unit, as the new guys will probably die quickly simply
because they are inexperienced and thrown to battlefield. As a result, any
investment in social relationship with them is wasted. And as a result, the
whole unit will get grumpy.

~~~
fnthawar2
Interesting points.

We never found smart effective folks who did not want to get to know newer
smart and effective folks.

~~~
vlehto
I'd guess there is something like 50% cutoff point.

Less than 50% of hires stay: "oh geez, more meat to the grinder."

More than 50% of hires stay: "A new guy came, do you play ping pong?"

But my cut off point might be way off. And there might be some elasticity
between those where people are more iffy about the whole deal.

I'd suggest testing this. Stack slightly not so promising new hires to one
team and more promising in other. Let's hope there is different retain rate.
Now you can measure the performance changes of both _teams_ and see the net
effect.

------
Tade0
For me one skill that stands out as a predictor for performance is the
person's ability to do code reviews.

Of course not all decent devs are particularly good at this [1], but from my
experience below average ones are consistently unable to find flaws in both
their own and someone else's code or even if they do they don't care enough to
point that out.

[1] Not saying I'm an especially decent dev, but although I manage, reviews
are hard for me because I'm way to lenient - I guess it boils down to trying
not to hurt other people's feelings.

EDIT: accidental _emphasis_

~~~
zimpenfish
> unable to find flaws in both their own

It would be an interesting interview where they put some of my own code from
github/bitbucket down and said "code review this, please". Especially if it
was reasonably old and I'd forgotten about it...

------
docdeek
"We interview people who fit the basic criteria, and for less than one hour
(sometimes 15 minutes!). If the person seems capable and there aren’t major
red flags, we hire them (we use an extremely coarse grained filter). If we
have five applicants, sometimes we’ll hire all five. They’re then on a 90 day
probationary period to see if they work out…”

Not sure how that would fly outside of the US. In France we have probationary
periods but I have never heard of a company hiring multiple people for a full
time role (CDI) and then laying off the ones that aren’t the best fit after a
couple of months. That sounds to me like a way to get in a bit of trouble -
legally, socially, with unions - in the employment context here.

Would be interested in learning whether there’s a French company that does
anything like this - maybe a half dozen CDD’s with the express commitment to
hire one of the six on a CDI after three months? But who is leaving a CDI on
that sort of bet?

~~~
superplussed
I'm an American living in Berlin, and I think the problem here would be more
of a cultural one than a legal one. Germans just have an expectation that once
hired they will be given every chance to succeed, to the point that firings
seem to come across as a shock or an implication of major wrong-doing.

"Hire fast, fire fast" is already ingrained in American startups, so I think
the policy outlined in this article would be easier to adopt in the US.
Americans in general view jobs as more transient than Europeans do.

~~~
mifreewil
I think you meant “hire slow, fire fast.” Never heard fast for both.

~~~
blumomo
That's what the article says that is being discussed. Probably you didn't read
it.

~~~
arkades
(1) the article put forward their approach as a novelty; OP claimed he’d never
heard such a thing (as being ingrained in American culture already.) These two
statements do not contradict one another.

(2) claiming people didn’t read the linked article is actually one of the few
things that’s explicitly called out in the HN guidelines as not being kosher.
Please don’t.

------
placebo
I'm delighted to see comments that show some people here actually get this.
While my conclusions are based only on my own experience, they have served me
well so far. In the dozens of interviews that I've conducted over the years,
not once did I need to resort to quizzes that do a fine job of showing how a
person can answer a quiz under pressure of an interview but not much beyond
that. Most of the important qualities I'm interested in concerning an
applicant have very little to do with this sort of ability. A decision based
on a chat which reveals more than any professional quiz ever could (if you
know how to listen) is usually a better one.

Not only do I refuse to ask candidates quizzes, but after getting enough
professional experience, I started refusing to answer them when I was looking
for new positions. One such case involved two executives that interviewed me
for a certain senior R&D position. The interview was going well when at a
certain point one of them asked if he could test me on some professional
stuff. I politely answered that while I respect their candidate filtering
methods, it doesn't fit my MO and that I'll pass on that. Not surprisingly, I
later received a negative reply from them. A couple of weeks passed and I was
hired for the same position by a much larger company (and with much better
compensation) that didn't insist on me standing next to a whiteboard to see if
I can pick up on some silly trick. About 3 months later, I received a call
from one of the executives in the company from which I received a negative
reply. Apparently they hired someone who had managed to pass their interview
tests with flying colours, but was terrible at his job and so they asked me
whether I would like to work for them (of course, this time with no tests). I
said I'll pass on that too.

I think the reason for the difficulty in finding the right people for the job
stems from a deeper problem of people having lost touch with their inner drive
and resorting to external means to understand what is good for them. It starts
in grade school and continues on from there. This is not a problem that can
(or should) go away quickly, but the more I see people at least being aware of
the issue, the more hopeful I am that a more sane process for people
fulfilling their potential will eventually replace the existing method.

~~~
zimpenfish
As someone who recently rejected a company who wanted a 2-3 hour test + 90
minute interview _after_ a 45 minute phone interview (which I did), this is
gratifying to read.

------
barrkel
I'm not a fan of technical interviews, at least not whiteboard ones, or asking
people trick questions, or algorithm analysis bingo.

I like to work through a problem. The problem is synthetic, unfortunately, but
anything actually relevant will give too much of a leg up to people who are
familiar with frameworks. Steps: (a) discuss the problem and come up with
potential solutions, and once we've agreed on a solution (b) turn the solution
into code in any language they want, as long as we can easily install it on
Ubuntu. An explicit non-goal is actually coming up with a solution to the
problem: it's great if they do come up with a solution, but far more important
is mind-melding on a problem and solution, and being able to convert agreed
solutions into working code.

The idea is to simulate work: I assume that everyone we interview has at least
basic ability to code (we use a Codility pre-check), so I create a scenario
where I'd be helping set up a team member to work on a functional piece of the
application. Communicate and ensure we have a shared understanding of the
problem, discuss a solution, and see them actually produce a solution.

Once we have a solution, I do want to know if they understand what the
performance characteristics are; that's a very practical concern, as the
company I work for deals with data batches ranging in 100 items to 10 million
items, so code should be written to scale linearly at worst.

------
venturis_voice
We've often found that employers want to see a willingness and ability to
learn and adapt to new challenges as opposed to a candidate having an
encyclopedic knowledge of coding languages etc. With a competent knowledge of
your market you can be taught the rest of your role but if you're unable to
articulate your goals and mission to non-technical people you'll often come
unstuck when trying to communicate what your doing to others.

This seems a lot more important in the hiring process for tech people now as
technology is usually the product or output of a company as opposed to being
shut up in a basement somewhere just helping a company operate.

We've just spoke to an internal IT recruiter about this and he's echoed a lot
of the sentiments put across in this thread. Links below if you wanna listen
:)

[http://www.venturi-group.com/podcast/internal-
recruitment/](http://www.venturi-group.com/podcast/internal-recruitment/)

------
cacrawford
I had a 3-month job search over the last summer, encompassing about 150
contacts which I filtered into roughly 25 actual interviews. It takes an
enormous amount of time to deal with all the various interview techniques out
there. Such as:

* Four or five-hour interviews. * Interview prep suggested by recruiters for tech interviews. * All-day work sessions pairing with employees. * "Homework" that can take anywhere from 5 hours to days. * Multiple online sessions, each to solve a tech riddle.

I can't imagine how I could've done this when holding a job at the same time.
I'd have to be incredibly picky about who I chose to interview with - which
means, I wouldn't have interviewed with my current company because they didn't
interest me during the screening, only until after the interview when I got to
talk with _actual developers_.

------
maltalex
This makes no sense to me.

Most candidates aren't unemployed; they're switching jobs. Leaving a job they
don't like, or looking for an upgrade. Many have to be persuaded to leave
their current employer.

If I were thinking about switching, I'd want a lot more commitment from my
future employer than "we'll hire you and four more guys for the same position,
then we'll see which one of you will last 90 days". Regardless of my
confidence in being able to do the job, who wants to compete for a job for 90
days? Interviews are horrible and stressful, but this is just replacing them
with what is essentially a 90 day interview for which you have you quit your
current job.

------
twic
This is a particularly bizarre article to come from someone who is ex-Pivotal,
given that Pivotal's interviews are all-day pair programming on real code
(mostly) rather than whiteboard nonsense, and don't suffer from the problems
described here. AFAIK, Farhan came in through Pivotal's acquisition of Xtreme
Labs, but I thought the point of Xtreme Labs was that they copied the Pivotal
way of doing things, including hiring.

Also:

> For example, let’s say that someone is working on our mobile client and it’s
> not going as quickly as we need it to go. We’ll

... work with them to identify and remove the impediments slowing them down,
while revising our plan to be more realistic?

> let them know that they need to speed up

This guy is an asshole.

------
throwaay3192321
Is it only me who can't think properly when constantly being prodded to by a
bunch of people ? I also feel that the game is so rigged that one doesn't have
any real option other than to be pretentious; to be the "model programmer" who
is "passionate" about whatever shit that the company is doing; to fit into the
"culture" of whatever flavor of WASP is running it. Frankly, SV bullshit
smells worse than Trump's hotel bed.

~~~
mikelevins
No, it's not only you who can't think when being prodded. I have similar
issues.

Actually, my issues are kind of entertaining when they don't get in the way of
my livelihood. My brain appears to prioritize processing interaction with
people, especially strangers, over some other kinds of activity, including the
kind that's needed to solve logic problems. Ask me to take some open-ended
time alone to write a solution to a problem, and I'll give you one when I'm
done. Ask me to do the same thing with people watching or, worse, interacting
with me as I do it, and you will get random results that may or may not bear
any relation to the problem.

It affects things other than coding. When she was a teenager, my daughter
sometimes engaged me in conversation when I was driving somewhere, just to see
where we would end up. I remember a particular instance of winding up in the
parking lot of a Safeway in Capitola, California, wondering why I was there,
while my daughter laughed her head off.

I've been at this programming thing for a long time now. I have a reasonable
idea of how good I am at it. Given the right circumstances and the right kinds
of problems, I can be (and have been) extremely productive. I've been
described by someone paying me as one of those "10X" programmers, and the dvcs
logs bore him out (but I know what he didn't: if the tools and goals and
problem space had been different, or if the work circumstances had been
different, then I wouldn't have been nearly as productive).

But technical interviews aren't going to reveal any of that, certainly not
about me, specifically. I'm always going to look like something between an
idiot and a mediocrity in the typical technical interview.

Various critics are complaining that the OP's methods aren't going to work,
but all the data we have says that current fashions in hiring already don't
work. The correlation between interview performance and job performance is
laughable. Companies all like to say they hire "the best"; what they really
mean is that they hire the best that currently-known methods can distinguish,
which is to say, a random selection of people. About the most you can say
about current methods is that they select for people who want a job, which I
suppose is better for hiring than pure sortition.

We don't know how to hire good people in technology. Popular hiring strategies
are voodoo. The only method that has been shown to produce much better results
than chance is blind, standardized skills-testing, which is not currently
popular.

Technical interviews are nonsense. The proper role of interviewing is to find
out whether the candidate seems to be a glaring asshole. If you want to select
for skills, administer standardized tests. If you don't want to do that, then
it doesn't matter much what you do. It all seems to be about equally useless.

You might try doing a Tarot card reading for the candidate.

------
piyush_soni
Yeah. No. I'd never like to interview with a company which just hires me (I
don't think I've any red flags) and then after 3 months tells me "Sorry, we
only had to hire 2, we hired 5, and though you're good, you're not as good as
Mr. X". I'd rather work at a place which has the intention of keeping me for a
long time.

------
funkythingss
"Tons of great people, and, disproportionately, women and minorities, can
perform less well at technical interviews but be great in role."

You lost all your credibility with one sentence. Congratulations.

~~~
Niksko
The data available shows that women and minorities ARE under represented in
the tech industry. Corellation does not imply causation, but if you have a
limited number of causal factors during the hiring process, the logical
conclusion is that parts of the hiring process contribute to this under
representation in significant ways.

Perhaps the focus is wrong. Perhaps it's not the 'technical' part of the
technical interview that causes this disparity. Perhaps it's just good ol'
fashioned racism or prejudices, and really the part of the technical interview
that causes a disproportionate number of white males to be hired is simply the
fact that the interviews happen with the interviewer fully cognizant of the
applicants race and gender. You'll notice that the article also mentioned
their disdain for being able to see the applicant.

To dismiss a fact that reasonably straightforwardly follows from empirical
evidence and limited options for causality is simply obstinancr.

~~~
funkythingss
Multiple problems with your argumentation:

1\. women and minorities are underrepresented. True. That does not imply there
is sexism. In reality, women have a 2:1 chance over men to get hired, just
because everyone is desperate to hire women. Be it to improve the image,
whatever. Source [http://news.cornell.edu/stories/2015/04/women-
preferred-21-o...](http://news.cornell.edu/stories/2015/04/women-
preferred-21-over-men-stem-faculty-positions)

2\. Norway (correct me if I'm wrong on the country) experimented with
genderless and faceless applications. The result: Men were actually favoured
over women in STEM. How can we explain that? It's certainly not sexism.

At the end of the day, it comes down to this: it is very controversial to say
men and women chose differently, but they do. And there's nothing wrong with
that! Isn't that what early feminists fought for? Were is the "sexism" in
plumbing, oil rigs, and other less desirable jobs? There are virtually only
men on those jobs. Tells you what these "diversity" people really are:
jealous.

EDIT: Grammar

~~~
danielhooper
Sexism isn't real. Men actually have it twice as hard as women, because
companies hire women just to make them look good. Here's a link to one source
that proves this forever.

Norway hired men more often than women with genderless applications. Science
cannot explain this, just like the tides of the ocean, or magnets.

At the end of the day, people fighting for equal representation are just
jealous, and they can't accept that their Y chromosome made them not want to
work on an oil rig.

~~~
funkythingss
well, I wish I could be that direct sometimes :D

------
leowoo91
Technical interviews are just a form of an expensive filter that works for big
companies and should be considered as a warmup.

------
expertentipp
Women, minorities?! At this point even those "privileged" (male, qualified,
experienced) have problem getting hired. The technical recruitment has become
perpetuum-mobile of job postings, assignments, countless audio and video
calls, technical teasing. Sometimes I'm wondering - is there any actual hiring
happening? I have impression there are people in companies who are literally
getting paid for creating recruitment noise and infinite "hiring".

