
Dear Programming Job Applicants (2010) - jacquesm
http://joshcarter.com/software/dear_programming_job_applicant/
======
twelve40
> He reasoned through the problem, wrote the code, it ran perfectly the first
> time. I hired him.

I get the overall sentiment, but come on, "I hired him" sounds like self-
absorbed anecdata - so this post is about how to quickly appeal to some
manager dude on the interwebs? A more useful metric would be, did this hire
survive the first two years, and what do the people around him have to say
about his performance.

> It’s funny how many people can’t edit text on any machine but their own

How often does this person himself get thrown into random-ass editors and
forced to quickly work through some rando algorithm while absolutely not
forgetting to eloquently detail out loud their entire thought process? Self-
absorbed, out of touch with how humans work.

~~~
skrebbel
Bullshit. It'll go like this:

Interviewer: here, a laptop with vi

Applicant: I've never used vi

Interviewer: just hit "i" to be dropped into insert mode, then just navigate
with the arrows and use backspace like in any other editor. Ask me when you're
ready to save and I'll teach you the magic incantation.

Applicant: _types away_

If you're not able to code in what's essentially just a test box then that's a
useful thing for an interviewer to know. It's a strong indication that you
don't fully grasp where the editor stops and the language begins, and unless
you're applying for a junior role that's a negative sign.

~~~
ericol
> just hit "i" to be dropped into insert mode, then just navigate with the
> arrows and use backspace like in any other editor. Yeah, no. Let me call
> bullshit on you calling bullshit.

I've been working as a mediocre programmer at the same company for the last 10
years. when I landed this job, I had never ever even heard of vi. I was
"gently" introduced to it by my boss, and eventually got to kind of get used
to a basic usage of it.

But in the box where our server run it is configured to highlight syntax,
maintain tabs and shit, delete deletes, you can move using arrow keys, and a
slew of other non default niceties.

Over the years I more or less got acquainted with different tastes of Linux,
and used and installed it in a few of my own boxes (Debian, mostly).

Even thought vi respects arrow keys by default now it seems (thanks god I
don't have to use hjkl. It is hjkl, right?) there's this conf issue that I've
never been able to fix _because I don't know how to formulated the question in
order to google it_ and it's the fact that when you're in non edit mode, _the
cursor never goes to the end of the line_, so if I have to let's say add a new
line, and the last word is `return;` I have to convert that to `return;;` put
the line jump between the 2 ;; and then remove the extra ;. Plus, arrow keys
in non edit mode add lines with crap in it.

I can't even fathom how stressfull would be doing a job interview under this
circumstances.

Force a person to use a different OS than they are used to? Well, may be. Even
thought I don't like nano, it would be a better choice than vi because at
least it beheaves as a "normal" editor.

force a person to use vi with default settings? thank you very much for your
time.

~~~
toyg
I had your same problem for years (I use vi extremely sparingly) and the
answer is “a” - which means “append”: it will go to the end of the line and
leave you in insert mode _after_ the last character.

Found out when I was looking for something else, and improved my quality of
life quite a bit. (I still hate distributions where arrow keys in insert mode
don’t work like any reasonable human would expect, but they are thankfully
getting thinner on the ground).

~~~
ericol
Yep, well thanks for that. But imaging having a job interview, you are forced
to use an editor you never in your life used and that _doesn't behave as a
normal editor_ and you can't even inser a line _normally_.

------
larkeith
Most of this is good, but one real WTF:

"Editor Flailing

It’s funny how many people can’t edit text on any machine but their own. I
tend to interview people on a laptop running Ubuntu, and I open gedit for them
to use, with the offer that they can use any other Unix editor they like. Most
can barely navigate gedit, and it’s stupid simple.

Don’t ever let yourself get hung up on the editor. If you can’t figure out the
magic command keys to indent code the way you like, just press the damn space
bar and indent it yourself. Flailing in the editor wastes time."

Talk about an arbitrary condition. Sure, being adaptable and/or pragmatic with
respect to tooling is a nice thing for your candidate to have, but to
prioritize it at a similar level to _knowing what your company does_?! Are you
really going to hire the incompetent-but-familiar-with-emacs Linux user over
the capable-but-rigid Windows dev? Unless you're looking for an SA or full-
stack dev, this seems rather arbitrary, especially considering the
availability of plenty of cross-platform, fully-featured editors.

~~~
emidln
This is a great reason to learn vi for basic editing tasks. It's everywhere.
Even if you typically use a different editor/ide, vi is a common ground.

Disclosure: I'm an emacs user

~~~
SOLAR_FIELDS
It’s kind of weird to NOT know basic vi/vim if you get to a certain point in
your career. If you can’t at least open the software, go into insert mode, and
save/quit, have you ever had to ssh into a remote server and edit a config
file before? Only excuse I could think of is if you literally did everything
in windows for your entire career.

~~~
npstr
What's wrong with using nano for that?

~~~
MayeulC
> It's everywhere.

It almost litterally is. Even busybox contains a vi clone. While I have
encountered more systems without nano nor Emacs than I can remember. Plus,
there is no excuse for learning the basic set of commands: i,ESC,x,u, and
maybe navigating with the letters (which I'm not proficient at).

~~~
GordonS
I only have to edit a file on Linux once every couple of months of so - I
tired of forgetting how to exit vi (or enter/exit edit mode, save the file...
just about anything really), so started installing nano as the first thing I
do on any system. Nano is _so_ much more obvious than vi.

~~~
nemetroid
Most people can't install arbitrary software on every system they access.

~~~
MayeulC
This exactly. I am pretty sure that if you gain [adb] shell access inside of
an android recovery partition (as a random example), you have read-only access
to the system, with only busybox at your disposal. Thus vi, but no nano.

------
battletested
So author, who are you? You start already with an authoritarian touch. What
makes you believe you are not an incompetent interviewer? How can an applicant
assess your skills, you could easily be the greatest fuck up in the company.
Is your company really that cool that I should want to die to work there? Did
you first weed out all the incompetent staff that is duck sitting there
playing business politics?

IMAO most companies are not any better than the applicants applying. And no,
you didn't hire only the best from all candidates, you just have a rich
imagination that favours your ego.

~~~
scarface74
And what makes him think that his company is so special that I would be
willing to deal with his attitude at the interview let alone accept the job?

I’ve rejected plenty of offers because I didn’t like the interviewer.

~~~
trickstra
I once rejected a company because they had a big framed picture with 4 naked
girls full frontal in the interviewing room. And because the manager pointed
to it saying how "open minded" the company is.

------
iamaelephant
"I'll spend hours brushing up on Scheme just to test you on something
completely irrelevant to the role just because I like playing Resumé Gotcha".

Yeah that's a thanks but no thanks from me. I wouldn't work for this guy in a
thousand years.

~~~
mrisoli
It's a good investment for the company, if the interviewer can red flag a
candidate who is blatantly lying on his resumé because the candidate would
assume no one would know said technology, it would save a lot of money from
cutting ties with an employee in a later stage.

As an anecdote, I used to work for a company and would require candidates to
know some Ruby, for one guy with several years experience in Python we changed
the requirements of the home assignment so he could write it using whatever he
wanted. he hands over a nodeJS application claiming he took the opportunity to
learn something new(why not Ruby?), seemed like it was well done, so we bring
him in for an interview, unlucky for him, there was one member in our team
with some nodeJS experience(me), having reviewed the code, I asked him to do a
minor feature addition to his own code, he froze, couldn't do it because he
didn't write the code(copying from some repo) and didn't know any nodeJS at
all, asked him to do it in Python instead and he still couldn't do it, he had
just spiced up his resumé with tech we didn't use to see if he could weasel
his way in.

~~~
wolco
Imagine he got the role and did well. Trying to find the perfect person
doesn't always work out as expected.

~~~
redbluegreen
Yeah, but lying to that extent is a huge red flag, not just saying your
Spanish is "mediocre" instead of "beginner".

------
spyspy
> So, your code isn’t working, what do you do? Stare blankly at the monitor?

This always gets me. When the interviewer asks a question, the correct answer
is literally never, “let me think about it quietly for a moment”. This is one
of the disconnects between interview programming and real programming people
get frustrated over.

~~~
mooreds
Hmm. The point of an interview isn't for an applicant just to solve the
problem, it's to prove they can solve the problem. I think saying "let me
think about it for a moment" is perfectly acceptable. But going quiet without
guiding the interviewer is not communicating what your plan is.

Not saying interviewing isn't broken in a myriad of ways, but asking a
candidate to talk through their process to illuminate it isn't unreasonable.

~~~
ubersoldat2k7
I have had such hard times with this. I find it very hard to think about the
problem and to think what to say to this person without fucking up the
interview.

I mean, you don't want to say: "I'm going to trial & error this shit while the
fucking compiler builds and the stupid tests say it works" which is how must
programming is done anyway.

~~~
mooreds
I wouldn't use those exact words, no :).

But hopefully you have some ideas on what you want to try (and what your
experience says you shouldn't, equally important) and talking about that
thought process is exactly the kind of data I would want.

------
choppaface
Oof, this is pretty antithetical to hiring. Author seems pretty frustrated. I
hope this guy takes a long vacation. If I’m a candidate, I’d say this guy is
clearly way overworked and I’d bail. Good points, but the volume of negative
sadly speaks louder than the rationality of the points.

I see there being two parts to an SWE interview:

1) What experience does the candidate bring? Do they have _compatible_ core
competencies? If yes, then what’s novel about their experience—- will they
help the team grok unknown unknowns? (And if the team’s burning issue is not
unknown unknowns... then how does the candidate’s background add to the team’s
creativity?)

2) How well does the candidate adapt on their feet? How effectively can they
communicate? (If English is not a primary language, can they still get an idea
across, perhaps using code instead of prose?). Can they code their way out of
a paper bag?

The interview session is the _interviewer’s_ responsibility to make the
strongest case possible for the candidate. Let’s say that again: the
interviewer needs to play doctor and _adapt to the candidate_. The interviewer
is getting paid, not the candidate. Only once that sample has been taken
properly can a hiring manager (who might very well be the interviewer..) begin
to make an effective prediction as to how the candidate might do on the job.

Folks, demand for SWE jobs far outweighs supply. And it’s gonna be that way
for at least another decade as universities catch up. It’s time to stop
discriminating for the wrong reasons.

~~~
GordonS
This is mostly agreeable, but you do need to actually _test_ the competencies
the candidate says they have.

As someone that's done aot of hiring, I can concur with the author that there
are _many_ poor candidates out there, many who grossly "stretch the truth"
about their capabilities and experiences. Unless you want to be lumbered with
a dud, some kind of practical test is a must.

> It’s time to stop discriminating for the wrong reasons

I wasn't sure what you meant was the discriminating factor here?

------
sklivvz1971
A few more things:

1) Be humble. Don't expect people to take it easy on you because you got
street cred (You are a ruby contributor? You still need to show them how good
you are at coding Ruby). Many people with creds get offended when they realize
they are not as good as their credentials would imply.

2) Know yourself. Most candidates I've seen, including myself, encounter a
moment in the interview where they get hit by the nerves. Know that it's going
to happen, announce it to the interviewer, recompose yourself, start again
when calmer. You are not going to fail an interview because you are nervous.
You will not succeed if you are terrified, panic, and shut up.

3) Explain your reasoning. The way you approach a problem, which is a large
part of what the interviewer wants to see is in your mind only unless you
vocalize it. With a good enough mental approach, you will get a lot of slack
on the actual code by most interviewers.

4) Interview your interviewer. Go prepared with smart, non-trivial questions
on the job and the company. Ensure your interviewer is an empathic,
intelligent, and humble person. Assume anything annoying you experience is
going to be relatively permanent at the job -- will that be acceptable or not?

~~~
trickstra
ad 1.) yes, being a contributor doesn't automatically make you good
programmer. But having 7 years of coding practice in several companies kinda
does, because why else would those companies have you for so long? Yet these
programming interviews are required even for them. Probation period is much
much more telling about a programmer than the 15 minute coding task.

~~~
eitland
> But having 7 years of coding practice in several companies kinda does,
> because why else would those companies have you for so long?

Several jobs in 7 years might very well imply several companies gave that
person a chance and then gave up.

I often got questions about that years ago, and it was completely reasonable,
at one point I'd worked in 4 different positions in 5 years. (There were good
reasons for it and I had good references so I just explained it and it was OK,
but I can easily see why they asked.)

~~~
trickstra
> gave that person a chance and then gave up.

Nobody "gives a chance" for a year. Either the problems were discovered during
the probation period, or they were not as bad. Definitely not so bad that
you'd have any chance discovering it during the interview. Besides, this high
fluctuation is quite normal in IT.

~~~
ThrowawayR2
You'd be surprised. A common scenario is that manager A hires a bad employee
but doesn't want to admit their mistake. Then they move on to another position
and the new manager B has to go through the lengthy PIP and termination
process.

~~~
trickstra
Yes, but say 4 times in a row? And 3 times without discovering how bad the
person is during the interview? That says something about the prediction power
of an interview...

------
mettamage
> I brought in a guy that hadn’t programmed professionally in years, in fact
> he didn’t even have programming on the first page of his resume. However, he
> had been practicing while looking for a job and he rocked my programming
> interview. He reasoned through the problem, wrote the code, it ran perfectly
> the first time. I hired him.

And yet, I have a computer science master with an 8.1 (equivalent to a 4.0
GPA) and companies like Spotify/Google won't even give me a chance to do an
automated online coding test.

> One other thing: if I ask for a program sample ahead of an interview, don’t
> even think about sending in code that doesn’t include unit tests.

I haven't learned about testing in school or at my previous jobs or freelance
gigs. Where's a good place to practice it? I mean, I know what assert does and
all but I don't have a strong mentality to write a unit test, unless I'm
writing code that is finicky like a Red Black tree, then I do write some
tests.

I hate these snarky posts, because I don't even get to an interview. In all
fairness, maybe I shouldn't apply to A-tier companies such as:

\- Google

\- Facebook

\- Spotify

\- Digital McKinsey (I did some business studies back in the day)

Shout out to Optiver and OpenAI for giving me a chance though. Optiver made me
realize I needed to brush up on my algorithms in the first place. OpenAI made
me realize that I need to brush up on my math.

~~~
RealDinosaur
I've written tests before, but there ain't no way I'm writing unit tests for a
throw away coding exercise that used 4 hours of my time already.

~~~
je42
usually for a coding challenge i include in the instructions to add unittests.
;)

since I consider the ability to write well designed unittests as crucial.

~~~
trickstra
Just writing a unit test for an existing code would actually tell a lot more
about the applicant's skills than a coding interview with vi. Or a task like
"here is 100 lines of code, there is a bug there, show me how would you look
for it". I wish more companies were doing these kind of coding tasks. Instead,
all we get where I come from is "write a simple todo list application in your
free time".

------
retrac98
Some people completely blank when they’re under examination like conditions.
It doesn’t make them bad programmers.

~~~
mooreds
Sure, agreed. Except in very special circumstances (devrel, prod system admin,
startup first hires) the ability to think clearly under pressure isn't key to
success as a developer.

That's why I think that a paid take home test is the best way to understand
how someone can program.

But the job of an interviewer is to get data any way they can, and the job of
the interviewee is to provide that data as best they can. For the interviewee
that means it is almost impossible to over communicate what you are thinking
when faced with a problem. (I know, it's not easy to do, I have been there.)
It's not natural or what you do when you are programming typically, but an
interview is not a natural environment, nor should it be.

~~~
rootsofallevil
Interestingly, I've heard people say: if you can't code under pressure then
you might not be a good fit here, to which my reply has always been:

If day to day coding in your company generates _my_ interview level of anxiety
and stress then you are 100% right that I would not be a good fit and you are
doing me a favour by not hiring me.

The problem is that some people don't realise just how stressful interviews
can be due to them not suffering that level of stress, anxiety etc. so it's
difficult for them to see themselves in that position.

~~~
mooreds
I interviewed for the first time in years in 2018 and hell yes it is
stressful.

I wish every hiring manager had that experience as it gave me a lot of empathy
for candidates.

------
fit2rule
Dear Programming Job Recruiter,

If I get your job, you and I are going to share our lives together. We will
spend a lot of time creating something new out of the ether, and it will be a
rocky, adventurous ride for both of us. Hopefully, you will be worth working
for. The job market is large - me coming to you means I'm interested in what
you have to offer, too.

If I accept your offer to spend a sizeable portion of my life working for you,
it will be because I evaluated your authority, calculated the effect that your
snark will have on my life, and decided it was worth it.

Programming interviews are where I can see, for myself, just how ignorant you
are of Putts Corollary. Don't know what that is? You just flunked the
interview. Got some clue about it, and have designed the interview to test me
on it, too? Great, we're going to be able to work together.

------
bitL
\- "Hey, I worked at FAANG or better, creating latest super-duper tech you use
daily, was featured on TV, got multiple awards etc."

\- "Let's see if you can do Fizz Buzz!"

~~~
bartread
> \- "Let's see if you can do Fizz Buzz!"

Yes, exactly. I'd like to verify that you can string a few lines of code
together to solve a trivially simple problem. This is not an unreasonable ask,
and I really don't care how impressive your CV is. If you can't solve fizzbuzz
you're not going to be able to solve any of the much more complicated problems
we wrestle with on a day to day basis.

~~~
GordonS
It's such a simple task, but in reality it's a fantastic way to weed out those
that really don't have a clue what they're doing. Saves a lot of time
interviewing.

~~~
bitL
...unless the person you are interviewing decides you are childish,
immediately walks away and doesn't respond to your mail ever again, and your
business goes belly up as you can't find anyone on the market with the skills
that person was bringing, essential to your business. Frankly, not sure why
anyone competent in the current climate should take you seriously if you
attempted that.

It's equivalent to asking a partner of another law company you want to join
you what were the most important things that happened in 1753 and then
rejecting them because they didn't know.

~~~
eitland
> ...unless the person you are interviewing decides you are childish,
> immediately walks away and doesn't respond to your mail ever again,

...in that case they just proved they were childish and I'd be happy to avoid
working with them.

> and your business goes belly up as you can't find anyone on the market with
> the skills that person was bringing, essential to your business.

I think you are overestimating the value of childish ex-FAANGs :-)

If someone is too full of themselves to write a FizzBuzz once they are too
full of themselves for a number of other tasks as well.

~~~
bartread
> If someone is too full of themselves to write a FizzBuzz once they are too
> full of themselves for a number of other tasks as well.

Agreed: and one of the related issues that's worth stating is the damage and
demoralisation to your team(s) that's likely to result, were they hired.

------
sys_64738
This interviewer seems to have a machoistic view of interviewing people. At
all times you should be treating people with dignity and respect, not trying
to nail them to the ground to see them flounder.

Interviewing people by waiting around while they plod away at a text editor
isn't appropriate use of your or the candidates time. You should be
interacting with the individual via talking to them. If they claim to be an
expert in TCP/IP then you can peel back the layers back asking open-ended
questions to see where the conversation goes. If they have the depth of
expertise then it'll become pretty apparent when you discuss the intricacies
of the topic.

Trying to trip somebody up with returning int V long is just redundant. That
is an mistake to make and will be trapped by the compiler at compile time.

To interviewers I say stop wasting everybody's time and focus on discussion
not exam style questions.

------
kissgyorgy
Honestly, the guy has valid points, but he is probably an asshole I wouldn't
want to work for. I appreciate getting valuable advice, but the tone doesn't
have to be like this. Maybe he is mad because of the "bad candidates", but
that is his job, so he should be able to handle it.

------
867567838694
I'd bet 10 bucks this guys built one shitty ass team of people and I'm not
even talking about their programming skills. He's so caught up in being cheeky
and a dick he shows how unskilled he is at building an actual performant
cohesive team that works well together. He's not building a team of robots,
well maybe he is. I'd bet another 10 bucks his salary/hourly rates are also
sub-market.

------
thih9
Looks like the author favours candidates that are able to adapt to his hiring
process.

I think this approach results in too many false negatives. I prefer adapting
my hiring process, asking questions and/or helping.

I feel that this makes it easier for the candidate to demonstrate their
skills. Staying humble helps too.

EDIT: it’s possible that this article doesn’t represent author’s current
opinion; we should add „(2010)” to the title.

------
Uptrenda
This guy seems like the kind of interviewer to quiz you on how to type-cast a
binary-void floating function-function pointer array to a U64_INT_WIDE TCHAR
and then fail you for not using the right number of spaces in your code.
Lmaoo. Would not work with / 10.

------
ekzy
> It’s funny how many people can’t edit text on any machine but their own. I
> tend to interview people on a laptop running Ubuntu, and I open gedit for
> them to use, with the offer that they can use any other Unix editor they
> like. Most can barely navigate gedit, and it’s stupid simple.

No, it's not funny. Accessibility is important, what if, for example, the
person is used to a different keyboard layout?

I would always encourage people to use their own machine and setup. If a
programmer is uncomfortable on a different machine that might just stress them
out and ruin the interview.

Also, you could be missing out on some hidden skills. I could show off some
ninja moves in sublime text or emacs, or in my customised shell, but I'm
pretty sure I'd suck on a fresh ubuntu in Gedit.

I agree that most programmers should be able to ssh into a server and edit a
file without any issue, but that's different from completing a programming
task. It's like testing if a tennis player can ace a serve with a golf club.

~~~
myhf
This is why I bring my split ergonomic keyboard with dvorak firmware to on-
site interviews.

------
_pmf_
The thing is that the candidate does not know if the interviewer falls into
the pragmatic or dogmatic camp. I've absolutely had cases where the
interviewers insisted that the applicant was proficient in a specific compiler
toolchain + hardware debugger setup (for pretty generic embedded ARM where
skills transfer nicely from other commerical ARM ecosystems), and cases where
the interviewer gets hung up on coding style.

So, yes, I'll fiddle with the editor, because I'm not a fucking mind reader.

Besides, putting the candidate into gedit and then talking about debuggers is
a bit inconsistent. If you put me into this situation, I'll of course use
printf() debugging, whereas in a familiar environment I'd use the debugger.

------
GoToRO
Summary: if you don't know little thing X for sure you can't do Y! now and
forever! because Y can no longer be learned!

 _" you can’t program anymore"_ and forever?

 _" can’t edit text on any machine"_ and forever?

 _" can’t figure out the magic command keys to indent code"_ and forever?

He sees the developer as having static knowledge that somehow, in the very
moment of the interview, becomes frozen in time and nothing can be done about
it.

I should copy/paste this article and change the name "How not to hire -the
best-"

~~~
GoToRO
Oh, after they complain about everything that is not really important, they
spend 2 weeks to create a user/pass for you and months to learn the project
because the senior left.

------
alanfranz
If you interview for Java or C# positions, editor matters. Give me an IDE.
It'll take me hours to get the details right, because I'm used to the IDE
fixing it

------
Jemm
"if you haven’t been programming for a while, you can’t program anymore."

I do not agree with this at all. For a person who has a proper understanding
of how a computers works from the basics, getting up to speed on any language
and paradigm might take a short time but telling a person they cannot program
anymore is complete BS.

Ok, object oriented environments are now more common but so what; they were
invented 50 years ago and most of us have had some exposure to them at least
on a general level.

So telling us we can't program anymore because we cannot pick up your laptop
and your editor and toss out a program in five minutes is not a test of the
person, but more designed to make the tester feel superior.

I am happy that I do not have to interview with Josh Carter.

~~~
slyall
He doesn't mean that you don't know the JavaScript framework of the week.

He means if you have not been writing any code regularly recently (because you
have been a Manager or Architect or whatever) then your programming skills
will be rusty. You will struggle with FizzBuzz because you have have spent
less than 5 hours programming in the last 12 months.

------
SergeAx
This brought me to full stop:

> it’s worth a few hours of my time to prepare for an interview

So, how many interviews he did in one week? 1 or even 0.5? Today typical
manager with 2-3 open positions performs no less than 3 interviews a week. I
personally will not spend all my time learning some irrelevant languages or
frameworks just to show off in front of random people passed through HR
screening.

------
daniel-s
> I’ll brush up on Scheme myself just so I can give you a Scheme programming
> question.

That's when I realised the author was quite obviously lying.

------
craftoman
>Write code on Gedit?

That's fascism, what's your problem if I write my code on CLion? Should I
write code on a hipster typewriter and scan my printed document straight to
the compiler? Does that make me a qualified programmer?

------
je42
> if you say you’re a master of network protocols, guess what, I’ve maintained
> a TCP/IP stack, and unless you’re really a master I’m going to bury you.

yep. :) all lot of applicants should take a note at this.

------
ordinaryperson
> If you say you’re a master of network protocols, guess what, I’ve maintained
> a TCP/IP stack, and unless you’re really a master I’m going to bury you.

The goal of interviewing is never under any circumstances to "bury" someone
with obscure, difficult questions. Even as the OP is obviously impressed with
his own skill set ("I've maintained a TCP/IP stack") I'm sure someone coming
from a different vantage point could stump him easily, there's too many nooks
& crannies of a field that vast.

> I’ve interviewed several people that couldn’t write Fibonacci sequence. I’d
> tell them what it was and write on the whiteboard the first ten numbers so
> they could see it. They’d start typing and immediately go into the weeds.

There's a lot of pressure in the live format to produce right away. Maybe you
should consider take-homes instead of instantly assuming the candidates lack
your superior communication and abstract reasoning skills?

> Don’t make me point out cases where your code breaks.

Right. I'm sure you've never written a bug in your life -- especially as a C
programmer.

> I tend to interview people on a laptop running Ubuntu, and I open gedit for
> them to use, with the offer that they can use any other Unix editor they
> like.

I run Ubuntu desktop but why throw someone out of their comfort zone? Just ask
them to bring a machine, or remote into a Google Hangout. The point of the
interview is not to surprise candidates in unknown environments then feel
superior because they don't know what you know.

> ...I ask if you’ve got questions for me, and you say, “so what does your
> company do?” the interview is over.

If it's cheapfurnaces.com, sure. But most companies it's not completely
obvious what the company does exactly, even if you browse the company website
or LinkedIn -- don't be so snide in your assumptions the candidates did no
research on the company first, maybe they're just not articulate in their
phrasing when asking what exactly a company does. They applied for a developer
role, not to be CEO. This seems like an arrogant position to take.

> I’m not trying to beat up candidates because I’m a sadist, I’m looking for
> people I want to work with.

There's also a fair amount of chest-beating going on here, IMHO. The OP
doesn't just want to assess the skill level of the candidates he
simultaneously wants to assert his own perceived superiority ("most
programming job applicants suck").

OP should consider acting more humble and try to demonstrate more empathy
toward others -- often it's not the candidates "sucks" but his or her
particular skill set or career level isn't ideally suited to the open role.

~~~
LandR
Exactly, it sounds like this guy sees interviews as a way to feed his ego and
make himself feel smarter than the candidate.

He would be a massive red flag to me as an indicator I don't want to work
there.

~~~
867567838694
Definitely a solid pass on a job here.

------
jsqu99
Programming _is_ like riding a bike...after a brief reimmersion. Maybe a
little wobbly at first, but it's never taken me long to jump back into
something that used to be an old friend.

------
Pierre-ch
The colleague who interviewed me later confided that i was the first he ever
had who brought his own laptop for the interview. Apparently, it is not
common!

~~~
clarry
Interesting, I brought my laptop to every interview for a software job I've
had. Figured that's the best way for me to show and talk about some of my
code, and maybe even code too if it comes to that.

------
rayraegah
The article was okay to read but calling people out for not being able to use
an editor you know how to use is low.

------
mooreds
Note this is from 2010, but still has many relevant points. As someone who has
made some of these mistakes, I'd say the tl;dr is:

Good hiring managers prepare for an interview, so you best prepare as well.

~~~
nzjrs
Depressingly, the difference between then and now is today's blog post would
be advice for how to ace your 3 part interview, each with a 1 hour coding test
and the take home project for which you are expected to sign an NDA

------
davidhyde
Something I don’t see enough of is developers who have a lot of recent
interview experience (as an interviewee) being the interviewer. These devs are
inevitably contractors so they are rarely chosen to be the interviewer in a
company. Rather, the team lead who has been there for years is chosen. The
thing is, as a person who has a lot of experience at being interviewed, I know
the mistakes that interviewers make and they never get to learn this
information. An candidate gets to correct their mistakes and become better at
the interview process in preparation for the next one they do. An interviewer
learns, 3 months down the line, that they have made some mistake but never
learn what went wrong.

Here are some common mistakes that interviewers make:

1\. Not testing the candidate’s argumentative skills. The interviewer should
take a questionable stance on a topic and see how the candidate argues their
point.

2\. Never testing a candidate’s ability to read and understand code. Without
this skill a candidate is more likely to reject your team’s existing code base
and rewrite things from scratch. Instead of asking them to implement an
algorithm (which, btw, they already may have practice doing - making the test
pointless) get them to read a lot of regular code. Not a complex algorithm but
something that spans multiple files and is quite large. It could be your
codebase or something you found on GitHub. “Tell me what this does” “Tell me
what you think is wrong with this code” “How would you change it?”. Being able
to read code and write it are two separate skills and both need to be tested
in the interview.

3\. Making the candidate feel uncomfortable. For example, two interviewers
against one candidate could make certain devs uncomfortable. Why is this
important? A developer is going to get settled in the team at some point and
feel comfortable. Wouldn’t you rather test them in that state rather than a
state they would rarely be in? Unfamiliar text editors, interviewers watching
you code; these are further examples. Sure, some devs are unfazed but others
are, and they may be good devs that an interviewer is chucking away.

3\. The interview should always involve a tech test and I strongly believe
that the candidate should be left alone to do the test. However, this depends
on how pair-programmer heavy the team is. Regardless, the most important part
comes later when going through the results. So many interviewers miss the
opportunity to question the interviewee on what they have written. It can be
quite distracting if the interviewer is constantly picking through the code as
it is being written.

4\. Not going through the candidates cv during the interview. This should
happen first and is part of the prep that an interviewer should make. As
boring and full of exaggerations as other people’s CVs sometimes are, it is a
good way to increase the confidence of the candidate so that the interviewer
can get the most out of them for the rest of the interview.

------
thrax
TFW Dwight Shrute is your programming job interviewer...

------
nobody271
I can feel the pain here but in my own way. As a hiring manager it must be so
frustrating to be assaulted with massive idiocy when you are looking for a
candidate. Think about it:

\- candidates have zero penalty for applying to something they know they
aren't qualified for

\- there's constant noise about getting one of those well paying "tech jobs"

\- everyone who has ever logged hello world to the console thinks they are the
best programmer in the world

\- people are desperate and will lie

\- the ratio of unqualified to qualified candidates must be 100 to 1

It must be like dying of thirst in the middle of the ocean. The one thing I
love about this, though, is the "senior developer" who hasn't read a book in a
decade and has to get a new job. ahahahahaha. The moment when that mountain of
BS collapses underneath them must be ga-lorious.

Also though, I get the feeling it's a different job market than it was in
2010. I'm still trying to understand what I think I see.

Languages seem to be able to cover multiple platforms now. Programming I don't
think is as technical as it once was. At the same time everything seems to be
a mess right now. Everything's broken. There's a million and a half frameworks
for everything. ...It's like programming as a field has become much more
broad, while simultaneously lowering in quality, with knowledge that was once
spent on technical mastery now being traded for either lower wages or domain
knowledge. So if you went to school and got a degree in programming that was
once pretty impressive but now you're just some dude who can "code".

