
People suck at technical interviews (2014) - sgift
http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews
======
PuffinBlue
There needs to be a bit of a shift in understanding what 'category' of worker
a programmer 'is', both by companies and more importantly by (some)
individuals themselves.

Programming is both technical and artistic. It's a creative endeavour that
relies on technical skill to complete.

The best analogy to another profession would be to those in the 'technical
arts', those like photography, joinery, painting, sculpture, drafting, perhaps
writing too.

It seems at the moment that companies are approaching programmers as if they
are purely technical like an actuary or bookkeeper and are seeking to quantify
artistic skill through interview tests. This is rubbing off on some
programmers who begin to think of themselves in these terms.

I don't recall a single instance as a photographer where I had to quantify my
technical skill, but there were hundreds of times I had to based on my
artistic skill, proving I had already made a vast range of photographs with
sufficient quality to 'prove' my ability and by extension proving my technical
ability.

Crucially, it was the fact I had a portfolio that allowed me to prove my
ability, both artistically and technically.

I see a similar need in programming. I think programmers should create their
portfolios of personal or paid for projects that showcase their technical and
artistic skill and companies should take those seriously.

At the moment it seems that far to many programmers are attempting to get jobs
without a 'portfolio' which is why, in an creative endeavour like programming,
companies that hire are trying to quantify and determine a new hires ability
with these seemingly bullshit tests.

There's room for improvement in this argument and there are outliers, but I
think the basic premise is sound.

~~~
gregmac
Except that the vast majority of programmers essentially say "I'm very good at
taking pictures, but I can't actually show you any of them because they're all
property of my previous employers, and I never take pictures just for myself".

> I think programmers should create their portfolios of personal or paid for
> projects that showcase their technical and artistic skill and companies
> should take those seriously.

100% agree, and Github in particular is great for this. Sadly, in my
experience very, very few candidates have such a thing. Even non-code content
such as issues they've filed or stackoverflow questions and answers is a very
useful way to judge someone's technical abilities, but many candidates don't
provide links and either use separate identities/aliases or don't participate.

~~~
bobwaycott
I imagine the vast majority of employers would be pretty pissed if the vast
majority of programmers shared their private code, and some might even wish to
take legal action. As an employer interviewing and hiring candidates, one
should respect and expect this confidentiality to be exhibited and adhered to.

For example, I build things for clients that are proprietary to their
businesses. Some things are publicly accessible, like marketing pages, but the
real stuff is locked behind employee-only auth. Other things run entirely on
internal networks, and can't be accessed from the web. They would be rightly
upset if they discovered I shared their code with a third party, or placed it
on Github.

Moreover, just because Github exists, doesn't mean programmers should feel
obligated to "participate". Outside of developers who maintain or participate
in truly used projects, it's mostly noise. The only exception I can agree on
is looking at issues a candidate has reported to gauge their depth of
understanding, clarity of communication, offering of solutions, and other such
valuable insights.

------
skrebbel
In all honesty, I'm not sure the author did a lot of interviewing. For
example,

> _The famous fizzbuzz test simply asks "are you aware of the modulo
> operator?"_

Wait, what? No, it asks "can you write a for loop without breaking a sweat?".
There's a rightfully vivid debate going on about the virtue of asking
algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd
wager that virtually all programmers iterate a collection at least once daily.

The followup sentence drives it home for me:

> _Yet people will spend twenty minutes on it in an interview, a huge waste of
> limited time._

Well, if it takes an applicant twenty minutes to Fizzbuzz, you're done! Just
saved everybody lots of time.

I used to think Fizzbuzz was insulting and bullshit until I started
interviewing. I haven't yet met a programmer who couldn't solve a Fizzbuzz-
level question, but I've met many who took over 10 minutes and made little
logical errors. It's a great predictor for "can this person actually program,
well, at all?".

~~~
dfabulich
>> The famous fizzbuzz test simply asks "are you aware of the modulo
operator?"

> Wait, what? No, it asks "can you write a for loop without breaking a
> sweat?".

There are notorious cases where senior engineers with years of actual honest
coding experience "fail" fizzbuzz. IMO, That happens in two ways:

1) Not knowing (forgotten?) what a modulus operator is, and trying to code one
up from scratch with a for loop. This can totally happen when you spend a few
years working on line-of-business CRUD apps that never turn out to need
modulus arithmetic.

Coding modulus from scratch with just + - / * is a fun little challenge in its
own right, but it'll probably take you longer than 10 minutes to write it
correctly and solve fizzbuzz with it.

That means you just took more than 10 minutes on fizzbuzz, which means you
failed.

2) Trying to "clean up" the solution.
[http://c2.com/cgi/wiki?FizzBuzzTest](http://c2.com/cgi/wiki?FizzBuzzTest) has
a good discussion on 'Why Fizz-Buzz is "hard:"', which points out that many of
the most obvious solutions have code duplication, which some people then try
to eliminate, tying themselves in knots trying to make it perfect.

The third possibility, that a candidate with years of experience shipping code
nonetheless struggles to write a for loop, is IMO just not as common as the
above two failure cases. (Much more likely is that the candidate has
lied/exaggerated on their resume.)

~~~
benhoyt
If you don't know about modulus, you don't have to re-implement it. For
Fizzbuzz you're looping anyway, so you can just maintain two counters, one
that counts to 3 and resets, and one that counts to 5 and resets. When one of
the counters resets, you know the main loop counter is a multiple of 3 or 5.
Like so:

    
    
        def fizzbuzz_no_modulo():
            counter_three = 1
            counter_five = 1
            for i in range(1, 101):
                output = []
                if counter_three == 3:
                    output.append('Fizz')
                    counter_three = 0
                if counter_five == 5:
                    output.append('Buzz')
                    counter_five = 0
                if not output:
                    output.append(str(i))
                print(''.join(output))
                counter_three += 1
                counter_five += 1

~~~
squeaky-clean
There's a lot of ways you can do it. I think it's fun to see how people solve
it when they're not allowed to use the obvious answers (note: I don't
interview people and probably would not choose no-modulo-fizzbuzz as an
interview question).

Similar to your solution, instead of two counters, you can have two iterators
that cycle every 3 / 5 elements, and add them. Then fill in any blank elements
with their index+1.

    
    
        from itertools import cycle, zip_longest, islice
        
        fizz_list = ['', '', 'fizz']
        buzz_list = ['', '', '', '', 'buzz']
        output = [
            fizz + buzz for fizz, buzz
            in islice(zip_longest(cycle(fizz_list), cycle(buzz_list)), 0, 100)
        ]
        for i in range(len(output)):
            print(output[i] or i+1)

------
hanginghyena
Hiring Manager Perspective: Everyone lies, sorry.

As a candidate, I hate technical interviews. For the reasons above. As the
poor schmuck asked to make the hiring decision, however, I've learned that I
can't live without them.

My technical isn't complicated. A very basic SQL assignment (delivered to an
audience which claims to know SQL) that is followed by a few broader database
design / data process QA questions. Entire assignment is 100% job relevant (in
fact, my SVP asked for a copy of the report it generates when he saw the
problem on my whiteboard). I don't care about the details of syntax.

I do care, however, about candidates who produce SQL code which looks like the
bastard love child of LISP and Java. About candidates who claim to know a
skill but literally cannot write even basic syntax on the whiteboard. Who put
"certificates" from Oracle on their bloody resume and break down under super
gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?)
yet, never mind 5 years of claimed SQL experience at a big company on their
resume.

The coding question is most definitely not an exercise in sadism. We validated
it with several new hires who were confirmed to be "good at SQL". Average
completion time: 2 minutes, generally with trolling about why do we waste our
time with easy stuff.

That being said, my rejection rate from a basic coding interview is at least
50%, grading liberally and generally supported by several members of my team
shaking their head about a candidate.

I've tried screening resumes, I've tried doing non-coding phone screens. IT
DOESN'T WORK. Actually, all it does is eliminate the socially challenged and
non-communicative (who actually tend to pass the whiteboard test) in favor of
the liars.

And don't get me started about Python. Lest I bring up the Google-Motorola "I
LUV Python _heart_ _heart_ _heart_ " guy who didn't understand the difference
between a list & dict.

~~~
MrLeftHand
Potential Employee Perspective: they can't be serious!!!

A lot of times a job spec contains a minimum of 10-15 skill you need to know.
And that's just the modest one.

Maybe employers should stop trying to find the non-existing 'developer rock-
star' and people would stop lying.

The funny thing is that even the developers themselves start to behave like
that when they are on the other end of the hiring (Been there, done that).

"never mind 5 years of claimed SQL experience at a big company" \- you can
easily have that without touching JOIN.

Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and
you're not allowed to change anything.

The crap you can get into and stuck in it when working with legacy stuff is
crazy. And you can end up working with something for years without having the
liberty to experience and grow.

That's the sad truth about software development. Well one of them at least.

~~~
arethuza
5 years of SQL experience and no idea of what a join is?

Isn't that like saying 5 years of C/Java/C#/... experience and not knowing
what assignment is?

~~~
MrLeftHand
I don't thinks so. You don't have to use join, but you might end up with loads
of queries instead of having just one, but the end result will be the same set
of data.

~~~
pjmorris
Arguably that's one year of SQL experience repeated five times.

~~~
dllthomas
Or one week of SQL experience repeated 250 times...

~~~
pedrosorio
One day?

~~~
dllthomas
Arguably.

------
gavanwoolery
As someone who is going through many technical interviews right now, and
failing all of them, I love this article. (It was actually brought to my
attention last week.)

My technical ability is readily apparent to those who have viewed my work, and
by virtue of those who have praised it. I don't claim to be the best
programmer in the world, just a competent one. I've also been programming for
over 20 years, that might have something to do with it.

However, I suck at interviews, in any way shape or form (personality tests,
technical tests, you name it). Yet I've aced every job ever given to me, and
people love to work with me (even in spite of my salty attitude).

To think that you can determine what it is like to work with me over the span
of a year within the span of an hour is completely and utterly ridiculous.

As it turns out, the little sub-problems they give are the most trivial part
of programming. The hard part, the part it takes many years to get any good
at, is coherently organizing, documenting, and ensuring the stability of a
larger system, particularly concurrently with other programmers. Or designing
an algorithm that you can't just Google. Or making a really tough decision
about what features to cut or what direction to pivot. Or organizing a vision
of what will add the most value for the customer. Or...etc

Being an introvert with a monotone voice, general lack of expression, and
deadpan sarcastic humor does wonders for personality tests. Most people's
default reaction to me (in interviews or otherwise) is that I am a total dick.
Which I am, but the kind you don't mind hanging around.

I don't do well with programming that has a one hour deadline. But give me a
day and I can produce the typical output a programmer would within a day.

If I spent all my time practicing for interviews, I'd probably be better at
them (with stuff like Top Coder or Interview Cake or whatever). And I think
giving these things a whirl is well worth it (not for the sake of winning in
interviews). But it is not my life goal to be good at interviews. It is my
goal to work in areas I am interested, and continue learning things that are
directly relevant to my real-world tasks (sorry, writing a red-black tree on a
white board within an hour never happens to me in the real world).

~~~
ktRolster
_But it is not my life goal to be good at interviews. It is my goal to work in
areas I am interested, and continue learning things that are directly relevant
to my real-world tasks_

You have to look at the programming career as requiring two skills: the first
is programming, and the second is finding a job. That might suck, but it's the
nature of a career where you change jobs every three years or so.

~~~
gavanwoolery
Oh, I agree with you, you are totally right. I am mostly speaking from a
hypothetical "I wish the world did not operate this way" type of tone. :)

------
MrLeftHand
With one of many job applications I did, I received a small coding exercise
before getting to the actual interview.

It was about writing a small application in perl (one of my favorite scripting
languages) to solve a problem. It was a number converter from arabic to roman
and vice versa.

Anyway I started by looking up a perl module that solved the whole thing in
3-4 lines of code.

What was the answer? Sorry that's not we wanted. We would like to see, how you
would solve it with general code.

So you're saying that doing investigation work, finding an existing working
solution and applying that solution is not a good answer for you?

Sorry but that's how I work. I find a problem; I investigate for a solution;
if there is one I use it and implement it; if not then I will write one.

The moral of the story is: interviewing is fundamentally wrong and doesn't
help you find a good candidate. There are millions of good solutions to one
problem in programming. Asking for a solution you want to see and not a
solution that solves the problem will never help. Then why don't you clone
yourself and have an army of developers which work the same way and produce
the same code with the same flaws over and over and over.

~~~
Scarblac
I disagree. You need to be able to find existing working solutions and use
them, sure.

But you also need to be able to do this kind of thing yourself if you can't
find an existing solution, because that also happens all the time. It's that
ability that they were testing. That's perfectly valid.

They should however have told you that before the test.

~~~
Ma8ee
> They should however have told you that before the test.

He should have been able to figure that out before the test. It was a test of
his problem solving abilities, not his Google-fu.

~~~
Scarblac
He did solve the problem.

~~~
Ma8ee
Only in the most literal sense. The developer who thinks that their job only
consists of translating very precise literal instructions to another set of
precise instructions will very soon be out of work. That is a thing that is
easy to automate. The developer's value lays in being able to translate vague
and very context dependent instructions to precise instructions. This guy
clearly failed at this.

------
itaysk
Interviewing is hard.. I always hated the idea of judging someone based on a 1
hour chat (I was always the tech interviewer or first screen). I also hate
that interviewers aim to challenge the candidate with hard technical questions
that they might have or might have not had experience with.

So what I do is ask the candidate to tell me about their experience, past
projects, and also frankly ask them "what are you most comfortable talking
about" and continue diving from here. When they talk about a topic they claim
to be experienced with, you can really see what they worth. When someone can't
fluently discuss something his claims to be knowledgeable in (yes that
happened), that's a bad sign.

------
ktRolster
When I interview, I try to find out what the person is good at. Everyone who
comes to interview is good at _something_ (even if it's just good at getting
interviews).

Sometimes their skill-set overlaps with what we need, sometimes it doesn't.
But the focus is figuring out what they are good at, rather than an abstract
test.

~~~
yardie
Are you hiring? I've had a pretty miserable week of interviewing. Either I'm
not the right fit or the potential employer is less than ideal.

~~~
ktRolster
Right now I'm looking for a job, not hiring haha. The table is always
spinning.

------
cmrdporcupine
That companies now insist on running the Google-style whiteboard-algorithms-
coding-skill-testing-question type of interview tells me that there is no
shortage of programmers to hire.

Because as far as I understand it we use that process at Google because we can
afford a lot of false negatives because we are inundated with a lot of
resumes.

Smaller companies and startups surely are not, and finding candidates must be
harder. Unless the job market is saturated with candidates.

Many perfectly good, maybe even excellent, candidates will just falter and
fail in a whiteboard coding interview. I do, and many people I've interviewed
have. Coding on the spot using pen and paper sucks. I think by coding. Give me
Emacs and a REPL, and let me go away and think for a bit, and I'll produce
something way better.

Smaller companies should think twice before trying to emulate Google,
Facebook, Microsoft, etc. In a small company social cohesion is very
important, so rapport and personality are very important, cultural factors are
important, experience in dealing with similar types of environments,
familiarity with technical stack.

That's how I used to interview before coming to Google, anyways. It seems like
the industry has turned in very large part to this hostile "prove yourself"
methodology...

~~~
machogeek
I would gather if companies like the ones you mentioned adopted new ways of
interviewing, or at least randomized it in way that it couldn't be easily
cloned, other companies would follow suit or adopt their own style. The
challenge is that every companies wants the "best" engineers and believes they
deserve it... So in their minds, they do what they think the "best" do.

I have heard more than a handful of CTO's and companies sling this expression
around as if using this phrase put them in company with the likes of Elen
Musk. It's a joke to me really. I look forward to the day one of these guys
says, hey, lets be original.

Contrary to your point, I believe there is a shortage of qualified
programmers... or at least senior ones that can solve hard problems
independently. Smaller companies need devs that can solve problems
independently, with minimal oversight. Copying Google and Facebook is what
they think the path is to get there.

~~~
pyb
If there was really a shortage of qualified programmers, companies would be
working to improve their interview practices.

From this thread, and my own experience, things are going the opposite way.
Companies appear to be able to afford to use more and more arbitrary filters.
Which indicates an excess supply of great candidates!

------
whack
Every time I read one of these articles, the author invariably ends up
recommending solutions that have glaring holes, just as large as the ones he
spends the entire time attacking.

In this case, the author begins the entire essay by telling us that we
shouldn't hire on the basis of what someone already knows. One of his first
solutions later presented is the exact opposite of this: find out about their
level of existing knowledge, regarding specific technologies and frameworks.

He then goes on to rile against "team fit," because of its potential for bias.
But his entire solution basically comes down to behavioral interviews, which
are notorious for how bias-prone they are.

His solution basically tells us that we shouldn't consider fancy degrees or
companies. And yet, in the span of 30-60 minutes, we should be able to form
accurate judgement on how much talent and drive someone has, and what they
will be able to do in the next 3 years? Sorry, but unless you're the Steve
Jobs of character reading, there's no way you can do the above accurately.
Everyone lies on interviews. They pad their accomplishments, and inflate what
they have previously done. The only thing you achieve through such a
discussion, is figuring out how good a talker someone is.

The following article sums up everything that is wrong with almost every
"Hiring is Broken" critique ever. Every single approach people have ever
thought up, is broken in so many ways, as ably demonstrated by many others.
Unless someone has hard data to show why one technique's pros outweigh its
cons, such discussions are almost always pointless.

[http://www.thecaucus.net/#/content/caucus/tech_blog/684](http://www.thecaucus.net/#/content/caucus/tech_blog/684)

------
pklausler
Over the years and across 100's of technical interviews, I've found that I get
the best results from asking smaller numbers of easier problem-solving-with-
code questions that require the candidate to demonstrate basic skills. I'm the
guy who makes sure that the candidate can clearly get over a low bar.

I do this because the candidate pool is swimming with people with great-
looking degrees and long resumes and fine references who can talk all day long
about computer programming but who simply cannot program a digital computer.

So I ask a 5-minute easy warm-up question and then a 40-minute harder problem.
I pace things slowly and give them all the time that they need. I happily
answer any questions they may have about the problems, which can all be stated
clearly in short sentences. I do not care what programming language they use
or whether their syntax would compile or how descriptive their variable names
are.

Essentially, I'm trying to not generate a "false negative" result. If you
can't do my easy stuff, I really don't want to work with you. If you're a
great candidate, you'll have fun with this and take it away in interesting
directions.

(Sample easy question: Given two closed intervals [a,b] and [c,d], determine
whether they overlap.)

------
soham
[Disclaimer: I run
[http://Interviewkickstart.com](http://Interviewkickstart.com), which helps
candidates suck less at technical interviewing.]

I have conducted countless technical interviews in my lifetime. I agree with
the author; it's very difficult to actually become a good interviewer. The
skill to judge someone's life and career of several years in 30 to 60 minutes
is not something that comes easily. Alas, it's all too assumed to be easy.

When you start, for quite some interviews, you are very likely on either
extreme viz. either too strict or too lenient. It takes a while to calibrate
your standard, and not give in to an extreme. And that too, only if you
introspect, or when someone draws your attention to your interview results.

Many companies don't have a culture which values interviewing as a skill.
Rarely if so, I come across a company which has a process of shadowing and
reverse-shadowing in an interview, which they take seriously. It is viewed as
a cost center, when it's actually a profit-center when done right. And due to
my business, I have come across plenty of them. At least in the valley.

------
WaxProlix
Oh man, I thought they were on to me, but no, it's for the givers of technical
interviews. Phew.

~~~
gavanwoolery
I chuckled :)

------
up_and_up
My optimal hiring process:

1\. Screen resumes...throw out anything that seems bogus, hype-y etc. Time
investment: 1-3 mins per resume.

2\. Phone screen...ask them simple technical and project questions directly
from their resume. They wrote it so they should know it. Generally,
bullshitters are exposed right away. Time investment: 20-30 mins

3\. Take home project. A somewhat simple but non-trivial project like: Write
an autocomplete search script using a large text document as your dictionary.
This will test their understanding of algos and software engineering best
practices. Time investment: 10 mins to review the code

4\. They talk with 3-4 other engineers. Those engineers now have a simple
project to compare candidates and to question the candidate with. "Why did you
choose this algo?", "How did you break down this problem?". Each engineer can
ask whatever they want. Time investment: 30 mins.

5\. Final engineering huddle. Compare candidates, pros and cons. Gut feelings.
Etc. Time investment: 30 mins.

The small take home project is extremely revealing and more useful IMO. You
get to see their actual ability at coding a small feature. Is it well-
composed? Did they include tests? Do I want to maintain his/her code?

The project also spares the rest of the team from wasting time interviewing
non-serious candidates.

~~~
runchberries
> Time investment: 10 mins to review the code

This is what really irks me about take home exercises. The candidate spends
2-4 hours (or 12 and say they did it in 2) and the interviewer has no real
commitment to reading and understanding it. 10 minutes to review the code? I
would expect a video call where we go over the code together.

All interviewing I do, I do while talking to them and give them ample time to
explain it back to me.

The candidate is investing their time. You should have enough respect to
invest your time too.

~~~
up_and_up
> This is what really irks me about take home exercises.

The project is simple. In 10 mins I can easily review the project. Are there
tests? Is it well-composed? Does it run? Really doesnt take long for a simple
project. Since every candidate gets the same project it is pretty easy to
determine a good solution from a bad one.

> I would expect a video call where we go over the code together.

Thats what the next step is for.

------
l1feh4ck
> Don't hire for a fancy degree.

There are some companied coming to my college for hiring. The first criteria
they put was 70% aggregate marks (60% for some companies).

I have seen people who doesn’t know how to write even a small program getting
hired, while people with good programming skills are not even eligible to
attend the interview.

Going through 200-300 candidates in an interview might be a tedious job, I am
not sure. What other choice do they have?

~~~
MrLeftHand
Had a coworker from a university, didn't even know how to write a while loop.

He didn't last long to say the least.

Of course we will never know, if he could have been a good programmer or not,
but it was baffling to see people fresh out of uni with zero knowledge.

------
DeBraid
The whole hiring process is a nightmare for both parties.

Two things I've learned about hiring / interviews: it's both very difficult
and imprecise.

Process is more like dating than laboratory science; a race to establish
rapport (a combination of comfort and trust). To get hired you must
sufficiently possess an arbitrary blend of credentials and testing/interview
performance.

Whatever it takes to make the hiring manager comfortable and trusting. Some
want 10x-ers only, are soothed by strong technical chops/coding test
performance, others select for culture and ability to learn. YMMV as selection
criteria based on job description, sector, company stage, weather/etc.

This is why personal referrals are so powerful: trust is established MUCH
faster, other flaws will be overlooked.

------
lambdabit
The problem with his interviews is that it's even more easily gamed. It
doesn't really take a genius to go through their employment history and
memorize blurbs that show learning technologies, applying it successfully
while being humble and nice for one day.

~~~
vonmoltke
If an interview like that can be gamed by "memorizing blurbs" then it wasn't
done correctly. A properly conducted interview will see the interviewer
tugging at threads to go deeper. At some point they will crack because
memorization won't be enough. Unless of course they are anpathological liar,
but those are rare enough that I would ignore the posssibility at the
interview stage.

~~~
lambdabit
You're right, I exaggerated but I don't think this is a hard game. People
spend several months right now on studying interviews. The topics are wide and
scope enormous, hence so many complaints; some companies test you on
languages, others on algorithms, data structures, dynamic programming, bit
manipulations, SQL queries, scalability, unix internals, I could go on and on.
On the other hand, there's only so many paths these past history conversations
can go, and you know where they can poke at.

------
seanwilson
Some people are just bad at giving interviews. If someone is so bad at
interviewing they will eliminate a candidate because they slipped up a little
with a programming teaser, they're still going to be bad at interviewing if
they try another technique.

I'm completely happy doing programming puzzles in interviews myself as I've
worked with people that claim to be experts in something when they aren't and
some people exaggerate to the point of lying on CVs. As long as you don't
penalise a candidate too much for not getting perfect answers I don't see the
issue.

------
ChemicalWarfare
My fav way of interviewing and being interviewed is a quick assignment
(nothing major like some companies want you to build an api, crud UI to drive
it and then push it out to heroku for them to look at) - either at home or
just leave the candidate alone in the conf room for an hour.

After that if they pass - few questions about their code, maybe drill down
into some areas depending on the answers etc.

Alternatively, if someone has a project on their github profile using the tech
you're looking for - few questions about that project can typically give you a
go/no-go right away.

------
skay_
A lot of people are saying that technical interviews are not good because some
people are not good at them but they are indeed good software developers.

Other people are saying that is impossible to judge someone in a few hours of
technical interviews/exercises.

I agree with both, but what's a better alternative? How to you minimise the
risk of taking hiring a bad developer? At least, it is my belief that the
technical interviews minimise the risk which is far better that ending up
hiring someone who is not technically strong.

~~~
Clubber
What I do is ask them about previous projects. 1. What was your favorite
project and why? Explain. 2. What was your least favorite project and why?
Explain.

I can get a good idea of the person through those two simple questions. I
throw a few simple technical questions like: What is a primary key? What is a
foreign key? What is inheritance? What's the difference between a function and
a procedure (Delphi days). Questions that anyone should be able to answer just
by writing code.

------
tn13
I think the problem is not whether you can design a 100% awesome tech
interview process that will have high precision and recall. That is known.
Spend enough time with the person basically to judge him rather than asking
few questions to taking him to whiteboard.

But then most companies wont be able to show profits if the start spending
that much resources on each candidate. Hence they optimize their processes
only for precision and not for recall. That explains why a lot of people fail
first few times.

------
liquidise
I had actually written a post a few months back[1] that bares a remarkable
similarity to this one. It's encouraging to see others have, and are, coming
to similar conclusions. Remember that each person who learns these methods now
improves a round of interviews in the future.

1: [https://blog.benroux.me/4-steps-to-making-your-interview-
suc...](https://blog.benroux.me/4-steps-to-making-your-interview-suck-less/)

------
mknocker
Too often, the team fit is put aside and you end up with people who does not
play well with others in your team. Technical interview can be ok but I would
not put too much details into it. I have been in technical interviews where
people were asking questions about obscure API calls and they were expecting
applicants to come up with questions that were not relevant to the job.

------
freek4iphone
I totally agree with most of the points Laurie made, specially I hate the new
trend of asking people for an online coding test before even talking to a
person. I have worked on a ton of complex problems in life and in real world
you never have to write 4 complex tree traversal algorithms using the best
possible approach in under 60 minutes, never!

------
crikli
Someone in a similar HN thread once recommended the book "Hiring With Your
Head" and then sorta did a mic drop.

I must do the same. Buy the book and implement it. It directly deals with so
many issues mentioned here (great dev but crap at silly tests, great dev but a
bad interviewer, etc).

------
probinso
so I seem to be alone in this.

although whiteboarding is not representative of Industry workflow, I feel that
it can be used as a metric for communication. everybody knows that it's
coming, and everybody knows how to practice it. if you perform poorly on
whiteboarding that means you didn't practice it. it's a learned skill it's not
a natural thing.

anybody I've met who complains about having trouble in whiteboarding has also
never seriously practiced it.

------
DrNuke
Apart of job-related questions and general-thinking problems, tech interviews
are still mostly a poor Tinder experience.

------
cloudjacker
lol I had to do the fizzbuzz test a few weeks ago

the modulo operator was obvious to me and after the interviewer kept adding
conditions to the problem, they then asked me why I didn't concatenate strings
instead of my approach of returning the string in each conditional statement

so fellow engineers, without having the telepathic skills I possessed that
allowed me to know exactly what traits the interviewers were looking for,
would you have:

a) erased your entire correct solution to write a more efficient solution, not
knowing the time constraints for this problem

b) created the most efficient and scalable fizzbuzz solution known to man at
the beginning? in the 15 minutes provided

c) laughed in the interviewer's faces since it was obvious the question was
irrelevant to how you would solve problems for the company on a day to day
basis?

d) other

------
bbcbasic
I want this guy to interview me. Even if there is no job. I'm sure I'd feel a
million dollars by going through the process.

