
I will not do a tech interview - ikeellis
https://medium.com/lessons-learned/80ba19c55883
======
crazygringo
Granted, there are a lot of bad tech interviews out there (asking about
algorithms that nobody ever uses) ... but I do not understand this.

Imagine someone's being hired for a front-end position, and we don't have
months to get them up to speed.

I'm going to ask them to explain how a closure works. How they deal with AJAX.
What they think about "!important". Things to be careful about with floats.
How CSS precedence/specificity works. Give them an example webapp idea, and
ask how they might architect it.

None of these are gotchas. All of them are directly applicable to the work
they'll be doing. If you can't explain how closures work, then either you
don't understand them (so you shouldn't be hired except for a very junior
position), or you're bad at communicating/explaining (which, on teams, can be
equally bad).

The author says "Other times I just froze on topics that I know very well."
Maybe somebody can explain this better to me -- but if you freeze up in
interviews, are you also going to freeze up in developer meetings? During code
reviews? When you're in the room with clients?

If you freeze up in interviews, then it doesn't seem like the problem is with
interviews -- the problem is with you freezing up, isn't it? I mean, if you
can't answer basic questions about your knowledge in a one-on-one
conversation, then that's a real problem, and not just in interviewing.
(Obviously, some overly aggressive or unfriendly interviewers can be off-
putting, but I'm just talking about "normal" friendly interviewers.)

~~~
untog
_Maybe somebody can explain this better to me -- but if you freeze up in
interviews, are you also going to freeze up in developer meetings? During code
reviews? When you 're in the room with clients?_

Of course not. Interview situations are very, very different than the others.
Meetings and code reviews are with co-workers, whom you know and trust.
Meetings with clients could be nerve-wracking for other reasons, but they're
unlikely to challenge your depth of coding knowledge.

For my own personal example, I once interviewed at a place where the
interviewer wrote up some HTML on a whiteboard, and then asked me to write out
the CSS next to it that would turn it into a horizontal drop down menu.

I don't work that way. I sit with my editor in one screen and a browser window
in the other, and I piece together the layout as I go along. I assure you, it
works just fine. But the interview situation was so far divorced from any
every-day working situation that it felt very unnatural.

I opted out of returning for the second round of interviews. The next place I
interviewed I sat down, in front of a computer, with the interviewer, and we
talked through code as I wrote it. I took the job.

~~~
tmoertel
Can I offer you some advice? _An interview is a negotiation._ The rules aren't
fixed. If you're asked to do something that won't give a reliable measurement
of your ability, say so and offer the interviewer a better option. You'll
probably get what you want.

In the scenario you described, I might try something like this: "I think I see
what you're trying to measure by asking that question, but it assumes a
working style that is foreign to me. So that you can get a better reading of
what I can really do, would you mind if we used my laptop, with you looking
over my shoulder, as I solved a problem of similar difficulty?"

 _An interview is a negotiation._ If you want to change it, just ask. Most
interviewers will be happy to agree to any changes that will help them get a
better read on your true abilities.

~~~
clavalle
It may be a negotiation but it is a very asymmetrical one. That by itself
might be the root cause of a lot of the anxiety.

~~~
tmoertel
True. But it's not nearly so asymmetrical as most people seem to believe. Most
interviewers aren't great at interviewing and know it. They're usually open –
surprisingly open – to changes that will help them conduct a more reliable
interview.

~~~
HeyLaughingBoy
Upvoted for this remark.

If I'm interviewing you, it means that we already think you are worth talking
to. I don't want to waste either my time or yours. If what I'm asking you to
do makes you uncomfortable, TELL ME! I can think of the last two people I
interviewed who gave me a series of immediate "I don't know..." answers to a
bunch of questions. They're happily (I hope!) working here now because we
changed the interviews to go down productive paths to find out what they _do_
know instead of beating our heads against a wall!

------
chollida1
> I politely suggest that a short contract job might be the best option for a
> company to evaluate a senior developer

I like the twist of doing the contract off site on the developers own time.

Every time I see someone on hacker news saying, "we've solved the interview
problem. We just require every new hire to give up their old job and contract
with us for a week to see if they are a good fit", I often wonder about the
quality of the people they hire as I have yet to run into a talented dev who
would quit their current job to do this one week contract for hire option.

Doing contract work via take home seems like a nice balance here as even
people with kids have 2-3 hours free after kids go to bed. Done over a few
nights in a week makes much more sense.

~~~
ig1
It would also breach the work contract of many developers. Most work contracts
tend to (1) prohibit you from taking on other paid work (2) claim copyright of
the work you do while under employment (which is why the FSF & Apache
foundation require employer waivers from contributors).

~~~
rohansingh
Do you have a source for this claim? None of my contracts in the US have ever
had something like this. It's in fact illegal in most jurisdictions, including
California.

~~~
SomeCallMeTim
>It's in fact illegal in most jurisdictions, including California.

IANAL, but AFAIK it's absolutely not illegal in California; what's illegal is
preventing you from working for a competitor AFTER you quit.

I've never had a salary employment contract in California that DIDN'T say they
owned everything I did in my off time, at least if I was working on something
in a similar domain. The best contracts explicitly state that I can get an
exemption, or that I can work on unrelated projects, but all have the clause.

If it's illegal, a lot of companies are breaking the law.

~~~
fizx
The interpretation is complicated, but its neither black or white. Also, its
standard in asymmetric contracts (EULAs, employment, rentals) for the drafting
side to completely overreach.

RTFM here:

[http://www.leginfo.ca.gov/cgi-
bin/displaycode?section=lab&gr...](http://www.leginfo.ca.gov/cgi-
bin/displaycode?section=lab&group=02001-03000&file=2870-2872)

~~~
SomeCallMeTim
>.... except for those inventions that ... [r]elate at the time of conception
or reduction to practice of the invention to the employer's business, or
actual or demonstrably anticipated research or development of the employer

Seems pretty clear on the "similar business" front. IIRC that's been the
wording in many if not most of the contracts I signed while I was still
working as an employee in CA.

I've mostly worked in games, too, and so that pretty much meant "no game dev
in my free time," period. A strong motivator to go indie/consulting.

------
lambdasquirrel
I'd go so far to say that most interviews do not seem to serve much purpose
other than to boost the interviewer's egos. The more that a company is full of
engineers who feel trapped in their jobs or lives, the more that this seems to
be the case.

The other irritating thing is that people seem to prefer selecting people who
are technically more intelligent than they are, but who are less socially apt
that they are. It's so bad that I think entrepreneurs need to think about
protecting their employees from themselves, because this cannot possibly be
good for companies in the long run.

Lets just face it. Engineers often times have low self-esteem (especially
compared with "business types")(edit: myself including), and interviews
frequently become the one place where they can be on top. It's always re-posed
as some "meritocratic" test of skill (isn't it always?), and it's anything
but, because an interview setting is not effective at measuring whether
someone has the initiative and creativity to get a job done.

~~~
fennecfoxen
I read things like this and I just wonder... Who are these people talking on
the Internet, and what universe do they actually occupy?

Because they have some decent points about how the interviews they've been in
have been flubbed by the people conducting the interview, but they seem
ENTIRELY inconsistent with my experience at any place I've interviewed ever,
and I don't think it's my experience any time I've conducted an interview
either.

Maybe I'm just not working in the wrong part of the industry? I mean, I think
I've gotten some variety in interviewing, like: Silicon Valley - a small-to-
medium networking software startup, and a small social media startup. Seattle
- Amazon. NYC - Bloomberg, a tiny mobile-software company, and a medium-size
very-late-stage media startup.

... and they all have about the same in-person technical-interview processes,
which is to say, a little bit of talking mixed with a series of exercises
like: here's a toy question, go solve it for us. I say "okay, here's what I'm
thinking, X Y and Z, this what you mean? do you care whether it's built more
like this or more like that?" _start throwing some code on a whiteboard, etc
etc_

~~~
lambdasquirrel
I'd rather let the thread die down a bit before I respond.

I think I hold the record for bad interviews amongst my friends when I was
asked to write my traditional Chinese name on the whiteboard. I'm not going to
pull any punches here. I've simply lost faith in the interview process, and in
the way we vet each other, and the way that we manage and communicate with
each other, and I think that a core root of it is how we approach the
interview process. The valley was supposed to be a collegiate and egalitarian
environment, and I hope we keep it that way.

------
16s
Lot's of very skilled people interview poorly. Nervousness, social stress,
anxiety etc. So don't feel bad, people who interview applicants a lot know
this. It's not a mark against you. If they are interested in you, they'll find
a way to learn if you have the knowledge/skills they require for the job.

If I don't know the answer to a question or if it is ambiguious, I tell them.
For example, I was once asked to describe how a TCP sessions ends. Well,
that's implementation defined. What OS? Are we talking FIN ACKs or do TCP
resets count as ending a session too? The RFC may say this, but in the real-
world, software sometimes does it like that. Etc, etc.

And, many times the questions aren't made to be answered, but to draw things
out of you (like the one above). And in these cases, you can turn the
questions back on them. Put them on the answering end ;) and that's OK, those
exchanges tell both sides a lot about the other.

I do like a few black and white questions. Like, "How many bits are in an IPv4
address" or "What data structure is a C++ set typically implemented in" and if
candidates have no idea on an answer, then I do have concern over that.
However, if they do not know the answer, but understand types and their sizes
and data structures and their pros/cons, then that's good enough in some cases
as well.

~~~
mikevm
> So don't feel bad, people who interview applicants a lot know this.

They do, and they will count it against you. (A few people in this thread have
actually said this)

~~~
Bartweiss
In addition to the people overtly saying this makes you a no-hire, it's almost
impossible not to use this even if you try. Someone smooth and mistake-less
will make a better impression on you, and like with most fallacies, you're
left flying blind on how much to adjust your expectations to counteract it.

------
edw519
Ike, I understand your reasoning and admire the stand you've taken, but please
don't do this. You're hurting yourself and the rest of us, too. Let me
explain...

I may be one of the most contrary programmers here on HN when it comes to this
subject. I have never shared code or given references before a job offer and I
never will. I believe that reviewing code that's already been written has far
too much risk for any benefit; permissions may be required, explanations are
often needed (but never given the opportunity), and most of all, taken out of
context. I _want_ a prospective employer to do their own work to evaluate me,
one on one, without depending on other code or others' opinions. I will do
whatever it takes to help them do this, including interviews, meetings, and
yes, coding for them.

As an interviewer, I have used many tools to get to know the interviewee, but
the coding exercise has alway been, by far, the most important. If you can
code, great. If you can't, I'll find out. If you struggle, no problem, we'll
work through it. But I have to know, otherwise we can't move on.

The trial project is a great idea, but for many reasons, it's not an option
for many employers.

Do whatever it takes to get past the roadblock of not being able to do a tech
interview. There are plenty of resources to do that. If you struggle and your
interviewer is a jerk, then no problem: you didn't want to work there anyway.
If you struggle and your interviewer helps both of you to solve the problem,
then you've both learned a lot about each other.

(Also, please try to avoid language like "I will not...". Except for murder
and ethical issues, this will probably hurt more than it will help.)

~~~
Ologn
> I have never shared code or given references before a job offer and I never
> will.

Yes, I think our concerns are different than the OP's.

A scenario that has played out for me is that I get an e-mail or call from a
headhunter. They want to send my resume to a company. The company likes my
resume so I get an interview. Right away they want three (or sometimes more)
references. Often they say they prefer, or even require, that they be
managers. Obviously this means I have to contact my former managers and co-
workers. I have to make sure I still have current contact info for them for
one thing. I also want to give them a heads-up that someone might be calling
them for a reference.

Perhaps I'm not asking for a big favor but I'm still asking for a favor. So
every time I go on a job interview, I have to ask several people I know for a
favor. Some of whom I might not have had much contact with in the subsequent
years. Then I have to contact them out of the blue and ask them if they can
give me a reference (I usually do keep in contact with people, but don't want
every other contact being me asking for a reference or a favor).

Like you, I think it's understandable if the company is about to offer me the
job and as a last step want to get some references. But I have people telling
me they want to talk to my former managers before I've even had an in-person
interview.

Compared with this, someone grilling me on data structures, or paging, or
TCP/IP behavior, or whatever is pretty minor.

------
misiti3780
I have passed a bunch of job interviews in the past - but I feel the exact
same away and hire this way these days. I really do not see the point of
brainteasers or white board coding questions if you have a budget where you
can just pay out a contract like this.

Also, I believe there was an article posted here a few weeks back that
indicated Google's brainteasers did not lead to quality candidates - I know I
am cherry picking something that supports my beliefs but it was here
nonetheless.

Also, I have interviewed a lot of people with 4.0 BS/MS in 5 years that turned
out to be horrible employees. They were awesome with the brain teaser
questions but sucked when they actually had to build something.

I guess I do not see how you can lose if you take the contract-to-hire
approach ..

~~~
300bps
_I guess I do not see how you can lose if you take the contract-to-hire
approach_

I agree with most of what you said, but one way you can lose if you insist on
contract-to-hire is that you are filtering out a portion of the highest
quality candidates who are only interested in immediate full time hiring.

~~~
tocomment
I don't think many candidates are interested in "immediate" hiring. Most
people I know need to take extra time to wait for other offers to come in.

It also gives the candidate a way to see what kind of problems he'd be working
with, and the quality of the code-base, working conditions, etc.

I think it's a win-win.

~~~
btilly
Many candidates with current jobs that they would like to leave are only
interested in immediate hiring. They do not have the luxury to take several
days off of their existing job for a tiny contract which might or might not
land them a job that they might or might not prove to want.

One size definitely does not fit all here.

------
Peroni
Given the plethora of comments, this will likely get buried but I'll weigh in
regardless as those who suffer from the anxiety issues the author mentioned
will likely scroll through most of the comments.

Every issue the author mentioned can and should be mitigated by a decent
internal recruiter or manager. Essentially whoever initiates the contact with
the developer maintains a responsibility to ensure that their 'candidate' is
as comfortable as possible throughout the process, regardless of who they are
meeting.

I've dealt with plenty of people who suffered from the exact issues the author
describes. It's a lot more common than you'd realise. I've also dealt with
rare occasions where I've helped candidates with autism, aspergers and even
down syndrome through the interview process.

If you form a decent rapport with your candidate and truly comprehend what
they really want from a job with your company as well as 'grok' their
personality type and limitations then there really is no excuse for dumping
them into a situation where they feel so stressed and under pressure that they
shut down.

Your responsibility doesn't end with the candidate though. It's equally
important to ensure that the people who will be interviewing this person after
you have a decent understanding of the type of person they are about to meet
and to ensure they are equipped to deal with a situation where the person
being interviewed begins to crumble.

As for references to previous submissions and comments where people claim to
have "solved the interview problem", I call bullshit. Every company, every
hiring manager, every team, every job and every candidate is different. The
silver bullet to 'solve' the problem simply doesn't exist and never will. Sure
there are companies with fantastic processes but for every 'perfect process'
you show me, I can show ten companies where that process simply wouldn't work.

The best thing about these discussions is that it encourages people and
companies to simply try harder and that's never a bad thing.

~~~
kinofcain
Unfortunately I think people who take the type of care you outline above are
in the minority of recruiters/hiring managers. I don't know what the solution
is, having been on both sides a number of times.

What I worry about most isn't that the contemporary coding interview creates
false negatives. What I worry about is I suspect that it unevenly creates
false negatives.

------
donretag
Not quite the same, but I once had a no name company (getglue) tell me that I
need to do a 3-hour programming assignment before I can interview with them. I
have too much self-respect for myself to put myself through that process. I
declined the "opportunity" to interview with them.

The interview process is broken and many of the interviewing techniques either
do not correctly judge a candidate, or place too much burden on them. I guess
the reasoning is that a false negative is better than a false positive.

~~~
geebee
Good decision. I regret very much that I didn't make the same decision you
did.

I did a 5-7 hour programming homework assignment, didn't hear back for weeks,
and then it was just from a recruiter (sorry, we've decided not to continue
the process).

I won't do it again, ever. It's not the wasted time that I regret so much. I
do agree with you that there is a self-respect element to this.

------
jkresner
I agree feverishly with you post.

I've been a dev for 10 years and worked in Sydney, London, New York & San
Francisco. What I noticed is that San Francisco has a very different
"technical" interview approach that is very CS focused. I studied a CS degree
(7 years ago) and think it's stupid that I have to dig into knowledge that I
have not needed professionally over my whole career.

I've built successful startups, coded mamoth apps used by millions of people,
but failed interviews at companies like Yammer.

I wrote a post about how I conduct technical interviews for my company
airpair.

[http://hackerpreneurialism.com/post/43661666180/how-i-
conduc...](http://hackerpreneurialism.com/post/43661666180/how-i-conduct-
technical-interviews)

Pair Programming is KEY.

Also, side plug we've been getting lots of business both around preparing for
interviews and helping to interview candidates when you don't have in-house
knowledge to vet skills you don't have.

Here are some examples:

[http://airpa.ir/1d5sqR6](http://airpa.ir/1d5sqR6) (Need help reviewing
candidates code)

[http://airpa.ir/1dteU8H](http://airpa.ir/1dteU8H) (Need help interviewing an
iOS candiate)

[http://airpa.ir/173ily2](http://airpa.ir/173ily2) (Needed help preparing for
JavaScript interview)

------
mkramlich
The traditional recruiting/hiring pipeline in the software industry is clearly
non-ideal. The current tradition favors superstitious meta indicators & ritual
over realism, it often features under-qualified or too-young interviewers
asking/doing stupid/irrelevant things, it favors unpaid unilaterally-imposed
work and bureaucratic hoop-jumping (and mindless paperwork and not-work-
related personal snooping), over professionally compensated mutual
reciprocity, and, to make it even worse, it's biased to reaching _false_
rejections (because they are so afraid of regrettable hires).

Let's do the opposite of all these things!

I've recently started writing down an attempt at providing a better
replacement I hope to begin following and enforcing 100% without exception
going forward. My own system has similarities to what the OA advocated. I call
mine RYR, which stands for "Realistic, Yes-Finding and Reciprocal."

~~~
desireco42
What you wrote above, I am signing it. I couldn't said it better.

On one hand, you are valuable developer, they went through a lot of trouble to
find you. What you are faced in the interview is often far from ideal. I did
ran into exceptions, but it is still more a standard then exception to
encounter what you eloquently described.

------
michaelwww
The interview process doesn't work for some because it's a gross power
imbalance where the interviewee has no control. The interviewee suffers at the
whims of the interviewer. Some interviewers enjoy their temporary power over
people who are normally not in a position of no power. The interviewee has no
recourse for whatever power trip the interviewer throws at him. Many
programmers hate not being in control and get anxious at the prospect. The
process is doubly hard for introverts, who may be brilliant in the quiet time
when alone, but who fail miserably when suddenly put in a position of an
extrovert selling themselves. It's unnatural and upsetting.

I feel this is different than in almost all social interactions, such as
working with clients or participating in meetings. There is more equality and
control in those kind of negotiations.

------
TeeWEE
Well, I need to interview candidates because I need to know if they are up for
the job when systems breaks. If a table query fails because it needs a btree
index due to range searches, I want the candidate to know how a btree index
works and why it fixes the issue. Also If somebody cant tell me the difference
between http udp and tcp, its a no hire for me.

So for me, I really want to interview somebody before he can work with me.

~~~
jnbiche
Can you not understand that there might be people who can complete your task
easily, yet who have extreme anxiety about interviews? I actually understand
this issue -- I've been trying to switch careers into programming for the past
year. I've know several languages well (Python, JavaScript, some C), can use
git, and have a few decently impressive projects on my Github profile. I also
contribute to a pretty well-known open source project. As a result, it's not
hard for me to get an interview. Nonetheless, I've discovered that despite
being very good at interviewing in my prior (well, still current) career, I
completely freeze when I interview for programming jobs. Programming
interviews seem incredibly confrontational compared to my current profession.
Interviewers seem to be out to trick you at something, or else to prove how
much smarter they are than you. So I predictably freeze in these types of
situations, to the point where I blank on things that I can usually do, even
under pressure. It's been a big shock for me, since I did very well in school
and went over a decade without "failing" an interview (i.e., taking an
interview and not getting an offer) before attempting to transition into
programming.

But I love programming languages and software development, so I do contracts
from time to time, which always go well. Unfortunately, I've not yet done a
contract that was actually for a company that was actively hiring employees
(most were for small businesses with no full-time developers). But this post
has given me some hope. If there are companies willing to let a candidate work
on short-term contracts to prove their worth, that means there's hope for me
yet to be able to move into software development full-time.

~~~
VladRussian2
>Programming interviews seem incredibly confrontational compared to my current
profession. Interviewers seem to be out to trick you at something, or else to
prove how much smarter they are than you.

well, welcome to software engineering. The interviews are for the reason, they
let you peek into your future job. If you can't manage that environment for 4
hours of the interviews, how you're expecting to manage it for many years
if/when you get into software engineering?

I'm not trying to be mean, i'm just warning that something like having a fresh
out-of-college arrogant Millenial reviewing your code means - well suffice it
to say that at my previous job it drove 6 out of 8 person team in 1 year, all
from mid to senior engineers, me being 7th, to either change the team (3) or
leave the company (4). The guy is a pest, smart, driven, high GPA from top
University...

~~~
lfuller
I realize that it can be hard to understand without having experienced
interview anxiety yourself, but it is an _entirely_ different environment.

I suffer from interview anxiety to the same extent as the author of this blog
post. Though I am a very skilled developer, I completely freeze in these
situations (I even failed a fizz buzz test once). This doesn't translate to
difficulty with on-the-job stressful situations however, as my anxiety is only
present in interviews.

Most of the anxiety stems from me running through negative thoughts in my head
("I'd REALLY like this job - I'd better not screw up.", "I did poorly on my
last interview. I'll probably do poorly this time", "The interviewer can
probably see that I'm anxious.", "Does my voice sound shaky?", etc.) to the
point where they trigger a fight-or-flight response.

~~~
VladRussian2
>I realize that it can be hard to understand without having experienced
interview anxiety yourself, but it is an entirely different environment.

my point isn't about denying interview anxiety existence (i suffer from it
myself), and it has solid science foundation - speed of dopamine removal once
your system is flushed with it. Some people have it faster, some slower. The
former ones are great performers in acute short-term stress, while the latter
ones are better at long/deep concentration on a task.

My point is about interview situation being preview to a lot [not all, yet a
lot and many of them will be key ones] of future situations.

~~~
lfuller
I understand where you're coming from, but I disagree that this is a matter of
individuals' responses to stress in general. I know that in my case there is
nothing else I have ever experienced that can trigger a stress response
equivalent or even similar to what I experience during an interview. It is
irrational, but it is entirely separate to anything I could experience through
professional work. It is not the questions being asked during the interview
that cause anxiety, it is the interview itself. I actually find that I work
quite well under high-stress and high-stakes work environments.

~~~
VladRussian2
from your descriptions it sounds pretty much like my situation.

>I actually find that I work quite well under high-stress and high-stakes work
environments

not getting the stress and being able to manage it is 2 different things.
Couple jobs ago we had real clients with real problems, and it happened pretty
naturally that i became the top "firefighter" that is brought in when support,
escalated support, services/solutions, related development, etc.. exhausted
their options and various executives on both sides are having sparks out their
tailpipes - one may call this a high-stress and high-stakes environment, yet i
just wasn't getting any stress, to me it was a simple 2 step algorithm : 1.
forward me your AWR report (and this is instructions on getting it) 2. this is
your root cause, config changes, emergency patch, etc... Simple, familiar, no
stress (which i can't manage as i just get paralized/stuporred by it, like, in
particular, in many interview situations)

------
tomelders
I walked into an interview once, expecting to go over my work which I'd
brought along with me, much of it for the company I was interviewing for, so I
wrongly assumed the interview was just a formality. They asked a couple of
basic questions then opened a laptop, and BOOM! technical interview right out
of no where.

I blanked. They just handed me the laptop and didn't even tell me it was a
test. There were some comments at the top of a few javascript files and like
an idiot I answered the questions verbally. The two devs just sat their
smirking at each other like they'd won at something.

I'm not averse to tech interviews, but I do not enjoy the "look at how smart
we are that we caught you out" attitude that comes with them. I'm shit at
crosswords, that doesn't make me illiterate.

I've since been keeping an eye on their work and now I get to feel smug
because it's been universally panned.

I also had to sit a test for what I call "the worst agency in the world" (AKQA
and after 7 hellish months there I'm happy to stand by and put my name to that
assessment, they're simply awful). I forgot to specify the radix in a call to
parseInt. It was the only flaw and while they didn't make a big deal out of
it, the interviewer was clearly pleased with himself for finding it. They then
proceeded to ask ZERO questions about why I'd coded the test the way I had.
Which is a shame, they might have learned something.

In my experience, there's nothing wrong with tech interviews, but there's a
lot wrong with the people administering them. If I want to know wether a dev
knows what they're talking about, I ask them to explain something they've
already coded. If they can explain it, they understand it, and I usually learn
something to boot. Everybody wins.

------
bitwize
The whole point of tech interviews is to see if the candidate actually has the
requisite skills for the job.

Off-site contract work is NOT a solution. Hint: the candidate may not be doing
the work himself; he may be farming it out to oDesk or Elance at a fraction of
the price and playing WoW all day.

~~~
ahk
Easy solution to that is to discuss the work/code in the interview.

~~~
moubarak
i agree..i remember when i was a graduate assistant we would interview
students and discuss their submitted homework. It was such a clear indicator
of who worked and who didn't. The rule of thumb though when interviewing teams
was to meet them all at the same time and never individually.

------
lumens
What about just setting the interviewer's expectations up front?

"Hey, as I'm sure you may understand, these sorts of on-the-spot interviews
are a significant departure from the day-to-day environment under which I
normally perform these sorts of tasks. I know this stuff well, but still might
fumble a bit because of this atmosphere. Do you mind if I talk through this
problem with you as I would if we were working on the job together?"

Short contracts can be great when you can afford them (ie, have time/are not
currently otherwise engaged), but sometimes you have to work within the
framework provided. Being your own salesperson is not all that complicated:
manage expectations, build rapport, and under sell/over deliver.

A good recruiter can help fill in these gaps for you -- pre-setting the hiring
managers expectations, coaching you up on interview strategy and tactics, and
helping you understand a given company's interview process in full so you can
mentally prepare. Unfortunately, most recruiters are _not_ good and dealing
with them tends to be a pain. We're building a better recruiter, online, at
Mighty Spring ([https://www.mightyspring.com](https://www.mightyspring.com)).
You control the whole process through a web interface, and simply request
contact when desired. We're geared towards engineers and are currently in
private beta. Will expedite invites to HN signups -- feel free to email me
(address in profile).

~~~
jnbiche
Sounds like an interesting service, and I will e-mail you shortly for an
invite. That said, can anyone recommend a good recruiter like you refer to
here, who _is_ good at helping candidates with good skills learn how to
interview better? (if so, e-mail is my username at gmail)

I know recruiters have a bad reputations among most developers, but someone
like that would be worth their weight in gold to me.

------
dirk94018
Those European university tests copied by Google, then copied by SV startups,
mostly deliver two things, making the interviewer feel superior and filtering
for submissive coders.

All managers dream of robots that can read minds and work for titles but lazy
managers prefer to hire those who do what they are told, even if its
pointless, even when done poorly or without imagination.

A good manager is worth his weight in gold. "I will not do your tech
interview" while offering a short contract is an excellent way to screen out
the lazy managers.

------
moubarak
i remember getting rejected at the screening stage because i was not able to
explain how an sql index works (i'm not a database guy although many people
would think this is general knowledge). The next job i got was to build an
r-tree for goespatial querying purposes into a database engine. i knew exactly
what r-trees and b-trees were, i was exceptionally good with algorithms, but i
had no idea what an sql index was. for me it was very ironic and i had since
refused to go through tech interviews.

~~~
thestoic
We have seen this situation crop up with employers who refuse to do try outs.
these great devs then get picked up by employers who try devs out PS I work
for GroupTalent so I am biased

------
geebee
One good thing about reading/browsing HN is that you can get an impression of
the ideas that are starting to emerge. One thing that seems to be emerging now
is that people are rethinking the grueling technical interview process.

There was a huge emphasis on avoiding false positives in the interview process
- largely because a single bad hire can do great damage to a software
development team. But people seem to be learning that these grueling processes
may not do as much to avoid the false positives as we thought, and are
creating a vast number of false negatives.

I am no longer interested in participating in this sort of multi-day technical
exam taking. I've studied stochastic processes, mathematical optimization,
data structures and algorithms. I've taken exams on them. I've hit the books
for a couple of weeks prior to interviews where I've been grilled on these
subjects in greater depth than I experienced during my exams in grad school.
It's important knowledge, I get that, but I don't want to have to mentally
reload the material in "exam ready" memory simply to pass yet another
interview. I will rely on my general knowledge and my ability to look things
up on the job. My interviewers should feel free to evaluate my knowledge, but
does this really have to be more grueling and take four times as long my final
exams in college/grad school?

It's not that a technical screening isn't valuable, it's that the grueling
nature of these interviews means that if you can't recursively print out all
permutations of a string on the spot, right now, don't get confused up there
at the whiteboard, you're a no-hire. It can be very clear that the interviewee
is aware of what mergesort is, how recursion works, the importance of run time
in algorithms, and that the candidate almost certainly at one point
implemented it. They want to see it, now, in code, on the whiteboard. Or,
these days, typed into a screen that an interviewer is looking at.

A couple of years back, last time I was looking for jobs, I spent one and a
half days in interviews. I was asked to code a singleton, add a branch to a
binary tree, traverse a binary tree, now without recursion please!, find the
long term probabilities in a markov chain, formulate a linear program and
prove that the dual of the primal is the primal of the dual, now with matrix
notation please!, write a bunch of outer joins, convert a curve into a
piecewise linear function (don't lose convexity, please), on and on. Each
interviewer was fresh, I was shuttled from room to room. Then I came back for
three hours of interviews with management. No hire.

Another special one was where I only got to talk to a recruiter, passed a few
java tests (about an hour), and then took a homework assignment (spend no more
than 5-7 hours, please!). Didn't hear back, didn't hear back, didn't hear
back. About a month, and the recruiter calls, oh, they've decided not to
pursue this any further.

This is a rant, and perhaps an angry one. I feel bad about that, and it
doesn't feel great to admit that I've failed in these interviews, either. But
I'm glad that some pushback against this practice seems to be building.

~~~
gregors
"I was asked to code a singleton" This interview is over!

~~~
hderms
require 'singleton'; class Foo; include Singleton; end

Can I have money now?

------
throwaway1979
Very cool! I suffer from the same problem :(

I had an interview with a small startup I adore and had to code a simple
python scrapper with the startup's CEO. I was so freaked out I totally bungled
it up. Needless to say, my confidence went down the toilet.

I think I should accept that I don't do the traditional tech interview well.
Next time, I find myself in such a situation, I'll suggest the short contract
or coding exercise.

------
tokenadult
There is a large research base on how companies can hire to gain the best
workers. The smart thing to do is ask job candidates to go through a work-
sample test. An additional thing to do (which involves some special legal
steps in the United States, but can be done routinely in other countries) is
to give each job candidate an IQ test. Evidence to back up these statements
can be found in a FAQ

[https://news.ycombinator.com/item?id=5227923](https://news.ycombinator.com/item?id=5227923)

I've posted here on HN from time to time, which I expect to add to my personal
website in a while. A job candidate who doesn't want to do a work-sample test
is a job candidate who doesn't want to work for a smart employer.

------
oracuk
When I started my career I was in the UK civil service. One of the best things
I took from that experience was the formal training they gave me in
interviewing.

The UK civil service used interview boards consisting of a manager of the
role, a subject matter expert and an independent person from outside the
organisation. It is an inherently high-stress situation for the candidate due
to the numbers involved and and usually due to the room layout.

I was trained to account for the stress reactions and see past a freeze due to
the situation and focus on clear demonstrations of skill and experience. If
anything we were trained to try to make the candidates perform at their best
in the board rather than probe to see their worst sides.

It was complicated by the fact I was employed in a highly technical specialist
team (It was a military research agency) and few people we interviewed had any
experience of what we were planning to employ them for.

We also consciously went beyond a general knowledge test and focused on how
the candidate thought about answering questions rather than if they knew every
technical detail. In that role technical detail was only a man page or a
conversation with a colleague away if you know what you didn't know and were
prepared to ask for help.

Any interview that stresses the candidate, quizzes the candidates memory of
detailed technical facts and doesn't work from the premise that it is a high
stress artificial situation is not going to provide a valuable outcome for
anyone involved.

Edit: My best question to identify general technical competence starts with
"Can you describe the TCP handshake?" and if they know is quickly followed up
with "Why is it like that?". Unless there is role specific reasons to know TCP
then it doesn't really matter if they don't know, if they do know I am really
interested in their answer to why it is the way it is. Many even quite senior
candidates have never considered it before and watching their process of
thinking about it is very instructive about their ability to think about
technical details in the abstract.

~~~
cousin_it
Thanks for writing that! I hadn't realized it before, but after reading your
comment it seems obvious to me that an interviewing process should be designed
like this:

a) Acknowledge and minimize the unavoidable stress of the situation.

b) Use more general questions where candidates can choose their preferred
approach.

c) Allow them to show their strengths instead of seeking out weaknesses.

------
foobarbazqux
Can we please put the name of the author in the title of Medium posts? Ike
Ellis: I will not do your tech interview

~~~
leetrout
This is interesting and made me think--apologies for being OT.

You request this because you can't tell from the URL, yes? Do you have some
authors you'd have a greater desire to read?

I just got my invite to Medium and on some research saw where a notable dev
(who's name slips my mind) was moving off then platform for a few reasons and
I believe the URLs was one of them.

Now seeing your request I am thinking this is an interesting situation where
it sort of levels the playing field (or could cheapen the experience) since
you don't know who you're going to read based on the Medium URL.

------
rexreed
Love this article, but am I the only one wondering why this fellow is
interviewing so much if he's already been hired in a number of situations? Are
the companies he's working for going bust, laying him off, firing him, or he's
quitting? I'd think that if interviewing is his fear, he should do less of it
and find a great employer and stay there?

It sounds like contracting might be what the OP wants to do more than
employment if he's so good at selling that and not interviewing, but also not
keeping those jobs long enough.

Or maybe I misread it? Sounded like he was hired a number of times for jobs,
but went back to interviewing not long after anyways.

------
lhnz
Some very opinionated people in this thread. My two cents...

I've had similar experiences to the guy who wrote the article. Something about
interviews seems to make my heart race and I can stumble on very simple code.
This is in strong contrast to how I am in normal social situations where I am
highly confident and my personality is often infectious and passionate. I
think it's a case of high anxiety in authoritarian/test conditions. Those that
imply their working conditions are similar to interview conditions make a good
point, however if that is the case I would prefer somewhere less
confrontational and more forgiving.

Generally I prefer proper timed tests [0] without anybody watching. This is
how I normally work.

I'm also one of those people that has to constantly look things up; actually I
have a broad range of experience but I often find myself delving deeply into
things I have only cursory knowledge in - imagine a librarian that remembers
the locations of the books in a library and the analogy to knowing high-level
concepts that allow thinking on your feet when used together with the correct
reference materials.

Of course I believe that it's better to be good at making do with limited
information. Understanding things from scratch is what I have been doing all
my life. Like a chameleon when I look at some code that I did not write, it
becomes my syntax and I quickly understand the contents. However different
organisations and cultures sometimes prefer different kinds of engineers:
there is either a preference towards robustness or flexibility [1].

[0] [http://codility.com](http://codility.com)

[1] A test I would excel on would be being passed code in an unfamiliar
language, domain, library or ecosystem and being told to quickly get to grips
with it and add features/fixes (aka. flexible knowledge: unfamiliar territory
which requires me to pull together a broad range of skills.) This is opposed
to being passed a piece of code in a familiar language, domain, library and
ecosystem and being told to quickly and robustly add a feature or fix to it
(aka. robust knowledge: familiar territory which requires only a very specific
set of skills.)

------
kkshin
On-site interviews are a necessary for the most part, but phone screens have
always been the bane of my existence. About 50% of the time I can barely
understand what the other person is saying, mostly because the person
conducting the interviewer is not a native English speaker. I almost never
have an issue in person with non-native English speakers because you're able
to pick up so much more context from subtle physical clues. I wonder if anyone
else has this problem.

Disclaimer: My parents are non-native English speakers and I can't understand
a thing they say over the phone, but in person I have no trouble.

~~~
Bluestrike2
Tangential, but you hit on a really fascinating field in psychology with your
post.

We have these differences--linguistic, cultural, even physical characteristics
--that are huge. The differences that highlight a lack of shared
background/experiences/origin/etc. can be found not only to be at play
between, say, native and non-native speakers of a language but even separate
groups within the same culture. You see that in how we handle subjective
feelings of personal space, for instance --we Americans, for instance, tend to
prefer greater personal space over say Scandinavian or certain East Asian
cultures. But the fascinating thing is how those expectations can shift based
on region, and on an even more micro level, affluence etc.

Even when the differences are minor, such as say race and skin color, the
effects can be profound. If you look into what's called the cross-race effect,
you'll find a tendency to have difficulty processing faces of members of other
groups. If you've ever heard anyone say "all Asians look alike" or the similar
"all Westerners look alike", this effect is what's behind that sentiment. And
it's universal: this processing difficulty isn't limited to any particular
ethnic group. Cross-racial identification statistics for eyewitnesses prove
all too well just how troubling this can be even amongst ethnic groups that
are otherwise readily familiar (i.e. whites identifying blacks and vice
versa). But what a lot of the current literature shows is that the rate of
difficulty can decrease with familiarity that shapes how we code faces and
integrate them into

Anyhow, as far as communication is concerned, it's not just verbal. On the
contrary, most of our cues are distinctly non-verbal: body language, gestures,
expressions, prosody, paralanguage, and a lot more. People toss around Albert
Mehrabian's "93%" number a lot without considering its context (namely, his
work was limited to the communication of feelings and attitudes), but the
broader point is that these cues serve as a means of helping to imply meaning
to the words they accompany.

Now, where the really fun stuff begins is when you start to consider the
universality of some of these nonverbal cues. Particularly with the face with
microexpressions: involuntary expressions lasting only a tiny fraction of a
second that correspond to six basic emotions. Contrary to the idea that
expressions and meaning were culturally determinate, the research is fairly
overwhelming that despite differences in culture, language, and even physical
face characteristics, microexpressions and the emotions represented are
consistent. Rules governing those emotions are be culturally specific, but how
they're expressed and the emotions themselves aren't. Back in '71, Ekman went
to the Papua New Guinea to show this with the Fore people even though they had
almost no direct contact with the outside world up until the fifties, and at
the time Ekman went, had no access to Western media or entertainment that
might have given the Fore the experience with outsiders and their facial
expressions.

Related to your post, however, are the findings that show we're able to
recognize these expressions by people outside our own ethnic groups. In a
sense, not only are the emotions and expressions universal but so too are our
ability to recognize them. Biologically determined, hardwired. So talking in
person, rather than on the phone, can make all the difference in the world.

If you're curious, I'd recommend taking a look at a reprint of Ekman's
_Unmasking the Face_ and _Darwin and Facial Expression: A Century of Research
in Review_ if you're curious about some of the historical origins of the work.
The latter, in particular, is truly fascinating.

------
lewispollard
My current job hired me roughly the same way - short, informal with a very
basic coding test just to make sure I wasn't bullshitting. Then I was given a
couple of weeks to recreate a game they'd recently finished - didn't have to
be perfect, just a prototype and an example of the kind of code style I write.
Got paid to do it, spent a couple of hours at home a night working on it, came
back in to present it, and voila, job offer. So far it's worked out great!

------
cpprototypes
I've been a developer for 8 years. I have a good job already. When I get an
email from a google recruiter, I usually think this:

My free time is very limited and valuable. Google sounds interesting, but here
are my options:

a) Spend my free time exploring and building small projects with new
technologies and techniques. Maybe work on a mobile app that could make some
money.

b) Find my old CS textbook and notes and do algorithm studying and exercises
just to prepare for an interview.

Doing a) directly improves my skills and has lots of benefits. I've been able
to improve projects and gain a lot of good reputation at work because of
things I discovered doing a). a) could also lead to making a revenue-
generating mobile app. And perhaps most important of all, a) is FUN.

Doing b) just feels like a giant waste of time. Doing b) is a direct
opportunity cost of not doing a). The potential return for b) is what? Going
through a day long interview with judgmental engineers trying to look smart?
And it's boring. It was fun learning in college when it was the first time and
I had that aha moment of understanding. Now its just boring to go over it
again and again just to rote memorize things. I would rather be building or
learning something new.

------
consultant23522
This sort of reminded me of the old adage about people who "aren't good at
tests." "Oh, I see. You're not dumb, you're just not very good at the part
where we find out what you know." Software development is already full of
anti-social and/or introverted people. I know, I'm one of them. If you're
tipping off my "too much anxiety" scale then you're really up there.

------
jmtame
The smartest hacker I know was approached by Google, apparently they found
that he was working on some interesting stuff on LinkedIn. They asked him if
he'd come in for an interivew and he told them "I'm not going to do an
interview for you guys. You can either hire me based on my previous experience
and sample work, or I'm not interested."

A week or two goes by, and they hired him without doing an interview.

On a separate note, I've always had the test anxiety problem so I could
understand how an interview is more of an acquired skill and less of an
indication of your coding ability. I can code, and I have no problem with
understanding the material, but when it comes to taking a timed test and using
a pencil and paper for something that I usually use a completely different
input for (a keyboard and a monitor), I struggle with it. Some people dismiss
it and say "well you obviously didn't know the material if you couldn't get it
on a test," but I never agreed with that.

------
jhuckestein
All else being equal, I'd still rather hire the person that doesn't panic. I
think it's entirely fair to subject a potential hire, especially for an
important position, to a certain amount of stress.

Most people I know, myself included, have suffered from anxiety or panic
attacks at some point in their lives. It's usually possible to overcome this,
though. When you realize that you don't interview well, are afraid to speak in
public, freeze up on dates, are afraid to speak to clients, panic when your
boss disagrees with you, etc., you can either work on it or try to avoid those
situations forever. Frankly, I'd rather not hire somebody who convinced
themselves that they have to avoid certain situations because they can't
handle them.

I do love the contractor idea, though. Perhaps it would be best to hire
somebody as a contractor for a small project and then have them present in
front of the entire team and ask specific questions or ask for live
modifications?

------
jff
Where I work, an interview is a full day thing. I'm pretty happy with how it
works:

After going through an initial resume screening and phone call, you show up
on-site in the morning.

You then give a presentation about some recent work you've done. For those
fresh out of school, it's generally about their grad work.

Then you have a series of 1/2 to 1 hour interviews through the day, mostly
with people who were at your talk that morning.

The individual interviews tend not to be the Google-style "please implement a
data structure for XYZ on the board" sort of thing. Rather, we'll ask about
things from your talk or your resume that interest us. We might describe some
work we've done here, to hear what you think about the problem, how you might
have solved it.

A lot of what we're looking for is how well you're able to communicate your
responses. We also want to get a feel for personality, how well you work with
others and how well your personality will interact with the people here. I
believe this place is actually pretty diverse, and I like to think we don't
fall into the "culture fit = 20-something white male" trap; however, some of
the restrictions and circumstances of the work we do may make some people
unhappy and we'd like to avoid that.

We also pick two people to take the candidate to lunch. This is supposed to be
a chance to talk more about life in the area and what it's like to work here,
although honestly a lot of that comes up during the regular interviews.

After all the interviews are done and the candidate leaves, the interviewers
get together, share their impressions, and say whether or not they recommend
hiring. The hiring manager then makes the final call.

It's not really suitable to everywhere, I'm sure, but I'm pretty happy with
it.

~~~
psuter
Where do you work, if you don't mind me asking? This sounds a lot like the
interview process for research/academic positions; if you've made it to the
interview day, there is really no reason to doubt your technical skills
anymore, and the interview becomes more about finding out whether you would
find your place and collaborators to work with.

~~~
jff
It's for research, specifically at an FFRDC. I don't believe there's any sort
of "establish your technical skills" portion. My hiring process was a bit
unique because I had already worked as an intern for 3 years, but as I
understand it the usual process is 1) hiring manager finds the best resumes,
2) hiring manager does a phone interview with those people, and 3) hiring
manager invites a few of the best prospects out.

The real technical skills part is the presentation. If you can give a good, 40
minute talk about what you've been working on, you've already put yourself in
a good place.

------
zacinbusiness
I've always been great at interviews. I'm naturally outgoing, love to talk
tech, and really try to show, rather than tell, why I'm a good fit for any
particular team or project. That said, I hate traditional interviews. I hate
begging for a job, and I hate having to kiss ass to some manager who has no
technical competence. I have been fortunate in that I've landed three awesome
jobs so far in my life. Two were short-term gigs but one of those gigs helped
me network and was a huge factor in my landing my current position. All three
of these jobs involved me saying "Hey, show me a problem and let me see if I
can fix it for you." I don't believe in performing gymnastics for someone like
a monkey, because I'm not looking for a spot in a zoo or a carnival. I like
solving problems and I like helping other people solve there problems. So I
agree 100% with this sentiment.

~~~
digitalmaster
Couldnt have said it better myself.

------
SonicSoul
this is a very good idea.

i've had multiple interviews where i did well on the phone and the tech-out,
only to receive a "take home exercise".. with guidelines such as "it will be
graded by style and architecture in addition to correctness of function".

This would mean half of my saturday in a coffee shop coding an elaborate
solution using latest technology and good patterns.. with some resentment
because i just wasted hours of precious (and scarce) free time.

Not only has this never lead to an offer, but in some cases i'd not hear back
for weeks, with eventual vague comment like "it was good, but not great" or
"it was great, but we decided to go with someone who happened to have more
experience in X domain".. that's nice..

~~~
frozenport
Same thing.

I got an open ended problem that would take a measure of forever to solve:
Specifically to write a program (in your favorite language!) that would do
natural language processing and discern emotions and feelings about subjects
from text. We were supposed to include our own lexical parser.

The author's strategy scales poorly with complex and interlocking problems.
Where it is more important to show potential ability to solve the problem
(puzzles), holistic understanding (talkin' about it), or prioir experience
(specific questions about libraries).

This guy should address his core problem (stage anxiety?) instead of
advocating a solution that is only tenable in a limited number of cases and
represents far too much commitment from the participants.

~~~
jarek
> I got an open ended problem that would take a measure of forever to solve:
> Specifically to write a program (in your favorite language!) that would do
> natural language processing and discern emotions and feelings about subjects
> from text. We were supposed to include our own lexical parser.

I know of a YC alumni company that asks for a weekend project on roughly that
level and when rejected candidates ask if they can upload their work to
Github, the company declines because they'd "like to keep an even playing
field for future candidates."

Then you're left with choosing between having an awesome project you can't
show off and being an inconsiderate jerk who uploaded code despite being asked
not to.

Doesn't really make one enthusiastic for the next time you're asked to do an
"exercise" or a "project."

------
joyeuse6701
I agree with that sentiment, I don't do well under the pressure of someone
leering over me as nice and comfortable as they make it. Sounds like a good
startup idea. Someone (maybe I will) make a site that formalizes the contract
work concept. Instead of setting up and doing a project for someone, maybe a
pair programming exercise on the fly over some days that neither the
interviewer or interviewee is prepared for? 'Program Tic-Tac-Toe in x
language', 'find the minimum value of this array given these properties of the
array'. Could make it fun. Almost like a mini-mini hackathon. I'd much rather
do that for 4 hours than random probes of knowledge from 4 people over almost
pure academia.

------
nappy-doo
Counterpoint:

This is a recipe for only finding unemployed people, and in my opinion, the
best people already have jobs.

I have been offered to interview with YC startups that wanted me to fly out,
spend a week writing code with them, and _then_ they'd offer me a job. I'm
already employed, by an employer that legally owns all my code. I can't take a
week off, write your code, and then _possibly_ get an offer. I don't have time
for that.

Technical interviews can go afoul, yes. But, IMHO, they are the best we've
got. They show respect for the interviewees time, and decisions should be made
quickly. Will you occasionally miss a good candidate, yes. Will a bad one get
through, less likely. That's about the best one can hope for.

~~~
thestoic
Ideally the time you spend writing code is both compensated and under a Work
For Hire of the company trying you out. Your current employer owns the IP of
whatever you do during work ours and using their equipment not what you do on
your own time.

~~~
nappy-doo
Not at Google.

~~~
pjlegato
At least in California, employers are statutorily prohibited from claiming
rights to IP that was created on the employee's own time and using the
employee's own equipment, and agreements that purport to waive this
prohibition are void.

(CA Labor Code 2870-2872; [http://www.leginfo.ca.gov/cgi-
bin/displaycode?section=lab&gr...](http://www.leginfo.ca.gov/cgi-
bin/displaycode?section=lab&group=02001-03000&file=2870-2872))

~~~
nappy-doo
Great. CA law doesn't apply in Massachusetts.

------
photomatt
This is how Automattic / WordPress.com has done interviews for 5 years now.
There are some tweaks to do it well that we've learned over time, but there is
nothing like seeing someone's actual work to see how they're actually going to
work.

------
wglb
_Every job I actually got was because a friend made sure that it happened._

I like this approach. In fact, something similar has happened to me in several
of my job acquisitions. Networking trumps pretty much anything else.

------
joeblau
I've noticed that when doing interviews with younger developers, you run into
the problem of "They only know about the projects that they've worked on at
_fill-in-school_ " and they have no real world experience to base an interview
on. I've even experienced this with interviewees that at companies I've worked
for. I'm definitely a proponent of contract-to-hire because you can figure out
if you really gel with the team. Plus there may be some things that the
interviewee never thought of that you're really good at.

------
RussianCow
Maybe I'm the only one here, but I actually _like_ technical interviews.
Granted, I've done a handful of terrible interviews (either because of the
questions or because the interviewers weren't prepared), but I think _good_
tech interviews are very productive. I've been on both sides of the table:
from the interviewee's side, a good interview allows you to show off your
strengths and show the team how you work; from the employer's side, it's
important to get inside the candidate's head and see exactly how they work and
how the solve problems.

Now, a good interview isn't one where you ask question about the technical
details of a language or a framework or how HTTP works or anything like that.
Sure, good technical knowledge is necessary for most positions, especially
senior ones, but information is really easy to pick up as you go, whereas real
talent is not. Good interviews ask more broad, open-ended questions. "If you
wanted to build X, how would you build it?" "If your app was really slow,
where would you look to fix it?" "What do you think about
framework/language/tool X in relation to tool Y?" Etc, etc. These kinds of
questions let you really get into the candidate's head and figure out if he's
a good fit, while still allowing him room to go in a different direction and
play to his own strengths.

------
rolandhordos
I too think something has gone horribly wrong with the "modern tech interview"
especially in a large corporation. It feels like a Frankensteinian experiment
gone horribly wrong relative to real world results-oriented development. If
the actual job was like the "tech interview", and the actual corporation run
like the "tech interview" process I would leave screaming inside of a week ;)

Practice can work against you. In one case I was worried about the algorithm
and data structures side of things based on glassdoor posts. Spent a week of
evenings coding algorithmic whizbangery. In the interview I obsessed on
getting every line of from-scratch code right (obsessively focused is often
how I code real software) and stopped "listening" to what was being asked.
Double whammy was the interviewer was actually not very familiar with the
solution to the problem (canned and complex do not mix well) and when I
confidently but politely corrected him as we were coding, boy the color of the
interview changed fast and game over. My bad, In the real world I'd politely
correct a coworker too.

Or maybe what you should practice is writing out JavaScript with pen and paper
like another interview. I hadn't written code out by hand for 15 years .. like
since the invention of the keyboard. I did a terrible job despite having just
completed a non-trivial very modern mobile front end project. Ri-donk-u-lous.

Be yourself, stay balanced, do your best, HR science is evolving too.

------
chetanahuja
Technical job interviews as traditionally run in silicon valley culture are
completely bogus. Many different better ways exist, one of which is the short-
term contract work (with an eye towards full time hire). For my company,
pretty early in my first conversation with a potential hire, I tell them that
the hiring process will never involve having to write code on a whiteboard. I
intend to keep it that way whether I'm the CEO of my startup or just a lowly
interviewer drone in a big corp from now on.

------
mahmoudimus
I'm a big fan of what GroupTalent is doing - I am finding exceptional
candidates through them.

One of their main features is contract to hire. I find many great candidates
through them where I work.

------
kenster07
The reason the san fran interview tends to focus on theoretical cs more so
than other regions is because the plethora of berkeley and stanford grads in
the area, who subconsciously prop the entirety of their ego on their college
educations, and thus use it as a measuring stick for others, sometimes at the
cost of a good, practical hire. I've seen job descriptions for FRONT END
positions which list a cs degree as a 'must,' which is just absurd in today's
day and age.

------
abawany
As an interviewer, my impression is that interview performance often does not
predict success in the workplace. The most extreme example is for a case where
the person aced (I mean absolutely aced) the algorithm questions I threw at
him but was unable to get things done at work. In technology, we don't have a
good way to filter by personality and conscientiousness - these unfortunately
turn out to be pretty key in getting things done well.

------
antihero
> I politely suggest that a short contract job might be the best option for a
> company to evaluate a senior developer.

This article _reeks_ of privilege, namely that of location.

The suggested is horrendously unfair to people that would need to relocate
(possibly even internationally) to get a job.

I am currently interviewing for a large tech. company in Silicon Valley. I am
living in England. It would take a substantial amount of resources for me to
even meet the team in person, so of course they want to vet me via Skype or
whatever before they commit to this. On the flip-side, if I'm going to be
uprooting my entire life and moving to SF, I want some sort of guarantee I
have a solid, full-time position.

I also wouldn't be able to afford a £1,000+ flight (and countless days of
missed work) in order to do an on-site interview. Utterly preposterous.

Thankfully, the person doing the technical interviews has been a person who
basically has the same job as me, so they understand the position and can see
if I'm a good fit. The interviews were of the format that they pasted into
some questions to a collaborative editor, I get to choose a language, and
solve them. We are Skyping so I explain the reasoning behind what I'm doing
etc. Code doesn't have to compile, I don't have to know the exact syntax for
function calls (because who can't find that in seconds anyway), but it's about
figuring out my though processes, confidence, ability to deal with new things,
etc.

It'll be interesting to see what they think of me, but it seems like a
reasonable process, and does not exclude people based internationally.

~~~
ChrisLTD
The contract work could be done off-site.

~~~
antihero
Not necessarily - for instance there may be requirements for physical access,
data protection, actually working in the same office as a team member, etc.

------
_getify
I won't do tech interviews either, but not because I think I will fail at
them. I think they are completely bogus and give totally the wrong signal.
It's a waste of my time AND the company's time. I wrote up my thoughts on this
exact thing a few months back: [http://blog.getify.com/technical-interviews-
suck/](http://blog.getify.com/technical-interviews-suck/)

TL;DR: Everything you need to know about if I'm a good fit is available online
in my OSS (et al) track-records. If that's not good enough for you, that's not
the kind of job I want anyway. I want to work for companies that value the
full lifecycle of OSS work, which you can only see in such a way, and CANNOT
judge via tech interviews.

By the time I walk in the door for an in-person interview, I expect you to
already know that I am fully qualified (tech and otherwise), and you're
looking now to judge my cultural fit by sitting me down in a real team meeting
and seeing how it works, etc.

If I show up and you try to quiz my tech skills, you didn't do your homework
on me, and I have no more time for you, so I'll just chuckle and walk out.
Politely of course.

------
luckydude
I'll probably take some crap for this but I go on gut instinct a lot. I've got
a guy working for me who is awesome, we got on the phone in the interview
process and 30 seconds into it I was saying "You're hired, I want to work with
you". My COO overheard that and was running at me waving his hands no-no-no.

That was 2004 or 2005. He's still here. Great hire.

Sometimes you can just tell right away.

All that rambling aside, I'm with the people who dislike the techy interviews.
I was #4 at Google and I don't think there is a chance in hell that I could
pass their interview questions today. But I've done good work, created good
stuff, they ping me from time to time to come back. So perhaps I should be
hired but I wouldn't pass the interview process so far as I can tell.

What's wrong with the contract idea in the original article? As a manager, I
love the idea of someone who is willing to demonstrate their skills in a
contract. If I were out looking for a job I'd offer that up, it's try before
you buy, what's the downside?

Can other managers tell me what is wrong with that approach?

------
pcl
I'm a big fan of this approach, and I've used it successfully when hiring at
startups. But it hasn't seemed to fit in well with the hiring culture at large
companies. We can't use someone's time for free, and initiating a contracting
relationship is mired in red tape, so isn't really worthwhile for a small-
scale project of the sort that's appropriate in this context. And asking
someone to spend a couple days working on something that is going to be thrown
away seems demoralizing and possibly counter-productive, since the fact that
it's "just a toy" will doubtless impact the approach the interviewee takes to
the problem.

Plus, in a large company, internal transfers are common. The social dynamic of
asking for an employee who works elsewhere in the same company to do work for
a different part of the company seems awkward.

Does anyone have any success (or failure) stories about trying to make this
sort of approach work in a large company?

------
sybhn
Being good at tech interview is an art, that few masters, and many are good at
while being poor developers. I have countless tales of wow-thumbs-up-interview
guys that turn out to be just good at that: interviews. Also, very anecdotal,
but my best hires in 15 years have been poor interview performers.

So what's the answer? no, not contract to hire. Although good in theory, in
practice many companies won't support or approve contract to hire for full
time position. Call it HR inertia, a.k.a 1 of the 4 horsemen of death in
bigger more established tech businesses.

So where am i going with all this? Well, that's why networking is important.
Get the people you worked with to bring you in places. You don't have to
impress anyone on a white board (who codes on whiteboards anyway) but put the
emphasis on culture fit since you already pretty much have been tech screened
by your old pals.

In conclusion, be nice to your peers. Especially the smart ones you work well
with.

------
ianstallings
This is interesting and I like the small contract up front, I've done that
myself, but I would say that performance anxiety is real and can be treated
using not just medications but training your brain to recognize and work
through it. My entire career I've been plagued with anxiety issues and have
worked through them with help from doctors, reading a lot on the topic, and
talking with others that have similar issues. There was a time when I would
freeze up just talking one on one with someone. Now I'm capable of giving
presentations to rooms full of executives. It is a never ending struggle and I
still get nervous. But I can't let it spiral out of control to a anxiety
feedback-loop.

My point? Don't just ignore the problem of anxiety when it cripples your life.
Address it head on and try to work through it. It will help your life greatly
if you can.

------
osetinsky
"I finally stumbled upon the cure when I interviewed at a small startup that
had a different approach. I met the leads for lunch, then followed up with a
social chat with the whole team. We talked tech, but they didn’t try and vet
my skills."

Meeting potential employers outside the office like this (over lunch or
coffee) has been so much more effective for me as well. It takes the pressure
off on both sides and lets everyone really get to know each other. If you
can't sit down with someone over coffee or lunch, how are you going to work
with them?

We're gathering companies who are interested in this approach to hiring (and
trying to make it a trend). Employees at the companies offer coffee meetings
(their treat) that anyone interested in the company can request. If there's
mutual interest, they meet for coffee to chat about the company.

www.treatin.gs

------
windust
In our company we understand that testing up-front can be off-putting, but we
rather pass up a great candidate than hiring a poor one (we do subscribe to
Polsky view on candidates
[http://www.joelonsoftware.com/articles/GuerrillaInterviewing...](http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html)).
We allow them to test at their pace (codility.com) from home first, then we
re-test them on-site (to avoid the 'someone doing my homework' effect). After
that the next interview is pretty much talking on the code written code and
approaches or decisions that the candidate took. So in that sense is a great
piece to further discussion.

The issue is that where I work we can't subcontract as a way to 'test' for
candidates. The code is so proprietary, and have so much red tape (Options
Trading platform) that we don't trust anyone unless you are full-time. Also,
the code is fairly complex and embedded in it's industry-speak that unless you
come from the same industry subset, you will not be productive (like knowing
what Black-scholes, instrument, or delta means). So the investment to getting
any good developer to be able to produce is immense. We considered
subcontracting for assessing a candidate, but it is fairly hard.

Also we have seen people that do extremely well on every other aspect of the
interview but can't deliver when asked to write a piece of code. Good or bad
it does show your ability to work under pressure (I am not sure if it's
extreme in the financial industry, but stress levels here run fairly high...
for a fun read [http://codesnipers.com/?q=interview-the-wall-street-
programm...](http://codesnipers.com/?q=interview-the-wall-street-programmer)).
So when you're getting your coffee, someone comes and says 'we need to fix
this' it will probably be as intimidating (or more) as having a code
interview.

Lastly, maybe because we've seen it often enough, there are a ton of
programmers that can't write code (yes, the fizzbuzz crew). Having the
codility test filter in front of all eliminates a lot of that chaff we see, so
we don't even bother with the candidates unless they get a good-enough result
in codility (we do look at the code, not just if it passes/fails the unit
tests, but we don't bring the candidate for an actual interview until we have
a reasonable expectation that they can program). We understand we will miss
Ike Ellis, and we accept that as part of the tradeoffs between time and
opportunities.

------
brianmcconnell
I've never liked the tech interview format. Throughout my career I've run four
different companies, all small, all resource constrained, so I never had the
luxury of competing for the A+ talent.

I ask people for a list of projects that they designed and coded (live
projects, so I can see how they function), to get a sense for how good they
are overall, then will look at the underlying code. I value readability and
documentation over fancy tricks meant to show off the author's MENSA status.

When it comes to the interview, that's all about assessing their personality,
work habits, and broader interests. Friendly personality, good work ethic and
broader interests = someone who is flexible, which is vital in a small company
where everyone has to do a bit of everything.

------
fieldforceapp
Perhaps it's already been mentioned, but GroupTalent [1] has set up a business
to offer this type of 'small project as an interview,' or what they call "Date
a Company" to help guide primarily freelancers to full-time employment:

They did a pivot after acquiring Kyle's TinyProj [2] customer base, which
included us. Wondering if anyone has any good experience with GroupTalent?

[1] [https://grouptalent.com/welcome/](https://grouptalent.com/welcome/) [2]
[http://techcrunch.com/2012/01/16/tinyproj-shuts-down-
users-s...](http://techcrunch.com/2012/01/16/tinyproj-shuts-down-users-sent-
to-techstars-grad-grouptalent-instead/)

~~~
thestoic
Hi this is Manny, CEO of GroupTalent. I wanted to add context to the pivot
comment. More than a pivot, we expanded our offerings to include try outs and
full time opportunities. It turns out that there is demand for all, and
someone may do freelancing for a while until they find the right fit. We
strive to provide all the options for the entire career life-cycle. We still
connect developers with contracts and short term projects - however we see the
majority of the demand on both ends for try outs at the moment

------
erikb
Rule of Thumb, which might apply or not (;-D): People who think they are good
usually aren't!

There are many reasons why people would come to you to ask for help or why you
are more successful then colleagues. E.g. in my company we have a guy who
thinks of himself as a web developer but thinks that CGI is the protocol the
browser talks to the web server. It is not hard to be the best in such an
environment. Don't compare yourself inside your company! Compare yourself to
the rest of the world! Look on GitHub, read blogs, talk with people on
software development mailing lists. If you still feel stronger than most
people around you, you probably are.

------
patatino
I always walk in with this in mind: "Let's see if I want to work here". At the
point where I'm really convinced and want to work there I get a little nervous
;)

I also insist on doing some work there, to prove myself of course and see how
things work. how they are organized, tools and frameworks they use etc. And
most important to get a feeling about the people there. I know it's hard in
just one day but you get an impression. I left my last job because I wasn't
feeling good there. No team spirit and a "cold" atmosphere. Why should I spend
8-9 hours a day at a place like that?

------
xijuan
If you think interview is really a measurement of one's professional ability,
then like any measurement, it has measurement errors. To me, it seems that
this person has some sort of interview anxiety because of previous bad
interview experiences.. So the anxiety kind of feeds back onto itself. In this
case, the interview can't really measure his ability accurately. But this
brings another question... How valid and reliable are those interviews? I
really have no idea about that since I have never had a tech interview. Just a
question to think about when it comes to evaluating a measurement

------
avoutthere
This piece mirrors my thoughts on tech interviews as well. Firing brain
teasers at somebody under the pressure of a job interview environment gives
very little indication of how the candidate will actually perform their day-
to-day job duties. I've long thought that the short-term contract method was
far superior. This is especially relevant in light of yesterday's post about
the "Wretched Google Interview"
([https://news.ycombinator.com/item?id=6243627](https://news.ycombinator.com/item?id=6243627)).

------
dspillett
_> I politely suggest that a short contract job might be the best option for a
company to evaluate a senior developer_

Nice idea. Though I hope you don't expect to be given high priority stuff or
be paid a full senior dev's wage during this short contract before which I
don't know your abilities as I've not had some other chance to assess them.

Of course an active public portfolio helps here, as potential employers can
get some idea of your output from that, but we can't truly rely on it as it
can be faked (or be misleading for far more equitable reasons).

~~~
Plasmoid
>Nice idea. Though I hope you don't expect to be given high priority stuff or
be paid a full senior dev's wage during this short contract before which I
don't know your abilities as I've not had some other chance to assess them.

The nature of the work isn't that important. However, asking someone to take a
low-ball contract is a great way to filter talent. People who are good, or
busy, will completely turn you down. People who are desperate or suck will
gladly take the money.

This contract test should be last one you do. It should be either the full day
on-site or the short contract. You also need to pay market rate if you hope to
hire market rate talent.

~~~
dspillett
_> People who are good, or busy, will completely turn you down._

 _> People who are desperate or suck will gladly take the money._

I don't see that as a universal truth at all. Many decent people are out of
work for various reasons (start-up just gone under, contract ended and haven't
found the next one yet, just back in the market after illness or similar, new
to the area, or like the post that started this discussion: they just don't
interview well despite their technical skills+experience) and some of them
_are_ desperate for new work. Not everyone, even amongst the best people, are
sat on enough of a nest egg that they can turn work down willy-nilly.

People who are busy won't be applying in the first place, or will take the
technical interview option (which is presumably less difficult to schedule the
time for) if offered instead.

 _> You also need to pay market rate if you hope to hire market rate talent._

For the job yes, of course. For the interview, which this short contract is
taking the place of? I don't think so. You can't be too cheap of course, as
that will make people doubt the salary range being quoted for the real
job/contract.

Of course if a company were to try use this as a way to get quick short-term
resource in cheaply, with little or no intention to take people on for longer
contracts, their reputation for it would circulate PDQ and people would stop
applying at all (unless _really_ desperate).

------
hfsktr
Reading through here and seeing how many people are saying "You don't know x?
You're an idiot, you're out!" makes me feel glad that I was able to get a job
at all. Apparently I don't know any of the 'easy' questions so I must not know
anything.

It definitely doesn't help with my confidence going into an interview and not
knowing if I admit I am not an encyclopedia is going to get me disqualified
right then and there.

I am sure that it has to do with the jobs and the locations and the companies
but definitely freaks me out about my future.

------
mathattack
As you had alluded references (and professional reputation) is the single
biggest predictor of success. This is why resumes tossed over the transom to
companies is such an inefficient process.

2nd to references is looking at real work products. You're in advertising?
Show me your ads. You build websites, show me your websites.

Your method of short term contracts is a good way to get to both at the same
point.

Any thoughts on recruiting college hires? They don't have work products, and
in many cases don't know enough to be useful on a project with low guidance.

------
danso
To go on a tangent, the OP mentions once being asked for his favorite video
games...if I'm ever in a interviewer role -- and the candidate mentions in
passing that he plays video games as one of his interests -- I think that'd be
a _great_ expository question.

For instance, a gamer who enjoys TF2 or better yet, Left4Dead...that's a
partial sign that they enjoy teamwork, despite the downsides of dealing with
weak-links and griefers. Someone who enjoys only Halo deathmatch...well,
hopefully their skills match their bravado ;)

------
chaostheory
well you better have something to show then such as a public github repo.

~~~
toomuchtodo
Pass. I spend enough time at the office writing code that I can't show to the
world because my employer owns it. I don't need to justify my six figure
salary to my next employer by writing even more code on my off time just to
prove I can write said code.

~~~
chaostheory
Well then how am I going to figure out whether or not you can code? The only
thing I can think of is an expensive two week trial period which doesn't make
sense since I feel that most programmers will either submit work or submit to
a pop quiz.

~~~
toomuchtodo
Good developers cost, what, $120K-150K/year?

If a two week trial period is "expensive" to you, you don't have the budget
for someone in that pay range.

~~~
mikeash
It's expensive in other ways though.

A programmers who is currently employed but thinking about moving on probably
won't agree to a two-week trial period because of the substantial risk that
they get rejected afterwards and end up unemployed. That makes the trial
period expensive to _him_. In turn, it makes it expensive to the employer as
well, because you'll filter out good people.

~~~
toomuchtodo
Can they not do this two-week project after hours? Must it be in your office,
on your schedule? Where you code, the hours you code, these do not matter. The
code is what matters.

~~~
mikeash
Sure, but now it's not going to get full time dedication, maybe half that if
you're lucky. So it's more like four weeks. And maybe they don't even have
that much free time, so it's even longer.

------
bubbleRefuge
Creative idea. Also, if you complete the assignment in your spare time, it
says something about your drive/motivation and discipline. These intangibles
are hard to glean in an interview.

------
leokun
The benefits of a tech interview is that you have an opportunity to present a
challenge to the candidate that contract work may not have. I increasingly use
problems I have run into myself while working on the product we are hiring
for. It's good to know how a candidate will solve these critical problems,
because bad solutions can be really bad for your team and product. Contract
work will also eat up time just getting the dev running the development
environment and leak code/product secrets.

------
elb0w
I do most the interviewing for our tech team. I will rarely even ask a
technical question. I look for passion, confidence and that they can keep a
dialog on the topic of tech going. If I cannot have a conversation with
someone for 30 minutes, how would I work on a project with them for months? I
personally loathe logic and algorithm questions. If I ever get asked them
myself on an interview I will actually ask for a different set of questions. I
dont think it adds any value.

------
hackula1
I will not hire someone without seeing them code something... period. There
are too many tricksters out there. I ask them to solve Fizzbuzz using any
language they want, any editor, any question, any google search (including
just looking up the problem and copying and pasting), and any amount of time.
They get to do it on their own at a private workstation. Still 90% fail even
after completely fleecing me in the "technical conversation" portion of the
interview.

------
brenfrow
We're all wired differently. Some people just naturally have more anxiety than
others. I think what's needed is a proper amount of empathy for people who may
not be able to hold up to the nerve racking process of an interview. Given
that developers are not always the most empathic towards
emotional/psychological issues, I'm glad someone has voiced this and that its
getting so high on hacker news.

------
rjurney
I couldn't agree more with this. Most technical interviews are designed to
make the interviewer feel smart.

I interviewed at a company that gave a software engineer's interview for a
data scientist position. Because I'd actually worked as a data scientist, my
software engineering was a little crusty. I failed the puzzles, and its really
frustrating that way.

I've done the 'start as a contractor' thing twice and it works.

------
nrubin
This is sort of like an internship, but for people no longer in school. I've
interned three times (finishing my third now) and I think it's a great way for
you to get to know a company and for a company to get to know you. That is, of
course, assuming the company has a bite sized piece of work that allows you to
show if you've failed or succeeded.

------
benschwarz
I wrote about code tests and interviews a couple of months ago.
([http://germanforblack.com/post/52224250893/the-perfect-
code-...](http://germanforblack.com/post/52224250893/the-perfect-code-
interview))

Heres a choice quote that I'm still happy with:

"Programming isn’t theatre or performance, “on demand” isn’t how your job
works"

------
ahk
I'm pretty much at the same point of refusing to do any actual coding on an
interview and for pretty much the same reasons. Really like the option of an
offline code test followed by discussion of the solutions or a small contract.
But it's pretty rare for companies to actually do this, since nearly everyone
now follows Google's model.

------
joe_the_user
I've almost always done really well at technical interviews.

But I support this because a lot of technical interviews are ripoffs of
people's time. I've put a lot of effort into technical presentation, done
well, and then been disqualified based on other criteria. That sucks and the
companies have done it that way because it's easy for them.

------
thehme
Did I just read that employers read potential employee's tweeter accounts?
This is odd. What does that have to do with coding? I hope they meant the
employee's work related tweeter account, which they got from the employee.

Anyways, the article is good, but mostly for very experienced developers who
can demand certain accommodations.

------
codex
I've observed that there is at least a 10x, possibly greater, difference in
the caliber and culture of various organizations. So if you failed interviews
at organizations A, B, and C, but are doing OK in your job at D, it doesn't
imply that you would have succeeded in A, B, or C, possibly due to differences
alone.

------
pbreit
I understand the sentiment, the traditional interviewing process doesn't seem
like the best way to evaluate candidates. However, the proposal breaks down
for the vast majority of good hires in that it is impractical to expect
someone with a full-time position to quit in order to try out for a new team.

------
bogardon
the point of technical interviews is to see how you think about problems,
getting it correct isn't even that important. i can understand why people
really hate this stuff if they did not come from a cs background, but it is a
knowledge gap that they should look to bridge eventually...

~~~
rolandhordos
>> to see how you think about problems .. That is the noble goal. Then it goes
horribly wrong along the way because many (very many by this river of
comments) don't think the same way during interviews as they did while doing
amazing work just the very day before. It's gone too far and it's presently HR
"conventional wisdom".

>> getting it correct isn't even that important .. Perfectly proving the
point. Coding the day before, you're aggressively focused on getting it right
and shipping a quality product. Suddenly you're in an interview and you're
doing the opposite, coding just so much irrelevant nonsense that doesn't
really matter and being judged out of context. Wasted time, effort, angst, in
short a potentially bad start to what might be a great relationship.

------
icn2
I like oracle way of hiring. You got a degree from a decent college with
decent GPA you are in. Very clear and straight forward. If you got in a decent
college and graduated with a decent GPA - you are smart and somewhat
hardworking, you should be doing well in your job.

~~~
pja
Google recently revealed that going back over the data they kept about past
hires demonstrated that an individual's GPA was completely independent of the
quality of their future contributions to the company.

Why should Oracle be any different?

~~~
taway2012
There is a diff between what the parent said and what you said. They aren't
opposites, hence they can both can be true. IMHO.

What I understood from parent was: good college + good GPA => meets minimum
hiring criteria, so make them an offer.

What you are saying is: (good college, good GPA) is not correlated with
magnitude of performance among _PEOPLE ALREADY HIRED INTO GOOGLE_.

~~~
mikeash
I bet height correlates very weakly with basketball ability among top NBA
players, too.

------
tyang
This is great. The best way to see if someone can do the job is to give them a
job to do and pilot test. Introducing variables, like interviews, logic games,
etc. reduces the likelihood that a potential employer can figure out whether
or not you can actually do the job.

------
edent
If you get nervous under the pressure of an interview - how will you react
when $CriticalSystem breaks during $BusyPeriod?

Do I want to hire a person who is great when things are going well but who
goes to pieces under pressure?

Learning how to be interviewed is as useful a skill as learning how to code.

~~~
kamaal
There is a common theme but an interview and a crisis situation are not the
same.

Its like attending an exam, its not the same getting work done in the real
world.

>>Learning how to be interviewed is as useful a skill as learning how to code.

No, learning how to build is a useful skill. Learning how to be interviewed is
mastering the art of being the best rat in the rat race.

The whole point is even if you win, you still remain a rat.

~~~
10098
> Its like attending an exam, its not the same getting work done in the real
> world.

Of course it's not. Real world is much more stressful than an interview.
During an interview you chat with another developer in a room with a
whiteboard. In the real world you are woken up by a phone call at 4 AM to fix
a critical system, knowing that if you screw up even slightly, you'll lose a
very important customer. I've experienced both and I can confidently say that
I prefer the former.

~~~
MitziMoto
I disagree. I've been in those "4AM" situations before and handled them well.

I can't interview to save my life.

These are two completely different mindsets.

------
whiddershins
I agree 100% with this post. Any time it is feasible, the best way to know
what it is like to work with someone is to work with them. Small contracts and
transitions from contract-to-full time allow both parties to learn a bunch
about each other with minimum risk.

------
KirinDave
I loaded the article and searched for "Github", "Bitbucket", "Mercurial" and
"Git." I didn't find any. No tech interview and no carefully prepared resume
of source with 3rd party annotations for a base level of veracity? No hire.
Doesn't matter how neck your beard is.

And I am certainly not going to introduce a TON of overhead into our process
bringing you up to speed just to assess this. You go from asking for 3-5 hours
of my time to asking for over a week _like that is reasonable_. Like that is
somehow a superior outcome for everyone? Here's a hint: it is not.

You live the life you wanna lead buddy, but I am not going to "trust" that you
are a good developer without getting at least some indication that you are not
a very convincing impostor. I have trouble with high-stress googletard
interviews too (and I don't give them), but to ask for tech jobs without any
real evidence of tech capability?

That's unreasonable.

------
snapoutofit
I completely agree with this, to the extent that I enforce this in every place
I plan to work with/in. Work in with a small contract, get to know the
people/business. Keeps options open for both sides without losing out on
time/momentum.

------
chenglou
Seems like a reaction to yesterday's Google post.

Does anyone know how interviews at Apple and Facebook are like? There are
often praises of Microsoft's interview procedures and bash on Google's on HN.
Wondering what these two other companies are like.

------
thomaslangston
While most of the comments are about the perspective of "Why does the
applicant desire to not have a technical interview?", I'd rather talk about
"Why does a company desire not to do a short contract?".

------
lgleason
a contract in the evening is the best way to see how someone works and makes a
lot more sense. A bad hire costs everybody a lot of money. I don't know why
more firms don't embrace this method.

------
gauravvgat
Giving paid assignments to see the candidate's job performance is not new. It
has been used by a lot of companies. Even we hired our first guy using such a
process. And it has worked.

------
meerita
Before I ask someone to come, I check his online stuff: github account,
twitter, personal website, Linkedin. If with that I'm not enough sure I don't
bother to interview anyone.

~~~
zerr
So you a priori don't believe what is stated in the resume. Why?

~~~
meerita
I read their cv's. In fact, Linkedin is a cv itself. But I like to inspect
his/her code/design before taking a choice.

------
AYBABTME
To put this post in perspective, I'm curious about:

    
    
      - How long have you been doing this career for?
      - How many jobs have you had?
      - How long you had those jobs?
      - How many technical interviews did you do?
      - Since when have you started practicing your new 'technique'?
      - Over which period have you effectively applied it?
    

Until similar numbers are available, I'll simply consider this article an
anecdote that, if anything, suggests the OP is a job hoppers or has a hard
time keeping a job.

In a non ad-hominem manner, I guess what I mean is: what useful data is this?
Should people base their future behavior on your anecdotical reliable
experiment/measurement?

------
melindajb
very smart approach. it's never wrong to approach a job interview as a
negotiation from the beginning. If you KNOW you don't do your best in a given
situation, you get a chance to see if the company sucks by seeing how they
respond to your questions. Employers who don't get this miss the point
entirely. It's a two way street, especially when hiring quality developers.

------
ar4420
Great post! Completely agree! While we still do traditional interviews at
CoachUp, we favor the contract->perm model whenever possible.

------
Glyptodon
I wish all interviews were done this way. It solves so many problems with the
traditional coding interview process.

------
marcamillion
I couldn't agree more with this approach. I have a similar story that recently
proved to be quite successful.

I was working on a project myself, that I kept getting stuck at a particular
point. It could just have been that I was looking at it, by myself, too long
and was too close to the problem that I couldn't solve it.

I was looking for Rails devs because 5KMVP started getting more requests for
work.

I got a few recommendations and people reached out to me about that freelance
Rails position. I whittled down the list to a few I was interested in and I
decided to do exactly this.

I created a mini-spec of the problem I was trying to solve, pushed the
codebase to a private bitbucket repo and added the guy I was evaluating.

Told him what I wanted completed, and told him I would pay him to complete
that micro-job. If it works out, then we will move on to other projects.

Once he finished the project (in a few days) we both walked through his
solution. That was such an insightful process for me, because I got an inside
look into the way another developer thinks. I even learned from his approach,
from his code style and was pleasantly surprised with the quality of the
output.

Going through the 'post-code analysis' also allowed me to see how he
communicates in the way that I will really communicate (which is via Email and
Skype).

I have since hired him and I love working with him. We do have things to work
out - specifically on the communication side, but I was pleasantly surprised
at the outcome of the little experiment.

For a relatively small amount of money, I was able to a) Learn an interesting
approach to solving that particular problem, b) learn new coding approaches,
c) figure out how he communicates, d) see how we would work together - he
didn't understand something, so he asked questions while he worked through it,
e) he was able to do all of that at his leisure - not necessarily through a
timed examination.

It's a wonderful screening tool - and while I am not sure how that will scale
- that has been my experience with this approach too.

I will definitely continue hiring freelancers like this....by the way, I only
did this after I looked through his Github account and checked out any
projects and web properties he had online. That's the first line of screening
from my perspective.

Edit 1: I thought I should add that I think that this worked so well for me,
because this was a problem that I had been tackling for weeks and couldn't
solve. So I was intimately familiar with the inner workings of the problem and
so could fully appreciate the solution.

------
dk8996
This is the one I got just recently. You have one min draw me Twitter
architecture ... GO!

------
giociferri
Job interview have to change because the jobs are changing, possible startup?

------
dustingetz
the other way is to build up a github and speaking portfolio. not only will
this get you almost any job, but it makes it so obvious that you're good, that
you get the upper hand in negotiating.

------
snambi
100% agree. most hires through the traditional process are bad hires.

------
jebblue
I felt like I was reading something I wish I'd written, thanks.

------
sebnukem2
This makes me feel so much better about myself.

I'm not alone.

------
beefxq
Fish oil will help with anxiety issues.

------
pkrumins
I will. :)

------
beachstartup
quit giving away my hiring secrets!

the brainteaser-whiteboard-fizz-buzz-5-member-panel interview is, and has
always been, highly unreliable, if only for the sole reason that PEOPLE GET
NERVOUS. gee whiz, what a concept. back here on earth us mere mortals have to
deal with things like nervousness, forgetfulness, and intimidation on a
regular basis.

let's not forget sociopaths or assholes in a bad mood who deliberately try to
make people feel nervous. they exist. that's a thing. i've seen it with my own
eyes.

it is an unreasonably strict high-pass filter that gives false negatives
people who are otherwise perfectly valid for developer jobs. that's great if
you've got millions or billions in the bank and have carnegie mellon grads
lined up out the door. that's awful if you've got $50k in the bank and you
need someone competent working on things yesterday.

SO much value can be won by hiring people who can't or won't deal with this
kind of scenario. on both sides of the table.

------
amerika_blog
Hoop-jumping, including memorization-based education, just doesn't work as
well as real-world scenario tests.

We forget this at our peril.

The real reason we indulge hoop-jumping is that it gives a veneer of equality
to a process that (really) has more to do with natural gifts than
certifications.

------
bengrunfeld
Having gone through a fair amount of tech interviews, I really understand the
author's point. On another point, I just wish recruiters would put the salary
in the job offers. It would save everyone a lot of time.

