
A Tale of Two Interviews, Part 1 - javinpaul
http://www.youell.com/matt/writing/?p=785
======
aaronbrethorst
Make sure you read Part 2: <http://www.youell.com/matt/writing/?p=801>

------
Aloha
I shouldnt need a compelling reason to work some place.

I - need a job, presumably they need someone with my skillset, now obvious,
there are soft skill concerns, do I match the culture, is it going the
direction I feel my career ought to go? Other then that, it should be pretty
simple.

~~~
hmottestad
Since there are so many companies out there, giving some reason as to why you
picked this particular one seems fair.

I would usually go with something compiled together from separate things: \-
New challenges \- Location \- Their field of expertise \- Their culture

~~~
Klinky
This is where it can get murky. If you are firing off a bunch of resumes to
jump ship from a poor situation, honesty doesn't get you very far. While if
you were targeting the company from the get go, honesty is your best option.
It doesn't sound good to say "my current job sucks, and you guys responded to
my resume", but if you don't want to say that, then you will scramble to come
up with something that sounds like what you think they want to hear.

I can understand how a company wants someone enthusiastic for their
product/company, on the other hand I can understand how alienating it is to
have to bullshit about the reality of your situation.

------
auctiontheory
I myself have asked a candidate why he wanted to work for [my employer] in a
position of some responsibility, and been unimpressed by the reply "well, it's
a job." I had no idea this was a commonplace response.

It's good that you recognize from their feedback where you went wrong, but
it's bad that you don't understand _why_ "I just want a job" is a poor answer.
Your cynicism about "Cubicle Dream" also doesn't sit well. (Not trying to be
harsh - I know exactly where you're coming from, having been there myself.)

Here's a secret: in the workplace, unlike school, attitude trumps raw ability.
Every single time.

Think about what you really want. Maybe read _Ask The Headhunter_.

Good luck.

~~~
djhworld
I think his issue was he was bruised and battered after 5 hours of relentless
questioning that answering a question like that was the last thing on his
mind.

A 5 hour interview is a ludicrous amount of time to take out of someone's day.

~~~
coditor
If it takes someone more than an hour to determine a programmer's basic worth,
then they should fold up shop. The extra 4 hours is a waste of both side's
time. You won't really know how good the person is until they are working for
weeks or months so how to do you expect to learn this in 5 hours?

------
jaimebuelta
Let's not forget something. Interviewing is also an skill that you will learn.
If you are actively searching for job (because you're unemployed, or you
really want to leave your current job), you'll know what to expect and be more
confident and perform better on each interview. After the fifth interview, you
have already faced 90% of all those pesky algorithm questions. I don't really
believe in those kind of questions (other than for screening purposes)

Anyway, as a company, if you are able to create an atmosphere when
interviewees can relax and show "how they really are in a regular day" is a
great win.

~~~
faro1975
This needs repeating - interviewing is a skill you have to, and you can learn.

Like lsc below, I'm also a "mercenary". But probably much less competent and
maybe even better in interviewing.

My background is in humint which gives me some skills to "read" people, figure
out exactly how to build the trust with the interviewer, get them to like me
and even manipulate the conversation towards the questions I want them to ask
me... In my 17y IT contracting career, I didn't have a single interview that
didn't end up in an offer despite my significant lack of algorithms or
programming knowledge. Luckily, I didn't have 5h pair-programming interviews.

You can make it "click" with the company and you can manipulate their "gut
feel" to tell them that you would be the ideal candidate for the position.

It's not fair and it's irrational that people like me can get the job instead
of some much more capable developers, but that's what humans are - irrational.

------
jakejake
This article made me kinda curious - is it common to go into an interview
expecting to have to write algorithms? I've read about this frequently but
writing enterprise software I've found very little occasion to write
algorithms. I say _almost_ but I probably could just say that we never write
algorithms at all.

I'm not saying algorithms are unimportant, obviously a lot of the tools we use
rely on that type of skill. Just that enterprise software is almost always
more about workflows, schema design, UI layout, automating processes, etc.
Possibly some accounting math is used but generally those formulas would be
provided by the accountants anyway.

Is this just something interviewers are asking because it indicates school
training? It is just a benchmark of general awareness? Does it indicate
understanding of the simplistic recursion that some algorithms use? It seems
to me just testing plain old memorization of forumulas - it's not like I
expect the interviewee to have thought up the fibonacci sequence on his/her
own.

~~~
Evbn
Most people on net forums don't want to be in the enterprise software world,
even if they are.

------
gingerlime
One small thing I was wondering about - how comfortably can you drive in a
pair programming session on _someone else's computer_?

I mean, I don't mind being in the back seat on whichever editor the driver is
using, but if I'm driving, I really feel awkward without vim and my plugins
and key bindings etc...

~~~
wtracy
My understanding of pair programming is that the driver never even touches the
keyboard. Do I have that backwards?

~~~
gingerlime
I think you have it backwards. According to [1] at least:

 _"Pair programming is an agile software development technique in which two
programmers work together at one workstation. One, the driver, writes code
while the other, the observer or navigator, reviews each line of code as it is
typed in"_

[1]<https://en.wikipedia.org/wiki/Pair_programming>

------
jrs235
The Internet lawyer in me gasped when I read he was pair programming,
especially driving. Did he sign a transfer of IP rights and copyright
beforehand? Placing his code into production? He still owns the copyright on
that code...

~~~
mdellabitta
It was a work for hire. He got paid in lunch.

------
drstewart
I've had both kind of interviews before, and the latter made me want to work
for the company so much more. Ever since that interview, it's how I conduct my
interviews now -- no more whiteboards or pointless algorithm questions, I just
bring in my laptop and we work on something together.

------
azov
Interview is a two way street, they interview you, you interview them.
Basically, you just didn't like the first company and clicked with the second.
Don't put too much weight on the interview style. If they didn't extend you an
offer, chances are it would be even more frustrating - it's harder to figure
out what went wrong with the second interview as they are relying more on the
"gut feeling". The first one is a bit more systematic. Both styles can work
fine.

~~~
megablast
I think there is a lot more to it than that. I have been to interviews which
were almost hostile like the first one, and the opposite, where it was almost
a conversation.

I do not understand people who do the first type. Why? The interviewee is the
enemy.

~~~
DavidWoof
Sure, but read closer,and you'll see that the impression of the two interviews
is based almost entirely on the subjective terms the writer chooses to
describe them. One person was the "shark on the team" whose questions got
"very aggressive", while the other was "intimidating but tolerable" and "I
could tell he was protecting the quality of his team".

Or consider "Instead of demanding from me why I wanted to work there, he just
tried to get a feel for what I was aiming for."

Was there really a difference, or did the writer just click personally with
one group and not the other? If it had gone differently, I could imagine him
writing that "team one was respectful of my time and allowed me to order my
favorite sandwich and eat during the interview, while team 2 expected me to
waste yet another hour socializing with the group at a bad restaurant, where
they got very aggressive asking about my personal life".

So maybe company one really was hostile; just like you, I've seen that happen.
OTOH, maybe it was just a personality clash, or maybe some of it is slanted by
the fact that he got an offer from one and not the other. In my experience,
once an interview process starts to go bad, I start to see everything the
company does in a bad light, and vice versa.

------
kragen
This is cool. At one point I worked at a startup where they hired a guy who
interviewed well but froze up constantly when pairing — sort of the opposite
of this story — who consequently didn't work out. Seems like pairing-as-
interview would solve both that problem and the freezing-up-at-whiteboard
problem.

I admit to being sufficiently extraverted and borderline autistic myself that
I don't have a good understanding of why people find his "part 1" interviews
stressful and freeze up. I mean, it's just talking to hackers, right? I like
talking to hackers. Who doesn't like talking to hackers? But I guess standing
up and talking in front of a bunch of people, or being grilled to see what you
understand and what you don't, is a lot more stressful for most people than it
is for me.

------
proksoup
Hm, I thought ~ 5 hour interview process wasn't uncommon?

~~~
djhworld
Must be a US thing.

My first job had an interview that lasted around 2 hours.

The second had one interview that lasted 90 minutes, then a follow up
interview a few weeks later for 90 minutes.

Taking up 5 hours of someone's day (especially if they are unemployed) is
wrong and downright pathological. Job seekers are often desperate to get back
into the market and abusing their time is grossly unjust. It's fine for the
interviewer, they have a job and are in a position of power to decide the fate
of the interviewee.

~~~
pbiggar
Not sure how its abusing their time? In any company I work for, I want to
ensure that people who join my time are going to be good for my team and the
company. You're going to be working with an individual for years hopefully,
and the cost of getting rid of bad hires is really high: shouldn't you spend a
few hours to make sure they're the right person?

------
archagon
Man, I'd honestly find example 2 more stressful than example 1. Is pair
programming really something that programmers find useful? Should I develop
this skill more? I've barely had to do it at all at my jobs, and when I have,
it was difficult for me because I couldn't get into my usual flow. Even with
an extra pair of eyes and hands, I felt like I was working at 50% efficiency.

I guess I should read up on concurrency. :)

~~~
aaronbrethorst
> Is pair programming really something that programmers find useful?

Some do. Some people swear by it.

> Should I develop this skill more?

Yes, definitely. Think of it as being a more social version of learning a new
programming language or systems architecture.

> [I]t was difficult for me because I couldn't get into my usual flow. Even
> with an extra pair of eyes and hands, I felt like I was working at 50%
> efficiency.

It's definitely an acquired skill. If you think about it, though, if you're
spending most of your time while programming engaged in typing, odds are
you're probably doing something wrong (or working in a ridiculously verbose
language ;)

~~~
seanmcdirmid
> If you think about it, though, if you're spending most of your time while
> programming engaged in typing, odds are you're probably doing something
> wrong.

He didn't say anything about typing. Pair programming is meant to be slower
than alone programming, the extra eyes and ears actually slow you down because
you have to reach consensus so often.

Pair programming is about quality, not productivity.

~~~
jtheory
And quality is in turn at least partly about productivity (i.e., it's usually
faster to avoid the bug than to fix it after the fact).

~~~
seanmcdirmid
It really depends if you need the quality or not. Also consider Gabriel's
"worse is better." Anyways, doing pair programming can be considered as
another tradeoff (as you more than halve the productivity of your team); it
shouldn't be valued as always a net positive.

~~~
jtheory
Yup; lots of variables to play with. As long as we're actively aware of the
tradeoffs (and adjust approach as needed) it's all good.

I don't personally find pair programming very useful most of the time, though
I've done it now & then... though I do benefit from the half-way version,
which is to occasionally talk through problems I'm working on with other
developers (in detail, with code).

~~~
seanmcdirmid
I personally benefit from the rubber duck approach, but I'm a researcher
without so many people to talk to.

------
antoniuschan99
Read it. Awesome! So you what happened to the Startup? Did it fail?

------
kevin_morrill
Seems like this issue with the first job is you just weren't that passionate
about the company.

The worst thing you can do is trick people into hiring you. You'll waste
precious months/years of your life.

~~~
megablast
Most people are not passionate about a company. How can you be passionate
about a company you have never heard about, for people you have never met
before?

------
GoranM
Is there really a need for a phone interview?

I mean, you could just look at their github, and the writing on their blog, to
determine if there's a baseline of competence.

~~~
henrikschroder
I know this sounds crazy, but hear me out:

The vast majority of talented programmers neither have a github account, nor
do they keep a programming blog.

~~~
imalolz
Upvote, beacuse I see myself as a descent programmer and my github account has
been idle for ages.

Not to mention that holding a full time job and my wanting to spend time with
my wife and kid leave very little time to maintain a blog (which I don't) or
contribute to OSS (as much as I can, but next to nothing compared to other
readers of this site).

