

Today's Coding Interview Game - grayhairmomma
http://www.shubharamani.com

======
aristus
I worry a lot about this. I don't think it's distrust so much as
thoughtlessness.

From what I can tell, Google (and other companies) started using these kinds
of questions as a way to cheaply filter sudden floods of applicants, _not_
because this is the way to find the greatest geniuses of our time. Policies
implemented under the gun have two unfortunate properties: they are wasteful
and hard to change after the fact.

As the tactics of successful companies percolate through the rest of the
industry, they take on a third unfortunate property: cargo-cult foolishness.
Google asks binary search questions and they have great engineers. I want only
the best engineers, therefore I will ask binary search questions. I don't know
what else to do so I shall grade strictly on style points, because points are
scientific, right?

Bleh. Put it another way: if there are a large number of productive creative
people shut out by a culture of thoughtless interview checklisting, that's an
opportunity for some smarter company to snap them up. Such a company would by
necessity have an outlaw air about them. Who else would hire misfits? But
gangs of talented misfits can be a powerful force.

~~~
sokoloff
Thoughtful comment, but there's a practical problem with your last point: how
can YOU (as a hiring manager at this "some smarter company") effectively
filter through the enormous set of screened-out candidates that Google
rejected and find those productive, creative misfits that you want to
interview/hire out of the teeming throng of vocational misfits?

Of the people actively applying for jobs at any given point in time, the
"truly excellent" are under-represented as compared to the total population of
programmers.

I'm not a Joel fan boy, but I think
<http://www.joelonsoftware.com/items/2005/01/27.html> states this problem more
clearly than I can in a few paragraphs on HN.

~~~
tgflynn
If I were looking to hire a developer I would do the following :

1) Select a set of candidates based on their resumes making the assumption at
this point that their resumes are honest. Good candidates should have at least
worked on some interesting projects so their resumes should look interesting.
Most lame candidates wouldn't even be able to invent a credible interesting
project.

2) Do phone interviews where I would ask knowledge based (ie not problem
solving based) questions related to their resumes. The goal here is mainly to
filter out fake/exaggerated resumes.

3) Invite the selected candidates to give a presentation on a topic of their
choice related to work they've done that is at least marginally relevant to
the job. I think you can learn a lot about someone by seeing how they present
their work and respond to questions (though it doesn't tell you if they're
good coders, that's for the next step). The presentations could probably be
done remotely.

4) Hire the selected candidates for short-term contract work. Set things up so
they can work remotely. Assign them real tasks that you would expect them to
perform in the job.

Make final selection based on evaluation of the candidate's work on step 4 and
offer positions to the best.

~~~
btilly
I'm sorry, but this process would not work.

You are basically filtering for presentation ability. But 3/4 of programmers
are introverts, and giving presentations is simply not part of their job.
You're therefore selecting for the wrong skills until the contract step.

At the contract step you create another problem. Good programmers who want to
be employees probably already have jobs and are somewhat risk adverse. That
kind of person won't find the option of a short-term contract with no promises
at all enticing.

Remember, as bad as the economy is, the economy for programmers right now is
pretty good. And as annoying as the coding interviews may be, really good
candidates don't have too much trouble with them.

~~~
Xurinos
_You are basically filtering for presentation ability._

...unless you are looking to hire someone in sales or someone to represent
you. :) But I agree with you.

For something like software development, I think the presentation process can
be improved by talking to the candidate as part of the presentation, not just
letting them starve in front of an audience. Let's not rule out the
presentation mechanism; you can learn about the candidate's ability to give
presentations and handle pressure.

~~~
tgflynn
Also the candidate would be evaluated on the content of the presentation - not
his presentation skills per se.

------
aplusbi
I've interviewed a lot of programmers and I think there are many
misconceptions about what an interviewer is looking for or expecting.

I don't expect you to be able to code quicksort from memory. I do expect you
to be able to code quicksort given the spec for it.

Just because I point out an error doesn't mean I'm counting it against you.
I'm pointing it out to see how you handle it.

I do expect you to ask questions. If you are unfamiliar with an algorithm or
forget the details, ask. I may not give you the answer but I'll at least point
you in the right direction.

I generally try to make this clear to candidates so that they don't get
uncomfortable if I point out some problem, but a lot of interviewers don't,
which can be hard on the interviewee. I doubt, however, that there are many
who expect perfect code on a whiteboard.

It's as much about the process than the result.

~~~
timcederman
I feel exactly the same. Don't try to make stuff up you don't know, do ask me
questions, do just TRY, rather than noodling about and not saying or doing
anything.

~~~
mech4bg
The thing that sucks is when the interviewer doesn't care about that, but
instead cares about specific answers to their particular list of questions.

It can be astonishingly random who gets through an interview. Bizarre that
just a few words can tip the balance.

------
mavelikara
My theory is that many other technical fields have high barriers of entry
where a newcomer has to really prove her chops, usually with a certification
exam, before being allowed to practice the profession; but once she starts,
fellow professionals treat her with respect and take it as understood some
minimum capability.

In programming, almost anyone can start on the job - but we play out the
hazing ritual throughout entire careers. Every time a programmer has to change
jobs, she has to face a barrage of pointless trivia questions from
megalomaniacs. Of course, many of them then grumble that they can't find
competent programmers.

Also, I think that the interviewer anti-loop that Steve Yegge mentions
([http://steve-yegge.blogspot.com/2008/03/get-that-job-at-
goog...](http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html))
is real.

 _Well, back when I was at Amazon, we did (and they undoubtedly still do) a
LOT of soul-searching about this exact problem. We eventually concluded that
every single employee E at Amazon has at least one "Interview Anti-Loop": a
set of other employees S who would not hire E._

------
sblom
If you remember what a linked list is, how pointers (or references) work, and
have written more than 10k real world lines of code in your favorite
programming language, I would fully expect you to be able to write, not
memorize, any of the linked list functions that you mention.

I certainly understand your frustration, but I really don't think either the
tone or the content of this blog post is going to help land a job in this era
where hiring managers ask Google what it knows about a candidate.

~~~
blahedo
But possibly not error-free the first time at a whiteboard. Talk about
unrealistic conditions.

~~~
angelbob
Sure. And a good interviewer should take that into account. I ask this kind of
question ("write me code to reverse this linked list, re-using the existing
nodes") quite frequently. I don't expect even experienced programmers to have
memorized it, and it's (a bit) more interesting than it sounds.

While I _do_ give mental brownie points for people who can just write it in
one go, I don't consider it a non-starter if you can't. But if you can't get
to the point of having written it, with prompting and help, in half an hour,
that's a non-starter.

------
Evansbee
I feel bad for this lady, but there's a flaw in this logic (and with the logic
of many commenters here).

Everyone assumes that the battle is between...

Person 1: -Great resume -Relevant work history -Strong sense of corporate
citizenship -Can't code on white board

and Person 2: -Can code on whiteboard -Smokes crack in the bathroom

But the reality is, you're all interviewing for the same job! You're not
getting the job, not because you can't whiteboard code, but because someone
else has the same qualifications AND CAN whiteboard code.

Which would you choose?

~~~
j_baker
Unless I was hiring a professional whiteboard coder, I would find another
method.

~~~
Evansbee
I believe that /this/ is short sighted.

I do interviews, I care less about the right answer than I do about the
problem solving approach. I interview electrical engineers and I make them do
simple transistor problems. If someone gave up and said that they couldn't do
it without some sort of SPICE program, I'd cut the interview pretty short. But
if the fundamentals are there, even if they don't remember something stupid,
knowing how they approach a problem and if they know how to ask for help is
more important.

Every time someone says "I didn't get the job b/c I couldn't do a linked list
on the whiteboard." I'm fairly certain it was more than that.

~~~
j_baker
My point is that a person's inability to code on a whiteboard has little to do
with the value they can provide to the business. Some people just aren't good
at it, and why should they be penalized for it? There are other ways to get
programmers to write code in an interview, and a simple "Do you prefer to code
on the whiteboard or on a computer?" can resolve this. It's not as though
that's a huge burden on the business or the interviewer.

~~~
btmorex
I've been doing a lot of interviewing recently. When people struggle with a
white board problem, I give them a laptop to code on. I have yet to find
someone who struggled at the white board, but did fine on the laptop. Maybe
they exist, but I tend to think there's a high correlation between white board
performance and laptop performance.

------
jchonphoenix
I understand where the author is coming from because many interviews questions
are unreasonable and test absolutely nothing.

However, if someone couldn't code a linked list on a whiteboard, I'd be
severely worried. Same goes for a binary tree. If you know what a linked list
or binary tree is, you should have no issues figuring out how to represent
them with code in 10 minutes.

The other trickier problems are there to test problem solving ability, which I
believe is a valid thing to test.

I think the reason for this style of interview is that companies are afraid of
false negatives. They'd rather reject 95% of the qualified people and 99.9% of
the unqualified people rather than 94% qualified and 99.5% unqualified.

Additionally, swearing all over the place never helps your case...

~~~
rsl7
Code on the whiteboard is counterproductive at best.

Let's hook up your laptop to the projector so I can get a glimpse of how you
interact with your computer. I learn more about you by seeing your
relationship with your text editor, how you look up information you can't
remember, etc. Not watching you sweat with a marker in your hand.

~~~
ssp
_I learn more about you by seeing your relationship with your text editor_

Are you sure you are not just learning whether the candidate is superficially
similar to you?

~~~
weaksauce
well a programmer that is coding a linked list in c/c++ probably(definitely)
should know the pointer semantics. If they are looking that up then they
should be a pass unless you are looking for a really junior programmer. Now if
you are asking them to connect to a db and update a record with a stored
procedure and they looked up the syntax for a db connection to a mysql
database then you know they are fairly proficient at that type of coding but
just forgot the exact syntax of a db connection because it's not something
done every day whereas any c programmer worth their salt should know basic
pointer rules.

~~~
Retric
Any language I have not used for a while get’s tossed out of the buffer, and I
need to lookup even the most basic of syntax when I start coding in it. Once I
get going I can easily recall if it’s *, &, ->, or ^ but at the start I really
do need a refresher.

PS: Oddly enough, I have little issue working on a multi language programs,
it's just I think in terms of pointer not C pointer.

------
nowarninglabel
Coding general solutions should be par for the course. I agree that some
interviewers are coming up with contrived examples. But of the 6 data points I
have now from hiring people, those who could code on the white board turned
out to be good employees (4 of them) and those who could not turned out to be
a vast waste of time (2 of them). As jconphoenix was alluding to, I would have
rather ended up rejecting more of the qualified applicants than ending up with
a time-wasting employee.

~~~
hackinthebochs
I don't really understand this mentality. Is is really that hard to get rid of
the charlatans that slip through after the fact? Just monitor them fairly
closely (but secretly) for a couple of weeks. Have some sort of object measure
of performance for that time period. If they don't pass muster, get rid of
them. This seems like a better method than spending 6 months to fill a couple
of positions.

~~~
hc5
Training and getting someone up to speed for a few weeks, then getting rid of
them (if it doesn't work out) wastes more time and money than spending several
months to fill the position with the right person. Laying people off for
performance is hard to quantify, not to mention I certainly wouldn't want to
be working for a company who is _secretly_ monitoring new hires' performance.

~~~
philwelch
Some organizations _openly_ set out the first few weeks or the first month or
two as a probationary period for new hires, but you're right about the cost
effectiveness to some extent. A six month recruiting process might cost a few
hours or days every so often from a few employees, but won't add up to even a
single month's pay for a bad employee. Add in a cultural practice of risk-
averse hiring (don't hire any B or C players) tilts the scales even further.

That said, I can imagine some cases where opportunity cost and being more
concerned about getting good employees than immediately weeding out
potentially bad employees would lend one to the probationary thing.

------
edw519
_on a white board, no syntax errors, compilable_

Huh? You're worrying about whether or not what you write on a white board will
compile? How do you know? Press a magic button to OCR what you've written,
download it into some computer somewhere, and compile it? Sounds like you're
interviewing at firms with technology I didn't know existed.

Your interviewers have you code on a white board so that they can evaluate
_you_ , not your code. They want to see how you handle a problem, how you
approach your work, how you think on your feet, how you deal with interaction,
and how your intelligence and experience applies to their business. Anyone who
worries about whether white board code actually compiles is missing the point.
If they're more interested in perfect syntax than embracing you and your
potential contribution, then you don't want to work for them anyway.

I think you're making this too hard on yourself. Memorize nothing. Just be
yourself. Programming is like riding a bike; once it's part of your DNA, you
don't have to worry about it. Just relax, trust your inner programmer, and let
this become a self-solving problem; some jerks may reject you, but the right
fit will come when someone sees who you really are.

~~~
bmj
I agree, though I think, perhaps, the author has a point about something. It's
one thing to be asked to write code on the whiteboard for a practical problem.
During the interview process for my current employer, I was asked to sketch
out a database design for a given application, including actually writing out
some of the SQL to generate the tables, constraints, etc. I was then asked to
write queries to pull reports against my schema. I was also asked to show some
code to pull said queries from the database, in the language of my choice.

Those sorts of questions seems appropriate for the position in question.
Asking me to implement a linked list or binary tree? Not so applicable. Might
I use these sorts of things? Yeah, but the senior engineers assume I know how
to use Google.

~~~
aplusbi
It's often hard to ask relevant questions that will fit into the time allotted
for an interview. Your DB schema example is a good one - it shows that the
candidate can design (and to a lesser extent, implement) an application. Your
example (I'm assuming) is missing strong algorithmic problem solving however.
It would be good to have an additional question to test this kind of
knowledge.

It's also important to realize that most technical interviews are really about
weeding out bad candidates than finding good ones.

It may also be necessary to have questions general enough that any given
candidate stands a chance at solving it. If a candidate doesn't have SQL
experience your example would be bad (assuming the company didn't require SQL
experience).

This is why you see questions like "implement a binary tree." Any competent
programmer should be able to implement a binary tree. If they have never seen
a binary tree before, they are simple enough to describe in 5 minutes.

I once asked a candidate to implement a trie. He had never heard of a trie
before so I drew one on the whiteboard and briefly explained it. He asked me a
few questions and then proceeded to implement one. We then discussed the pros
and cons of different methods to store the nodes (vector, list, map). It
showed me that, given a spec, he could code a data structure and the following
discussion showed me he understood memory and time constraints.

~~~
bmj
Good points, but, how many interviewers would severely penalize someone for
not even knowing what a binary tree was? I think explaining the tree and
asking for an implementation could be a fair question, but only if the
question assumes that the implementation is the important bit.

~~~
aplusbi
Also a good point. I'd be surprised if a programmer didn't know what a binary
tree was and would certainly consider it a warning sign. I would assume that,
given a description, they probably wouldn't be able to code one (or code much
of anything). However I'm willing to be proven wrong and if they were able to
implement one I would be pleasantly surprised.

Of course, I can only speak for myself. I'm sure many programmers would
immediately write them off.

~~~
stcredzero
_I would assume that, given a description, they probably wouldn't be able to
code one (or code much of anything)._

That's a pretty glaring assumption, especially since it's subject to empirical
verification. It also contains an assumption of its own -- that all
programming needs a heavyweight familiarity with algorithms. There's a lot of
programming contexts where the productive programmer just uses a hash so the
mental bandwidth can be devoted to something else.

(FWIW, I do sometimes wish those programmers knew a little more about
algorithms.)

~~~
aplusbi
I agree that it is a glaring assumption, and perhaps is "culturally" biased.
Someone programming in Perl or Python, would probably be very familiar with
the built in data structures (hashmaps, dictionaries) but may not be familiar
with others.

And this is exactly why I would give the programmer the benefit of the doubt.
If they are able to implement a binary tree then I wouldn't hold it against
them (and I hope most other programmers would extend the same courtesy).

However I have never met a programmer who did not know what a binary tree was.

------
skybrian
I wonder how he knows what they're downgrading him for? Most interview
processes don't give the candidate any feedback - just "hire" or "no hire".

From the other side, I certainly don't expect perfect code on a whiteboard,
especially if they're typical mistakes that even experienced coders sometimes
make.

~~~
varjag
> I wonder how he knows what they're downgrading him for?

She. And yes, probably she knows. One usually has the feeling which part of
the interview they fail.

~~~
grayhairmomma
Oh I always know why I'm being downgraded. During whiteboard coding sessions,
I often need hints. But given these hints, I get to the answer most of the
time. In this economy, everyone is looking for "A" players. My blog post says
that. "Today’s interviews seem heavily geared toward software engineers who
rarely need to look stuff up. Those who code at an alarmingly rapid rate, who
get complex code compiled and running the first time around.". So sorry, but
this does not describe me. Nor does it describe the majority of good
programmers out there ! But interviews do seem to screen for these whiz kids.
Joel Spolsky said it right -- top notch "A" player software engineers don't
apply for jobs. They don't need to. Jobs find them. But does this mean that B
or B+ players are utterly worthless and unemployable ?

~~~
varjag
It doesn't, and am against sorting people into A, B etc buckets at all. Nor am
a big fan of interview puzzles in principle. Looking at how my grandparent
post sunk though, seems like an opposite came across to a number of people.

Good luck to you with job search.

------
mech4bg
I've had some astonishing questions asked in interviews lately. Very esoteric
and obscure parts of C++ that if you followed good design you wouldn't even
see or need to know about - and if you did, it's a short google query away.
Testing esoteric knowledge rather than actual intelligence and programming
ability is a complete fallacy imo. But then it goes even further at some
places where you have to do a psychometric test to get in...!

At least Google's interview questions (from what I saw) made sense in their
challenge. It's not stuff you would know from being an everyday programmer but
it's stuff a truly great programmer should know.

------
agentultra
Coding problems in interviews can be a put off for me (though not a complete
turn off if everything else about the job looks good).

1\. It shows unfamiliarity with my work. It seems rude to invite me all the
way into your office just to be filtered. In a perfect world (or at least the
one I knew some years ago) I'd be invited into an interview because you were
already familiar with my work and _wanted_ to talk to me -- not just to see if
I was worth talking to in the first place.

2\. Anxiety. I don't operate normally under conditions where everything I say
is being evaluated.

3\. They can be easily regurgitated.

4\. They don't really tell you anything unless you know what you're asking
for. I've been in interviews for web development positions where we started
getting into the finer details of C++, sorting algorithms, and file system
implementations. These are positions where I was being asked to write web
applications in Python. I've been writing web applications in Python for years
-- I don't think I've ever actually needed to implement a file system or even
write a sort routine (tim sort is pretty good and most sorting in web apps is
done by search engines or rdbms's anyway).

The problem is most people seem to think that since Google does it, they
should do it too. However, if you don't know how to ask the right questions,
you're just going to waste everyone's time. My time has been wasted in
interviews as the interviewee. Boring technical questions that lead no-where
and have little to do with the relevant skills for the job; often just for the
sake of asking technical questions and appearing smart. Anyone can do that
even if you yourself don't know the answers.

In a perfect world you wouldn't need to look at my resume to remember my name
when I walk in the door. You wouldn't need to bother "screening" me. You want
me to be there to meet me and see if I'm the right fit for the job.

But I also understand that businesses get a mountain of resumes and that some
large portion of them just aren't worth looking at. It'd be nice if there was
some way that you could at least know where to look in the pile for relevant
resumes. That way you could spend less time screening (how draconian sounding)
and more time interviewing. Sounds like a problem some decent software could
solve...

~~~
aplusbi
My company is currently in the middle of a lot of college recruiting. Most
college students/recent grads have very little to show. If you're lucky they
had the forethought to save some of their school projects and post them
online.

Even a lot of industry people don't have much to show. Plenty of decent
programmers don't have serious side projects (or aren't comfortable releasing
them to the public).

As for regurgitated answers, I keep my eye out for those. You can usually tell
if someone has seen a similar problem before. If I think they have I ask them.
I sometimes ask a different question to see if it was raw ability or
familiarity.

They do tell you a lot. They tell you whether the candidate can actually write
basic code or not. I'm not trying to see if you are a great programmer, I'm
trying to see if you are a bad programmer. It can be really difficult to spot
a great programmer, but it's usually very easy to spot a bad one.

Anxiety is a real problem however. I try to take that into account but it
affects so many people in so many different ways.

Personally I think resume's are worthless. I think the best form of
application would involve some form of code submission - either a simple
"screener" problem or perhaps a personal project. That might still be followed
by an on-site screening interview (people lie and cheat all the time).

------
davidjhall
We've been interviewing MS-SQL dba's for months now. Each time, we ask them to
rate their SQL experience on a scale from 1-10 and most candidates have said
7-8. When brought in and asked to do a simple SQL select with a group by, none
of these candidates could write any SQL. _Any_ SQL. That's what makes tests
important.

------
varjag
Perhaps it just shows there's more junior people in hiring decisions now than
it was before. They remember what they had to pass to get a grade in their CS
class two years back, and that's it.

All these tests are really assignments from Data Structures and Algorithms
class, and being fresh out of college can help here a lot.

------
RiderOfGiraffes
Like so many complaints about coding in interviews, this is talking about
coding _for a bad interviewer._ Listening to both sides of the argument I've
come to the following conclusion. Just as the unthinking mantra is now "90% of
applicants for programming jobs can't program," equally often we hear "99% of
interviewers can't interview."

Interviewing is a two way street, and programming jobs require more than just
programming wizardry. You will need to work with a team, you will need to
communicate with management, and you will need to understand people who aren't
programmers.

Start by understanding interviewers.

------
msie
It's hilarious that some commenters here refer to the author as a guy.

~~~
mmt
Your amusement seems to me to be based on a false assumption.

"He" could be gender-neutral, and perhaps they're encouraging equality by
ignoring the sex of the referent.

<http://news.ycombinator.com/item?id=1795518>

~~~
grayhairmomma
Trust me. I'm all girl.

------
golgo13
I dunno guys. Shouldn't the C++/C#/Java dudes be ready for this? I am an SQL
Server Dev/DBA and the code/design something on paper type questions are
expected for us. Plus it goes even deeper with DMVs, system stored procedures,
etc. I just don't get why the dev folks are surprised when an interviewer asks
them to implement a doubly linked list or something along those lines.

------
KevinMS
Its because credentialism has permeated the software business recently.
Credentialists love tests, its how they got their credentials, and if they
don't keep believing in tests over real world performance, they will have to
re-examine the true worth of their credentials.

~~~
Dilpil
It is the opposite.

Interviewers are coming to realize credentials, be they Microsoft certs or
computer science degrees, are not great indicators of software engineering
aptitude.

The more you believe in the accuracy of credentials, the less you would want
to ask coding questions in an interview. Better to simply examine resumes for
the appropriate certifications and then ask fit questions.

If on the other hand, you believe nothing but on the spot coding
demonstrations can prove a candidates abilities, you would do exactly what
these interviewers are doing. Perhaps these tests are not the optimal tests,
but they sure beat credentialism.

------
ericflo
This is why I don't ask candidates to code. I ask them to describe concepts,
articulate trade-offs, and/or walk me through their process of solving a real
problem (usually something I've just solved so that I'm intimately familiar
with the space).

~~~
RiderOfGiraffes
I hired someone who did brilliantly on walking and talking through all the
conceptual issues. Turned out they couldn't code, and they couldn't touch
someone else's code without breaking it.

I need to see someone code.

~~~
darwinGod
Like the subtle use of the word 'they', incorrect grammatically,correct
politically

~~~
Symmetry
What do you mean grammatically incorrect? The singular they was used by
Shakespeare for heaven's sake, its not some recent invention. Rather, the
prejudice against the singular they (and the split infinitive) stem from when
people looked down on ways in which English deviated from the rules of Latin.
Personally, I think its silly to call any construct thats been in use for
hundreds of years among educated people% and serves a useful purpose
"ungrammatical".

%The Chicago Manual of style lists "Addison, Austen, Chesterfield, Fielding,
Ruskin, Scott, and Shakespeare."

------
z0r
Data structures and algorithms are the foundation. If I ever find myself
unable to write a list or a tree or a sort, I'd better be doing a different
job.

------
Swizec
> Those who code at an alarmingly rapid rate, who get complex code compiled
> and running the first time around.

One word: Emergent design.

Coding shouldn't be done in large patches of perfect code, it should be done
in small segments of perfect code that are individually tested for their
correctness and build up the whole solution.

The fact I couldn't run my code every few lines would completely destroy my
ability to produce anything beyond what I would deem pseudo-code even if it
did, on the surface of it, look like real code.

~~~
JoachimSchipper
It's a linked list. It _is_ a small segment of code.

------
AndrewMoffat
This blog post strikes home. Anyone who has worked with me or seen my work has
identified me as a top-tier developer, and yet I rarely nail any interviews
because I never "sound" how the hiring manager thinks a good candidate should
sound.

I've boiled it down to my salesmanship, or lack thereof. I don't like talking
myself up, and therefore I have difficulty conveying myself confidently. And,
as it goes with vicious cycles, each time I fail to do so lessens my ability
at future attempts.

 _> Mistrust in applicants runs deep among hiring managers, and I have found
that I must still perform Houdini tricks during the interview process, even if
an insider vouches for me._

Even though I know I'm accountable for my salesmanship, I get this sense as
well. It's incredibly frustrating to sense that you're being looked over as
being a phony trying to pull one over on a company (how does this work
exactly, anyways?) More often than not though, I've noticed this happens more
with hiring managers who are not qualified technically to hire developers.

~~~
MetallicCloud
Yep, I'm right there with you. I know I'm not selling myself correctly, but
the thought of putting anything on my resume that even remotely embellishes
the truth a little makes me want to hurl.

Also, combine that with the fact that I hate my current job so much that I am
afraid that my next just might suck as much, so I am being /very/ picky. I've
turned down a couple of job offers that in hindsight I probably should have
taken.

~~~
sokoloff
I would encourage people like yourself to put enough information your HN
profile that you can be reached for networking purposes by other HN readers.
Many of us may be in a position to offer interviews for non-suck jobs or
pointers towards same, that we aren't going to post in open comments to the
entire HN community, but would send targetted to the email in your HN profile.

If you are shy or anti-marketing, you may need to work just a little harder in
mediums you are comfortable with to network. (This isn't directed at you
specifically, MC.)

~~~
buro9
Seconded. I'm hiring and whenever I see HN posts I like I check profiles
immediately for location information and contact details, or at least info on
where I might find out more about someone.

HN _is_ networking. Make yourself discoverable.

~~~
MetallicCloud
Thanks for the tip guys. Updated.

~~~
sokoloff
You now have location there (which turns out to be fairly close to one of our
facilities) but no contact information, so I still can't reach out to you.

If you're extremely uncomfortable listing an email address (or lisp form that
evaluates to one or something similar), you can reach out to me based on my
profile, but I'd really urge you to list some contact information in your
profile, even if it's a throwaway account that you can easily walk away later
from if the volume becomes overwhelming. If you're reaching out to me, add
"HackerNews" in the subject line, please.

~~~
MetallicCloud
Thanks, I had put an email in the email field, I just assumed that was
available from accessing someones profile. It's also in the about field now.

------
zackattack
Do you think that being able to implement a linked list is a fundamental
programming skill? Because if an advanced programmer is lost her ability to
relate with novices ("my boss can't even implement a fucking linked list") I'd
say that'd be a bad thing.

In my humble estimation, experts tend to be bad teachers because they have
lost touch with the frames of novices. The best teachers are ones who have
most recently mastered a skill.

~~~
angelbob
Depends on the position. I have worked, recently, on codebases where that kind
of thing was absolutely a core skill and we asked people to write linked list
code in the interview process. We were also doing manually-managed core OS and
display manager code for a mobile operating system.

In my current job writing server-side Java and Ruby on Rails code, I wouldn't
dream of asking that question. It would be pointless.

~~~
eftpotrm
Amen. I've worked perfectly happily and successfully in software for the last
10 years, writing what most of the software industry is writing - database
apps.

I've never, ever, needed to write a linked list, a sorting algorithm, access
memory directly and pass around pointers or any of the sample problems that
are being cited here. I know the theory, I've done them in academia many years
ago but I've got more important and useful things to remember on a day-to-day
basis. These are firmly under the category of 'look them up if I ever need
them again' and I'd be perfectly happy with a hypothetical candidate (I've not
interviewed anyone in years) who said they knew the theory and would look up
the exact details. I do that all the time with the more esoteric features.

At my last place, we did have a coding test as part of the interview. We
checked all sorts of little things but could usually mark the entire test with
some accuracy on the first question.

1\. Please write a valid SQL inner join statement.

Seriously. For a position specifying SQL, to maintain an SQL backed custom
business application, a majority of applicants couldn't write an inner join.

I suppose I'm saying - do whiteboard / paper coding tests, but do the _right_
ones for your projects. Don't give them a test on something that's clever but
unnecessary for what you do, check they know the basics and are up to speed
with independent learning and they should be fine.

------
pitdesi
I'd be interested to know what people think about coding pre-screening tests
in general. As is obvious from my profile, I'm working on a startup trying
that helps companies and recruiters easily implement coding tests to weed out
people who can't code. This is a bit different than asking someone to
whiteboard a solution - we're aiming to help companies get from a few hundred
resumes to the top 10 or 15. We've commonly heard the problem (and experienced
it first-hand) that people can't code, and we think coding tests helps solve
that problem. I think it's a better solution than going by your past
experience, because that's often fluff.

------
aarp
and you, you're just too f*cking, blond!!!

blond = old.

------
csjohnst
How good a programmer can she be when there's not even a Hello World post on
her blog, just this rant... just saying...

------
mikeklaas
If I found this article by a potential applicant, I'd be much less likely to
hire them. Besides the obvious red flag of the sentiment _why should I have to
code at a programming interview_ , the knowledge that they have been rejected
by many other companies would make me worry.

~~~
grayhairmomma
Sorry you feel that way. Several hiring managers from top companies feel
differently than you though, because they have contacted me directly and even
asked me to apply at their companies. Does this mean that I've got an instant
job ? Of course not. I still have much proving to accomplish -- to these
hiring managers and their crew. But they obviously see a glimpse of something
special in me -- which you don't.

I speak my mind...I live authentically. Yes, it's a risk to live that way, but
I am willing to accept the consequences of my actions.

~~~
mikeklaas
Good luck. I hope those leads work out for you.

