
The Technical Interview Rift - DonPellegrino
https://blog.techmasters.chat/the-technical-interview-rift-cf5d4cf6d2c#.yi5qfn705
======
kafkaesq
Some useful advice, but something about the overall tone seems a bit off:

 _You are a manager and it’s time to hire a new developer to join your
impressive team of A+ players._

That's where things started to go of course. You're _not_ an "A+ player", and
most of your team aren't "A+ players" either. You're just human beings doing
the best you can and (hopefully) trying to improve a bit each day -- like
anybody else.

No one wants to work with losers. But any (serious) talk of of "We're all A+
players here!" or "I know how to spot A+ players!" is just motivational kool-
aid, and ultimately a distraction from the real work you have to do --
including the task of finding the best people you can hire, and who are
willing to throw their lot with your cause.

Especially when it's quite often the people hired for their seeming "A+"
qualities (which they are able to exude in spades) who turn out to be the most
toxic, morale-killing members of your (once) impressive team.

~~~
jasode
_> , but something about the overall tone seems a bit off: [...] You're not an
"A+ player", and most of your team aren't "A+ players" either._

I believe you misinterpreted the author's backhanded "compliment" about teams'
_self-proclaimed_ _" impressive A+ players"_. His tone is sarcasm if you
combine it with the repeated fixation on "Fibonacci" puzzles in the rest of
the essay:

\- _quote: , what possible insight does questions like “solve a Fibonacci
sequence” + whiteboard + no internet give you to know about a person fit for a
development role?_

\- _Go Beyond Fibonacci Pen /Paper Tests to Assess Candidates_

\- _If you get Fibonacci’ed in your next job interview, perhaps you should
look elsewhere? If you are the one doing the Fibonacci’ing, you are doing it
wrong._

(In other words, if your team bombards candidates with Fibonacci, you of
course will think your company consists of A+ players!)

His "tone" might have tripped the obvious sarcasm detector more readily if he
wrote it to say: _" it's time to hire a new developer to join your impressive
Project Euler hackathon champions. blah blah blah"_

~~~
soVeryTired
But he also says "After all, the primary purpose of doing technical interviews
is to ensure A+ players are identified and are persuaded to join your team. If
your process is preventing this, then you are doing it wrong."

That doesn't sound like sarcasm to me...

~~~
jasode
It may not be _in that particular sentence_ since he's directing that "A+"
label towards the _candidates_. (He's being genuinely charitable towards the
job seekers.) However, when he's directing the "A+" label towards the
_interviewing team_ , it comes across as a backhanded swipe.

Perhaps calling it "sarcasm" is too strong since his sarcasm is _very subtle_.
If you integrate his _entire_ essay about _" Technical Interview Rift"_, he
essentially wants to lecture the "too cool for school" dev teams that pride
themselves on Fibonacci puzzles, etc. However, he can't go into full-frontal
sarcasm mode like Stephen Colbert / John Stewart because he doesn't want to
make the very audience he's trying to reach _tune out_ from his message.

Therefore, he has to dance around his intended message in such a way as to not
insult his target. There's probably a better word to describe what he's trying
to accomplish but I couldn't think of it so I called his passive-aggressive
tone: "sarcasm".

------
lisper
I think Triplebyte has the right idea: essentially a take-home test conducted
over a period of a couple of days. It allows a candidate to show off what they
_can_ do under realistic conditions, instead of allowing an interviewer to
poke at what they can't do under highly unrealistic high-pressure conditions.
A typical tech interview is more like a spelling bee than a realistic test of
a candidate's abilities: if you happen to get a word/question you know, you
look awesome. If you don't, you don't. (Not long ago I screwed up a tech
interview because I couldn't remember/figure-out-on-the-spot the iteration
condition for estimating square roots by the Newton-Raphson method, and I was
not willing to cheat by looking it up on Wikipedia while I was on the phone.
Their loss.)

I just wish Triplebyte would expand their outreach beyond YC companies.

~~~
Pyxl101
I have tried using take-home tests before. The level of plagiarism was
astonishing. And that's just the plagiarism I could detect.

Even with a problem that's unique to my organization, I don't know how I could
trust that the actual candidate themselves was the one who completed it, and
that they completed it without unfair assistance (e.g. from other people).
Similarly, I have a habit of looking over someone's resume and picking a few
random technologies they mentioned to discuss. I'm surprised how often
candidates claim experience with a technology and can't really describe what
they've done with it or discuss it intelligently. The level of dishonesty is
high.

For all of the downsides of interview-based hiring, at least I know what I'm
getting (modulo error bars on assessment efficacy).

> I couldn't remember/figure-out-on-the-spot the iteration condition for
> estimating square roots by the Newton-Raphson method, and I was not willing
> to cheat by looking it up on Wikipedia while I was on the phone

I don't ask the kind of questions that require obscure knowledge. I just ask
questions that you can problem-solve with regular rational thinking, with
questions that usually admit a "naive" brute-force style solution that can be
improved upon. If you did want to look up some algorithm that would be fine
with me, but I am more impressed by a quick and confident reasoning through
the problem followed by a fluid implementation of the naive solution, than I
am of sophisticated solutions with better algorithmic performance or accuracy.

~~~
matwood
We give take home problems and have no issue with plagiarism. In fact we
actively say use the internet, books, etc..., and we still get solutions that
are wrong or do not even compile.

The ones that do come back and look good, give us a starting point for the
interview. If the person did just copy it from somewhere else they have will
have a hard time talking about the solution and various pros/cons.

~~~
jghn
This is how we do things as well. When I walk around our office I always see
people looking at SO, Google and others. Why would I hold a candidate to a
different standard?

------
blantonl
I view technical interviews that require algorithm solving and coding on a
whiteboard as ridiculous. Primarily, because I am _deathly afraid_ of them.

And here is why. I own and operate two online businesses in the Radio
Communications space that are the de-facto standards for our industry. I've
coded both of them from the ground up in PHP/MySQL and manage all the day to
day administration of these sites. Our infrastructure is deployed on 20+
servers on AWS, Google Cloud, and some bare metal deployments, for which I
manage solely by myself. We have 100's of TB of audio archive storage that is
all developed and managed by myself. I've personally tackled the entire stack
from the ground up, end to end. I've hired an outside consultant, _once_ , to
do graphic design work. I've taught myself titanium accelerator and released a
highly successful mobile app for my business for Android and iOS. I've even
deployed much of our API using NodeJS! Gasp! I do all security, SEO, sysadmin,
scheduling, upgrades, marketing etc.

But I'm not a computer scientist. If you asked me to outline a best-case
sorting algorithm for x use case my response would be "uhhh... " If you asked
me to write out a for loop in PHP on a whiteboard I'd say to myself "uh...
where do the semicolons go again?" But I can piece together building blocks
from AWS, Stack Overflow, open source projects, multiple SAAS providers. I can
also write contracts, executive license agreements with third-parties, develop
highly successful and consumable APIs, and manage the financials for a multi-
million dollar business. I've also deployed multiple APIs in SOAP, XML, and
JSON which form the most successful parts of my business

But get me up in front of a technical interview team where the startup is
looking for a computer scientist and I'll have a ton of "yea, but..." and
probably wouldn't last too long.

So when I see these examples of technical interviews in organizations where I
_know_ I could add value, but realize their process for evaluating that value
could certainly eliminate me very early, that scares the crap out of me.
Fortunately, my business has been successful enough that this will never be a
scenario I have to face. It still bothers me though.

~~~
jdmichal
You're argument is exactly what I call the difference between a "trade
programmer" and a "computer scientist". You are describing the former, while
all the Google-copycat interviews with algorithms and data structures are
designed to hire the latter.

As you said, trade programmers typically glue together existing components and
frameworks. Sometimes, this is really all that's necessary, as you have proven
with your businesses. Computer scientists are qualified to create those
underlying systems in the first place, properly weighing and selecting the
algorithms and data structures to meet constraints.

I don't mean any of this to cast a negative light on trade programmers. They
are 80-90% what a business needs, and I think there should be better
opportunities for people to become such without the 4-year degree. [0]
However, the limitations also need to be understood, and in my opinion a
business is best served with a smaller set of computer scientists to provide
technical guidance. Otherwise, you will see a lot of history-repeating-itself
type of bad decisions.

[0] This is basically the hole that bootcamps have attempted to fill. They
could also be filled with associates degrees or apprenticeships.

~~~
jghn
I think your percentages are too low. IMO it's more like 95-97% of businesses
are 99-100% served by what you describe as a trade programmer.

The problem is that it seems that 90+% of shops think they're 0% served by
trade programmers.

~~~
jdmichal
Sure; 87.3% of all statistics are made up on the spot anyway. [0] It will also
vary greatly depending on your business scale. Google needs computer
scientists; at their scale any efficiency slip is very costly. For the local
small business looking to turn their Excel spreadsheet sitting on a shared
network drive into a CRUD app, a trade programmer or two is probably entirely
sufficient.

[0] Yes, you heard me right! 91.4% of all statistics are made up at the very
moment!

------
jakewins
> These are ways to gauge if they know the langue without making them write
> code. You should never ask a developer to write anything from scratch, or
> write anything.

But.. _why_? You are hiring someone to write code, what better way to gauge
their ability to do so than a work sample?

Obviously you don't drill someone on sorting algorithms, unless that's what
you are hiring them for, but make them solve a simple task that is on the
level of abstraction and in the domain your company deals with.

Having sat through interviews where candidates who had made it through
screenings and talked the technical talk turned out to be unable to write
actual code to solve rudimentary domain problems, there's no way I'm hiring a
developer without programming with them first.

~~~
luhn
The argument I usually hear is that many people don't do well under pressure
or with others looking on. So by doing coding tests or whiteboard tests or
whatever, you're selecting for people who do well in high-pressure situations,
rather than people who are talented coders.

But I agree with you. I've interviewed many people who have an impressive
resume and can talk the talk, yet can't even do Fizzbuzz.

~~~
lj3
> I've interviewed many people who have an impressive resume and can talk the
> talk, yet can't even do Fizzbuzz.

And I've interviewed many people who can do fizzbuzz because they studied for
it (CTCI) and wind up being terrible programmers.

The end result? Technical interviews are, at best, a completely random hiring
signal. You'd be better off flipping a coin. It's better to be lucky than
good, so why not use luck as a selection criteria?

~~~
jakewins
But, if you aren't hiring a developer specifically to implement fizzbuzz for
you, why are you giving them that as a problem to solve?

Hiring someone to work on a Flask REST API? Make them add a REST endpoint to a
little flask app. Hiring someone to do CSS? Make them style a form. Hiring
someone to build a database? Make them safely write to disk.

This is far from random - it's been almost twenty years since Schmidt and
Hunter showed that a work sample is one of the best predictors of future
performance, 24%, vs 3% for unstructured interviewing.

[http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...](http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf)

~~~
lj3
I couldn't agree more. The problem with most work sample tests is the length
and the format. Most are too long and they have you start with nothing. Adding
a rest endpoint to a little flask app is perfect.

It's a shame nobody actually does this kind of work sample test. And thanks
for that study. It'll make for some nice ammunition. :)

------
AvenueIngres
Here is my take on hiring: an active Git repository with a decent amount of
non-trivial code/projects generally gets applicants I have to evaluate to skip
the whiteboard interview and instead grab lunch or coffee with me. We then
discuss technology/software engineering. I find this approach to have yielded
much more conclusive results, though it probably would not "scale" well. You
can quickly tell whether someone is passionate and resourceful by talking with
them, occasionally erring on research-ish stuff but always focusing on the
implementation rather than the theory.

Plus I sometimes stumble on the occasional gem that is _very_ knowledgeable
and from whom I can learn.

Whiteboard interviews, coding challenges, take-home projects. All of those
things are so time-consuming for both the company, the interviewer and, of
course, the applicant. And all of that just in the hope that the company will
accept them... maybe? Of course when nothing else is available then it is the
usual drill: phone, skype, on-site 1, on-site 2. But if other signals are
available then to the trash it goes.

~~~
mancerayder
If you start with github repositories for your candidates, aren't you
filtering out people who do things other than work? Most of us work 40 to 60
hours a week, and sign paperwork that says that any code we write belongs to
the company. But now we need to work Saturday and Sunday on open source
projects so we're worthy of sharing a coffee with a hiring manager?

~~~
sqeaky
> says that any code we write belongs to the company.

I have turned down several jobs when they tried to hit me with that clause. I
have negotiated a better clause that gave them the work I made for them, which
just happens to line up with state law here

> But now we need to work Saturday and Sunday on open source projects so we're
> worthy of sharing a coffee with a hiring manager?

I wouldn't want to hire someone who didn't enjoy coding enough that they
didn't have something on publicly visible repo.

~~~
lj3
> I wouldn't want to hire someone who didn't enjoy coding enough that they
> didn't have something on publicly visible repo.

Why? Those people sound like terrible employees. Those are the people who come
into work to punch the clock and get paid while saving their energy and
creativity for their side projects, which is what they'd really rather be
working on.

~~~
jghn
Most of my coding output for my job ends up on a public github repo, which is
the best of both worlds.

~~~
lj3
That would be nice. Are you a library or framework developer?

~~~
jghn
I work for a nonprofit. The downside is the pay isn't as great as it could be
elsewhere. The upside is that the work is meaningful and I get to write OSS as
part of my day job.

------
sssilver
This is what I don't understand. During technical interviews, why don't we
just give the potential employee a laptop and ask them to solve the problem as
they would during a regular work day? Why can't they search Stack Overflow,
and perhaps reach out to a friend or even a random person on IRC for advice?
Isn't this how the real life works? They may not know anything about min
heaps, but perhaps a 15 minute research will help them solve the problem
better than anyone who actually memorized Cracking the Software Interview by
heart? Isn't it better to measure discipline and ability to learn and solve
problems instead of measuring existing knowledge?

------
svachalek
From a Silicon Valley perspective, I didn't even know that this was something
that companies considered not doing. 'Round here, a technical interview is
guaranteed, it's more a question of if/when there will be anything else
involved in the interview. Also, will it be a mundane technical interview, or
more like 6+ hours doing Top-Coder style questions on a whiteboard? It used to
be only Microsoft and Google were known for that but now it's practically
everyone as far as I can tell.

~~~
abecedarius
Re: your last sentence, it's been common in my experience for at least the
last couple of decades: that is, interviews for most of a working day,
including at least one each focused on coding and design. Maybe my experience
is unusual, but there were both big companies and startups.

------
arcanus
> All in all, would do again, except not more than 1 a month because flying
> across a continent and back for 1.5 days is gruelling.

This is part of the problem. Aside from college graduates, who has time to fly
around the country burning vacation time to _maybe_ get an offer?

~~~
cbanek
On the other hand, would you really accept an offer without having at least
met the people you'd have to work with? Especially if you have to move across
the country?

~~~
psyc
Video chat is good enough for me. I don't need to know about their posture or
how long their legs are.

~~~
cbanek
This might just be me, but video chat doesn't really do it. You don't get an
idea of the building, bathrooms, cafeteria, and the general idea of how often
your coworkers bathe.

All of these can be pretty important to my general mental health.

~~~
bdavisx
Yes, and they could easily hide a noisy, chaotic work environment in a video
chat as well.

------
crispyambulance
I am glad to see managers that give interviewing the level attention it
deserves.

Many interviewers just assume they know how to interview people to find the
so-called "A player" (yeah, we're up to A+ now too). People love the idea of
magic gotcha questions the answer of which determines whether a person is or
is-not skilled some specific area. But the reality is most orgs are barely
sophisticated enough to manage FIZZBUZZ-level screening, let alone screening
for "A players." Proven interview techniques that take practice, training and
coordination like the Behavioral Interview are often skipped in favor of ad-
hoc, unprepared interviews that end up with a go/no-go vote.

------
amorphid
When I worked as a technical recruiter, I found that a great way to screen
candidates was to explain the "box" I was trying to put them in. I described
the work I'd done to research the position, why I was screening for certain
criteria, and that ultimately I wanted to get their approval on the summary I
had written about them. Being non-technical, this worked better for positions
I was experienced recruiting for of course.

For example, when recruiting a web developer, I'd start by asking a hiring
manager what they wanted.

"Get me a full stack Rails developer who knows OO Javascript."

Then I'd just drill into why they asked for that until I didn' have manh
questions. I'd be able to describe roughly what projects needed attention, how
the tech stack helped solve that problem, and ask the candidate to help me
sell them as someone who can do that. It wasn't perfect, but it worked better
than most recruiting attempts I've experienced so far.

Now as a developer with a few years of experience, I feel I have no idea what
I am doing, and am winging it at all times :)

------
pklausler
OP: "There is a slight proclivity to conduct technical interviews within the
companies that comprise the community."

The companies _constitute_ the community. The community _comprises_ the
companies.

~~~
tdumitrescu
"In addition to its original senses, dating from the 15th century, “to
include” and “to consist of ” ( The United States of America comprises 50
states), comprise has had since the late 18th century the meaning “to form or
constitute” ( Fifty states comprise the United States of America)."
[http://www.dictionary.com/browse/comprise](http://www.dictionary.com/browse/comprise)

~~~
pklausler
This is like legitimatizing incorrect usage of "literally" or "unique" because
some people don't know their definitions. It is ambiguous and sloppy to misuse
a word as if it means its antonym.

