
Dear Startups: stop asking me math puzzles to figure out if I can code - brryant
http://countaleph.wordpress.com/2013/10/20/dear-startups-stop-asking-me-math-puzzles-to-figure-out-if-i-can-code/
======
tommorris
Here's the test I've used in the past:

Before the interview, I ask them to write some code to access an HTTP endpoint
that contains exchange rate data (USD, EUR, GBP, JPY etc.) in XML and to parse
and load said data into a relational database. Then to build a very simple
HTML form based front-end that lets you input a currency and convert it into
another currency.

I ask them to send me either a link to a repository (Git, SVN etc.) or a
zipball/tarball. If the job specifies a particular language, then I obviously
expect it to be in that language. If not, so long as it isn't in something
crazy like Brainfuck, they have free range.

If the code works and is basically sane, that goes a long way to get them
shortlisted.

During the interview, I'll pull the code they sent up on a projector and ask
them to self-review it. If they can figure out things that need improving in
their code, that weighs heavily in their favour. Usually this is things like
comments/documentation, tests, improving the structure or reusability. If it's
really good, I'll throw a hypothetical idea for refactoring at them and see
how they think.

The reason this works is that, despite Hacker News/Paul Graham dogma to the
contrary, "smartness" isn't the only thing that matters in programmers. It's
actually fairly low down the list. When hiring programmers, I want people who
are actually able to do the daily practical job of writing code, modest and
self-critical enough to spot their own mistakes, and socially capable to
actually communicate their decisions and mistakes to the people they work
with.

I interviewed a guy who was intellectually very smart and understood a lot
about CS theory. I asked him why the PHP code he sent me didn't have any
comments. "I don't believe in comments because they slow the PHP interpreter
down." Sorry, he can be smarter than Einstein but I ain't letting him near
production code.

~~~
bdg
I love your interview style: actually test for things the dev will actually
do.

I've applied to other jobs who's owners frequent HN, and they did things like
test my ability to write sort algos or data structures... but the job called
for a good knowledge of JavaScript, Backbone and general knowledge of django
to build a mix between a CMS and an elaborate voting system.

They didn't hire me. I'm utterly trash at working on algos under pressure. I
felt like a lost child just trying to write a simple sort during the
interview. Worse, I made it harder on myself by asking to not write the code
in MSWord (or some other similar thing) and instead use jsfiddle. The owner
looked at the code and said 'Yeah, that looks about right to me, it should
work.' I foolishly hit run.

What I learnt was two-fold:

1) this doesn't test my ability to do the thing you want to pay me to do (as
proof, I'm writing more complex applications today at a job I enjoy far more
than I would have at that company).

2) The employer can't differentiate between a "smart developer" or "average
developer" until the script executes.

~~~
lportion
I've had similar experiences.

I went for a job a few months ago where I had to write a program on paper to
produce report data from raw data collections, it was reasonably complicated.
This is the type of thing I breeze through when I'm sat alone at my desk, but
for whatever reason I just went into panic mode and couldn't think straight at
all. I apologised and told them just that. It was frustrating to say the
least.

The interview went ahead and we ended up talking about various architectures,
design patterns, programming languages, functional programming and even HN,
but I'm sure I never got the gig because of the technical test.

For the interview at my current gig they walked out of the room for 10 minutes
while I had to write sorting algorithms and I was able to do it without a
problem. So, for me at least, the element of being watched while I wrote the
code seemed to be part of the problem.

------
rdtsc
Two possible reasons:

1) I think a lot of start-ups want to hire "smart" people. Because they expect
the new person to eventually wear many hats. Objective-C, Java, Android, CSS,
server side concurrency, monitoring. An we've all seen Hunter and Schmidt
reference that tokenadult usually posts when talk about interviewing comes
around and it does seem that a general mental ability test (like an IQ test)
combined with a work samples seem to predict future performance of that
employee. Well except that one can't just straight up give IQ test to job
applicants (there is a court case about that). So we are left with a job
sample (which many forget to give, as is the point of the author). But instead
many focus on the GMA and create proxies for it -- cute little puzzles about
blenders, round manhole covers, and other such silly things.

2) Those interviewing don't know the technical stuff and are afraid you'd out-
bullshit them. "How does an Ajax request work" well if the interviewer
themselves doesn't quite know the details the might not be able to evaluate it
properly. They could have it written down but well, some technical questions
have many different levels of depth that a candidate might descent to. So a
quick written answer to the question might seem wrong but it is really because
the candidate is more advanced. So puzzles seems to be a generic and "easier"
to handle.

~~~
morgante
I think (1) is probably the primary reason, along with the fun factor I
mentioned above.

But honestly, why can't we just start giving IQ tests? Or at least asking for
SAT scores? We shouldn't have to run through training puzzles just to prove
we're smart enough to build a site.

~~~
deluxaran
What kind of IQ tests? Math thinking? Language? Other? These tests are kinda
old and don't prove anything besides the fact that the person has a certain
level of intelligence but that doesn't mean they can code.

~~~
morgante
> What kind of IQ tests? Math thinking? Language? Other?

Both. They're not perfect, but I'm going to be picky and look for people who
can generally reason well (both mathematically and verbally).

> but that doesn't mean they can code.

That's why you pair it with work samples.

The ideal hire would be an impressive GitHub + evidence of intellect. The
GitHub shows they have coding chops, while an IQ test usually means they can
react quickly and learn new skills.

~~~
cromulent
Smart & Gets Things Done, as Joel Spolsky would say.

[http://www.joelonsoftware.com/articles/GuerrillaInterviewing...](http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html)

[http://www.amazon.com/Smart-Gets-Things-Done-
Technical/dp/15...](http://www.amazon.com/Smart-Gets-Things-Done-
Technical/dp/1590598385?ie=UTF8&s=books&qid=1181076229&sr=8-1)

~~~
infinite8s
Or as Steve Yegge likes to say, "Done and Gets Things Smart"

[http://steve-yegge.blogspot.com/2008/06/done-and-gets-
things...](http://steve-yegge.blogspot.com/2008/06/done-and-gets-things-
smart.html)

~~~
RogerL
That is an _extremely_ long post that says "hire the rock stars". Except, of
course, we all cannot only hire the very best, transformative people (like
Jeff Dean at Google). And, he has no way to actually identify them, except
"ask around".

It's entirely unrealistic as a business strategy. It sure is nice if you luck
into it.

------
ek
> Spoiler alert: to solve this problem, you need to know how to enumerate the
> rationals.

This problem was addressed nicely in this functional pearl by Jeremy Gibbons,
et al.:
[http://www.cs.ox.ac.uk/jeremy.gibbons/publications/rationals...](http://www.cs.ox.ac.uk/jeremy.gibbons/publications/rationals.pdf)
. As interesting as the result is, however, it's a pretty well-made point that
research-level ideas from the programming languages community are not really
software engineering interview material in the vast majority of cases.

This is yet another example of "rockstar developer"-itis, wherein startups are
given to believe that they need the best of the best when in fact they do not.
This particular example is entirely egregious because they asked her about
something that requires enumerating the rationals when what they really wanted
was an iOS code monkey. Then they fired her, based on their own shoddy
interview.

~~~
AUmrysh
The worst part of it is that it's easy to feel like it's your own fault when
something like this happens. The real problem was the hiring manager
misleading the applicant about what the job would be, but the OP clearly felt
responsible for it.

I had a similar experience (working for family, at that), where I joined their
R&D group and it went well for a while, but eventually they decided they
wanted to get into selling solar power and didn't need a software/electrical
engineer, so I was lectured about this or that bullshit and eventually brought
into a meeting with the IT director and offered a position on his team. I
realize now that they were trying to make me feel unwelcome, but I felt
entirely responsible at the time. I never felt like I had a choice in taking
the IT position (or lose my employment there entirely), and I hated it. The
new boss was, for the most part, a nice guy, but he turned into a major
nitpicking asshole over little things.

I'm at a new place now and it's still hard to kick the habit of trying to
avoid coworkers because you know they don't like you and want you gone.

Culture has a huge impact on hiring and working. I wish I had been taught
about culture when I was in school, I could have avoided the problems I faced
had I realized the warning signs earlier.

------
Xylakant
I actually like asking math questions on interviews. It shows how people
approach a problem. Asking code questions in an arbitrary interview setting
shows just about nothing - no access to a reference doc, somebody peering over
your shoulder. Heck, I couldn't code my way out of a wet paperback in that
setting.

Certainly, asking _only_ math questions is stupid as well, people should know
at least a little about the stuff they're supposed to work with, but teaching
an actual language to a smart person eager to learn is a breeze compared to
teaching problem solving to someone who memorized the reference manual.

~~~
auggierose
I think you don't get the point. Learning a new language after you programmed
for 5 years in a variety of paradigms like assembler, object-oriented, purely
functional, will take you between a couple of hours and a week. But if you
have NOT had those 5 years of varied programming experience, then the new
language is not your problem. Learning the concepts is, and that will take
time.

~~~
Xylakant
I think you don't get my point: I expect a domain expert to be a domain
expert, but I don't expect a trainee to know anything and I'll structure my
interview accordingly. I'll ask the domain expert questions about his domain.
But I don't expect a domain expert to know the programming language that we
work with just because he's a domain expert. And seriously, I'll prefer the
eager-to-learn math graduate with little coding experience over the bored cs
graduate that knows the java reference doc by heart and now thinks he knows
how to build stuff. In any case coding examples in your interview will show
you little beyond the fact that somebody memorized the docs.

The actual pain point I read from the article is a different one: There's a
mismatch between hiring process and expectations. If I need a lead programmer
for the iOS project that I'm about to start next week then I can't hire anyone
that doesn't know Objective C and then I absolutely need to structure my
interview accordingly. But if I have a couple of weeks more I'll happily teach
him. And if I'm hiring somewhat smart I try to avoid those "we need someone
urgently" situations.

~~~
kelnos
I think you vastly underestimate the time it takes to learn these sorts of
things. Sure, you can teach someone to write a simple, passable iOS app that
does a few basic things in a couple weeks. But they're still going to be a
raw-novice iOS developer. Maybe the app you need them to build is super
simple, but if not, you're doing yourself and your company a disservice by not
hiring someone who's done iOS before.

I'm speaking from experience here: I learned iOS (even after having previous
MacOS X desktop devel experience) on the job, when a friend asked me to write
an iOS app for her startup. I learned quickly, but made a lot of mistakes in
how I structured the app that came back to bite me months later. If I'd had
the time to start over from scratch, I would have done things quite
differently and the whole thing would have been a lot easier.

And I was _slow_. Every new framework I had to learn slowed me down and added
days to implementing the part of the app that needed it. A seasoned iOS
developer wouldn't have run into problems like that.

~~~
Xylakant
I think you vastly underestimate the value of "other knowledge" for any kind
of complex undertaking. Unless you get a domain expert who happens to be a
rock star programmer and a ninja architect and top-notch devops, you'll have
to compromise somewhere. Take an iOS game: Depending on the game it can be
vastly more value to have knowledge of game programming and game AI than
having knowledge about iOS frameworks. If there's a team on the project I'd
even go as far and say that I would pick the domain expert over the framework
expert as team lead, given that all other capabilities were on par.

~~~
kelnos
Sure, there are always compromises. I wasn't claiming otherwise. I was merely
pointing out that ramping up on a particular platform is nowhere near as easy
as the parent suggests.

Games are a bit of a special breed, though, and there are several game engines
out there that hide the platform pretty well. I draw a bit of a distinction
between "building and iOS app" and "building an OpenGL app that runs on iOS".
The latter is much easier if you lack iOS experience but have the required
OpenGL skills.

------
mcphilip
After much experimentation giving interviews for server side positions, I've
come to favor questions that involve routine real world problems that can be
handled in increasingly sophisticated ways.

One example I use is getting the candidate to write crud, list, and search
controller actions for a simple category data structure. Given a basic
category data model (e.g. Name, Parent), the candidate starts with the crud
actions.

Crud actions aren't meant to be difficult to solve and serve as a basic
screener to verify the candidate has working knowledge of the basics. The only
edge case I look for the candidate to ask about is if orphaning child nodes is
allowed (I.e updating parent node, deleting a node with children)

List action(s) start getting more interesting since recursion comes into play.
A basic implementation of an action that can load the tree given an arbitrary
category as a starting point is expected. If the candidate has some prior
experience, a discussion of what performance concerns they may have with
loading the category tree is a follow up question. The tree loading algorithm
is then expected to be revised to handle an optional max depth parameter. An
edge case I look to be considered is how to signify in the action response
that a category has one or more child nodes that weren't loaded due to a depth
restriction.

The search action implementation has a degree of difficulty scaled to the
candidates experience level. All candidates have to write an action that
returns a collection of categories matching a search string. Those with
previous experience are asked about a paging solution. Senior level candidates
are asked to return matching categories in a format that indicates all
ancestors ( for instance: "Category 1 -> Category 1.1 -> Category 1.1.1"
result for search string "1.1.1")

For an added degree of difficulty, candidates can be asked to recommend data
model tweaks and algorithms supporting tree versioning requirements necessary
to allow for loading the category tree's state at a given point in time.

The candidate's performance to this exercise seems to give some insight into
their level of experience and ability to implement algorithms from a common
real world example without having to ask much trivia or logic problems.

~~~
dionyziz
OP would still blow you away by using the Nested set model:
[https://en.wikipedia.org/wiki/Nested_set_model](https://en.wikipedia.org/wiki/Nested_set_model)

Although if you've been doing this interview for a while, you're bound to have
come across someone who mentioned it, so I'm sure you're familiar.

~~~
arethuza
And even better - knowing that quite a few database engines have extensions to
help handling hierarchical data and it probably depends on the details as to
which is actually better in a particular circumstance.

~~~
nbouscal
Definitely. Nested sets have a lot of weaknesses, and any decent modern
database will have CTEs so you can just use an adjacency list with a recursive
query, or materialize out the closure table.

------
dpiers
Hiring engineers is hard, and companies haven't really figured it out yet.
Even the best companies rely on puzzles and gimmicks that often have little to
do with day-to-day programming.

At one company I interviewed with, I was asked to implement a queue using two
stacks. At that time in my programming career, I had worked with C, C++,
Obj-C, Lua, Python, JavaScript, SQL, and a handful of DSLs developing games,
game development tools, and web applications. Want to know what I had never
done? Written a queue using two stacks. My immediate response to the question
was, "Why would you want to do that?"

If you really want to know if someone has the capacity to pull their weight as
an engineer, ask them about what they've built. Even if they are fresh out of
college, the best engineers will have projects they can talk about and
explain. Ask how they approached/solved specific problems. Ask what they're
most proud of building. Ask what was most frustrating.

Those are the kind of questions that will provide insight into a person's
problem solving capabilities and offer a decent picture of what they're
capable of doing.

~~~
cynicalkane
If you're wondering, the "two stacks queue" is an easy way to write a simple
immutable queue for a functional programming language. You use one functional
stack for enqueueing and one for dequeueing. When the dequeue stack is
exhausted the enqueue stack is "flipped" into the dequeue. Amortized runtime
is O(1) per operation.

~~~
dpiers
Once they told me to use one stack for enqueueing and one for dequeueing, I
immediately solved the problem. What I didn't understand is why you would a.)
implement your own queue structure and b.) implement it in such a non-
intuitive way.

Now that I know this would be for a functional language, it makes _way_ more
sense. At the time I couldn't get over why you wouldn't just use a doubly-
linked list like the standard implementation in most OO languages.

------
x0054
Here is an interesting idea that I had reading this. As a startup, what if you
were to create a simple computer language that looked different from most
other computer languages, at least somewhat different. Alternatively, just use
one of the many really obscure programming languages out there, just make sure
the applicant does not know it ahead of time. Give the applicant a 10-20 page
reference manual for the language and ask them to make a simple program of
some sort. Have them read the manual and write the program, hopefully while
not looking over their shoulder, so they can relax. In the manual you give
them omit one critical function or API reference, but make sure that info is
available online (make it available if you made up the language). Then see
what happens.

This would test programmers ability to learn a new language.

~~~
collyw
It takes me a month or two to be comfortable with a new language.

How long do you expect your interview to last?

~~~
_ak
I guess that proposed interview is supposed to get people out of their comfort
zone and test whether how quickly they can adapt and learn from a manual and
simple examples and then at least be able to write simple programs.

------
morgante
It is rather unfortunate how little correlation most tech interviews have with
their respective jobs. It's largely a lose-lose situation for everyone.
Developers who could easily build great systems but aren't experts in graph
theory get passed over while brilliant mathematicians who can't necessarily
code get hired. Result? Companies simultaneously having to fire employees
while facing a supposed talent crunch. Given that this hurts everyone, how did
we even get into this situation?

Probably because the only person who doesn't lose from this is the
interviewer: they get to have fun. Honestly, when you spend all day buried in
code, it's _fun_ to play with puzzles for a change.

Perhaps it's time we started optimizing interviews for hiring success rather
than interviewer happiness.

~~~
kenster07
Okay, but any specific suggestions on how to do that?

~~~
morgante
Start with a simple interview which simply checks that the person (a) has a
brain; (b) is somebody you're comfortable working with.

Then do a short-term contracting gig (maybe just 1 day). If it works well,
hire them.

Edit: clarify length which even the best people could do.

~~~
nagrom
Generally speaking, high quality people won't take a short-term contracting
gig. They are probably working elsewhere and don't need that level of
uncertainty; they're looking for something _better_ , not just anything.

~~~
morgante
I'd hope that by that point I'd have sold them on my company enough that they
really thought it was _better_.

Also, I don't think it needs to be a long gig. Maybe even just a day, which
isn't much longer than the gauntlet of technical interviews some companies
will put you through. Even that short period should be enough to see if
someone works well.

~~~
lmm
Doing a day's contracting elsewhere would violate my current employment
contract. (And I think strict adherence to the letter of the rules will be
reasonably common among good developers)

------
Beltiras
Funny. Just made a hire and this story made me think of it.

The position I was filling is a part-time position for a CS major, sort of
like an internship. I devote time to develop his/her skills, s/he would get
real-world experience, and a little money to help with cost of living. If
everything works out, a position could open up for full employment.

I had a pretty good idea what I was looking for. Someone that had good grasp
on theory but had no experience coding. Preferably enrolled in Uni. I had 5
applicants but the only candidate I interviewed is enrolled in Math-CS.

I basically tried to gauge if he had deep interests and asked him to code a
bit, solve a simple control (find me the article with the highest hitcount
from the day a week ago, gave him 10 minutes).

He failed the coding test but I made the hire regardless. Reason why was 2
things out of the 4 hours we spent together: When I asked him who he
considered the father of CS he rattled off von Neuman, Djikstra and Knuth.
Yeah, you can make that argument I suppose, but he knew who the influential
people were. The other thing was: even if he failed the coding test he failed
it by not reading the code examples quite right, he was using my code to try
to help himself solve the problem. I'm sure he'll work out.

We as a field should employ internships a lot more than we do, get the college
kids and undergrads working on real-world problems a lot more than we do.

------
lotsofcows
I agree. But for a different reason: I'm shit at maths puzzles.

I just don't have the experience or tools or interest for them.

And yet, somehow, in 20 years of business geekery I've never come across a
problem I can't solve.

Maybe when writing Tetris for J2ME I would have saved myself 10 minutes
googling if I'd had the experience to realise that right angle based matrix
translations don't require fp maths and maybe when writing financial
indicators, I'd have saved myself half a day if I hadn't had to look up
integrals but this sort of stuff is definitely in the minority as far as my
experience goes.

~~~
yeukhon
I don't play Sudoku, I don't solve puzzles. I don't want to solve mathematical
puzzles. I just want to deal with system and deal with security and none of
them requires me to understand the tricks to solve a puzzle. Sure I can learn
some cool algorithms but no thanks. I don't want to solve puzzles. Exactly.

------
jph
> Breadth-first search from both ends.

I believe this is deeply valuable. For some roles, I would _much_ prefer to
hire someone who can quickly see the value of breadth-first search from both
ends.

If he/she doesn't happen to know the syntax of Ruby, or Java, etc. it's less
important to me.

~~~
tylerkahn
I mean this as a genuine question:

[http://sixarm.com/](http://sixarm.com/)

This is your company, correct? (I stalked your Github profile)

Seems like the types of problems you're solving are exactly those which
require far more domain experience with Ruby/HTML5/Javascript/whatever than
the ability to see the value of various graph-searching techniques.

Would you hire this guy even though he's said quite plainly that he lacks the
experience with these technologies (and has difficulty picking up new ones
owing to that lack of experience)?

~~~
jph
TLDR: Yes, for some roles.

Some of our projects have us on site, side-by-side with a client's staff
programmers. These projects involve millions of dollars, hundreds of
stakeholders, and years of existing code. The programmers have a wide range of
skill levels.

The work in these projects involves figuring out the project's objectives,
goal decomposition, some agile/lean PoCs, then developing the BDD, MVC, DCI,
API, CQRS, SQA, etc. Much of this can happen in pseudocode.

We also do pair programming, code reviews, brown bag demos, cross-training,
and the like. I believe all these can help with developers getting up to speed
with language syntax.

That said, choose the right person for the job. YMMV.

------
jroseattle
I'm dealing with this now, having been interviewing for different engineering
roles over the past two months. It hasn't been as bad as straight-up
conceptual math problems, but there have been plenty of questions that I have
questioned for validity.

Interviewer: "How can we optimize the character replacement in a string such
that we use no extra memory?" Me: "We do this and that and this. But, should
we consider what situations we would need this optimization?" Interviewer:
"What? Why?"

I can now use this as a filter as I interview organizations. Optimizing
algorithms by creating your own core data structure classes (instead of using
the built-in ones) is great in certain circumstances, but an absolute waste of
time in many others. And if you're _not_ going to ask me about those times
when making those improvements is important, then you're not asking questions
for a programmer -- you're asking them for a theoretician who can recall
syntax.

It's poor practice, and I've seen it everywhere.

------
tokenadult
There are many discussions here on HN about company hiring procedures. Company
hiring procedures and their effectiveness is a heavily researched topic, but
most hiring managers and most job applicants haven't looked up much of the
research. After reading the blog post kindly submitted here and some of its
comments, and then reading most of the comments here on HN that came in while
I was asleep in my time zone, it looks like it's time to recycle some
electrons from a FAQ I'm building about company hiring procedures.

The review article by Frank L. Schmidt and John E. Hunter, "The Validity and
Utility of Selection Models in Personnel Psychology: Practical and Theoretical
Implications of 85 Years of Research Findings,"[1] Psychological Bulletin,
Vol. 124, No. 2, 262-274 sums up, current to 1998, a meta-analysis of much of
the _huge_ peer-reviewed professional literature on the industrial and
organizational psychology devoted to business hiring procedures. There are
many kinds of hiring criteria, such as in-person interviews, telephone
interviews, resume reviews for job experience, checks for academic
credentials, personality tests, and so on. There is much published study
research on how job applicants perform after they are hired in a wide variety
of occupations.[2]

EXECUTIVE SUMMARY: If you are hiring for any kind of job in the United States,
with its legal rules about hiring, prefer a work-sample test as your hiring
procedure. If you are hiring in most other parts of the world, use a work-
sample test in combination with a general mental ability test.

The overall summary of the industrial psychology research in reliable
secondary sources is that two kinds of job screening procedures work
reasonably well. One is a general mental ability (GMA) test (an IQ-like test,
such as the Wonderlic personnel screening test). Another is a work-sample
test, where the applicant does an actual task or group of tasks like what the
applicant will do on the job if hired. (But the calculated validity of each of
the two best kinds of procedures, standing alone, is only 0.54 for work sample
tests and 0.51 for general mental ability tests.) Each of these kinds of tests
has about the same validity in screening applicants for jobs, with the general
mental ability test better predicting success for applicants who will be
trained into a new job. Neither is perfect (both miss some good performers on
the job, and select some bad performers on the job), but both are better than
any other single-factor hiring procedure that has been tested in rigorous
research, across a wide variety of occupations. So if you are hiring for your
company, it's a good idea to think about how to build a work-sample test into
all of your hiring processes.

Because of a Supreme Court decision in the United States (the decision does
not apply in other countries, which have different statutes about employment),
it is legally risky to give job applicants general mental ability tests such
as a straight-up IQ test (as was commonplace in my parents' generation) as a
routine part of hiring procedures. The Griggs v. Duke Power, 401 U.S. 424
(1971) case[3] interpreted a federal statute about employment discrimination
and held that a general intelligence test used in hiring that could have a
"disparate impact" on applicants of some protected classes must "bear a
demonstrable relationship to successful performance of the jobs for which it
was used." In other words, a company that wants to use a test like the
Wonderlic, or like the SAT, or like the current WAIS or Stanford-Binet IQ
tests, in a hiring procedure had best conduct a specific validation study of
the test related to performance on the job in question. Some companies do the
validation study, and use IQ-like tests in hiring. Other companies use IQ-like
tests in hiring and hope that no one sues (which is not what I would advise
any company). Note that a brain-teaser-type test used in a hiring procedure
could be challenged as illegal if it can be shown to have disparate impact on
some job applicants. A company defending a brain-teaser test for hiring would
have to defend it by showing it is supported by a validation study
demonstrating that the test is related to successful performance on the job.
Such validation studies can be quite expensive. (Companies outside the United
States are regulated by different laws. One other big difference between the
United States and other countries is the relative ease with which workers may
be fired in the United States, allowing companies to correct hiring mistakes
by terminating the employment of the workers they hired mistakenly. The more
legal protections a worker has from being fired, the more reluctant companies
will be about hiring in the first place.)

The social background to the legal environment in the United States is
explained in various books about hiring procedures,[4] and some of the social
background appears to be changing in the most recent few decades, with the
prospect for further changes.[5]

Previous discussion on HN pointed out that the Schmidt & Hunter (1998) article
showed that multi-factor procedures work better than single-factor procedures,
a summary of that article we can find in the current professional literature,
for example "Reasons for being selective when choosing personnel selection
procedures"[6] (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias
Berchtold, and Martin Kleinmann:

"Choosing personnel selection procedures could be so simple: Grab your copy of
Schmidt and Hunter (1998) and read their Table 1 (again). This should remind
you to use a general mental ability (GMA) test in combination with an
integrity test, a structured interview, a work sample test, and/or a
conscientiousness measure."

But the 2010 article notes, looking at actual practice of companies around the
world, "However, this idea does not seem to capture what is actually happening
in organizations, as practitioners worldwide often use procedures with low
predictive validity and regularly ignore procedures that are more valid (e.g.,
Di Milia, 2004; Lievens & De Paepe, 2004; Ryan, McFarland, Baron, & Page,
1999; Scholarios & Lockyer, 1999; Schuler, Hell, Trapmann, Schaar, & Boramir,
2007; Taylor, Keelty, & McDonnell, 2002). For example, the highly valid work
sample tests are hardly used in the US, and the potentially rather useless
procedure of graphology (Dean, 1992; Neter & Ben-Shakhar, 1989) is applied
somewhere between occasionally and often in France (Ryan et al., 1999). In
Germany, the use of GMA tests is reported to be low and to be decreasing
(i.e., only 30% of the companies surveyed by Schuler et al., 2007, now use
them)."

[1]

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

[2]

[http://www.siop.org/workplace/employment%20testing/testtypes...](http://www.siop.org/workplace/employment%20testing/testtypes.aspx)

[3]

[http://scholar.google.com/scholar_case?case=8655598674229196...](http://scholar.google.com/scholar_case?case=8655598674229196978&q=Griggs+Duke+Power&hl=en&as_sdt=2,24)

[4]

[http://books.google.com/books?hl=en&lr=&id=SRv-
GZkw6TEC](http://books.google.com/books?hl=en&lr=&id=SRv-GZkw6TEC)

[5]

[http://intl-pss.sagepub.com/content/17/10/913.full](http://intl-
pss.sagepub.com/content/17/10/913.full)

[http://www.economics.harvard.edu/faculty/fryer/files/Fryer_R...](http://www.economics.harvard.edu/faculty/fryer/files/Fryer_Racial_Inequality.pdf)

[6]

[http://geb.uni-
giessen.de/geb/volltexte/2012/8532/pdf/prepri...](http://geb.uni-
giessen.de/geb/volltexte/2012/8532/pdf/preprint_j.1468_2389.2010.00485.x.pdf)

~~~
mattjaynes
I can confirm this works in my own experience of trial-and-error interviewing
over 2000 applicants and hiring over 200 for my clients and myself (since
~2006).

Nearly 100% of the applicants were remote, so I think that helped me from
falling into traps of poor "traditional" hiring practices.

The point of hiring these remote folks was to help accelerate whatever team I
was on. It can be a great way to scale your existing team very quickly if you
know how to do it.

For example, I took over an iPhone app dev team and it was taking them 4
months to produce an app. These apps were all very similar in functionality,
but the developers were spending a ton of time slicing images, testing, and
other tasks that remote workers could easily do. So I hired some remote staff
(via oDesk) to do most of that supporting work and we got the app production
time down consistently to 1 month. That was a _huge_ ROI for the business
since the total cost for all remote staff was the same as for 1 additional on-
site engineer.

There's nothing magic about hiring well, but I've watched others try to hire
remote staff and the vast majority of them try once, fail, and give up on it.

They will approach the hiring process in a traditional way (personally
interview them to watch how they handle puzzles, etc). It's a grueling process
and then they still get really poor hires and conclude that "outsourcing
doesn't work".

It's most helpful to think of the process as panning for gold. (Naturally, I'm
not saying that some people are more valuable than others innately, just that
you're looking for those who are most valuable at performing your given
tasks.)

So, to find gold, you must filter, filter, filter. That's the exact process
for finding applicants that are high performers. Most of your applicants will
be pretty terrible at the job you're hiring for, so the filtering process is
critical for success.

    
    
      - filter out the very worst applicants with a small easy question
      - filter out the remaining applicants:
         - pick a real-life production task you've recently completed
         - ensure that the task is *exactly* what they'd be doing in the job
         - have them perform the task
         - compare their task results to your task results
      - hire more than you need of the top performers
      - filter out (gently fire) the ones that aren't as good
      - repeat as needed until you have gold
    

When I see others attempt this, the most common problem is that they
essentially go down to the river and just grab whatever pebbles they see in
their first handful and hope there's gold in it (hire without filtering). Or
they go down and carefully pick the prettiest pebbles hoping they will be gold
(wrong filter / puzzle interviewing). But the only way to really find gold is
to seriously invest in a filtering process that will yield actual gold. That
means filtering based on their ability to do the _actual_ tasks they'll be
doing on the job.

The great thing about hiring remote folks is that I care 0% how they get the
task done. I don't care if they've automated it, or have their mom do it for
them, or whatever. If they provide the results I need, I'm happy, period.

There are plenty of other smaller caveats and gotchas to watch out for, but
I'll try to cover those in a blog post sometime.

If you're a startup and want to go faster, try this out by off-loading some of
the grunt work from your staff. It can be a big competitive advantage if you
can do it right.

~~~
NAFV_P
"filter out (gently fire) the ones that aren't as good." If the employee finds
out you "hire more than you need of the top performers", you end up with a
potential court case. If I found this out about a former employer, I would
have pursued them to the end of hell.

~~~
jacalata
how is that breaking any law?

~~~
ebrenes
IANAL, and I'm just taking a stab in the dark here... But might it have to do
with the work contract not being made in good faith?

That is in my basic understanding of contracts it is assumed as part of the
contract that there is good will between both parties to fulfill what is set
out in the contract. Practices such as these would indicate that the company
has no actual intention of hiring the employee and is using the hire as an
additional filter.

I suppose if the contract stipulated that there was a trial period or some
such it might be a way to wiggle out of it. From a quick google search it
seems you can either sue for Fraud (they advertised a permanent position and
that wasn't the case, or they didn't make it explicit that the position was
temporary) or Breach of Contract if they didn't specify that you were in a
trial period.

Would love to hear from someone with better grasp of the situation.

~~~
aestra
IANAL or a legal scholar.

In the US, generally people are employed at will
([http://en.wikipedia.org/wiki/At-
will_employment](http://en.wikipedia.org/wiki/At-will_employment)) which means
an employee can be dismissed by an employer for pretty much any reason and an
employee can leave their job for any reason, without any notice.

There's some exceptions (for example, discrimination) but you're free to take
a job in bad faith too.

~~~
raganwald
A job being at-will doesn't affect whether you can offer a job in bad faith.
"At will" says you have the right to fire me for any reason. "Bad faith" means
you shouldn't offer me the job in the first place unless you mean it. They
affect two different actions.

Let's make an extreme example: I interview Anderson, Beth, and Charlee. I like
Anderson and Beth, but Beth is a better fit for the team. Charlee is terrible.

Meanwhile, All three are interviewing with my competition. So... I give jobs
to Anderson and Beth. I offer Anderson a very good salary just to make sure he
doesn't go to the competition. They hire Charlee, and that's a win for me. Now
I fire Anderson.

I suggest that if this was my plan all along, I wronged Anderson when I
offered him a job in bad faith. I may not have wronged him when I used the "at
will" provision to fire him, but I wronged him when I fraudulently offered him
a job that I had zero intention of letting him earn the right to keep.

------
DigitalSea
I failed mathematics in school, for the life of me I can't grasp them beyond
the basics, but give me laptop and a copy of Sublime and I'll code anything
you want. I can code, but I would fail any mathematical test given to me. This
kind of approach has always bothered me, there are a lot of good developers
out there bad at maths but posses strong problem-solving and highly analytical
skills.

Being a developer is 80% Google and 20% actual coding knowledge. We are
hackers at the end of the day, not miniature Einstein's with encyclopaedias
for brains.

~~~
gboudrias
I've always felt like I was supposed to like maths, but I learned (basic)
programming before I learned algebra, and I couldn't figure out how I would be
using it.

After years of being a programmer, I still can't.

------
mrcactu5
It looks like Emma's math prowess is working against her. It's ironic the app
developers - who need her help the most - are pushing her away.

OK, so there is a difference between computer science and programming. that's
why there are two different stack-exchanges:

    
    
      cs.stackexchange.com
      stackoverflow.com
    

And we can make even finer distinctions if we wanted to.

it's actually really fucking INCREDIBLE that

* you can know tons of CS without being able to build a decent app * you can a decent facebook clone without having any idea how it works

I feel really bad for Emma. I was a math major, but app developers won't even
look at me b/c I'm not a full-stack whatever. So now I'm a Data Scientist at
an advertising firm in Puerto Rico.

~~~
fnbr
Hey, I'm a math major looking for jobs/internships in data science. Any chance
I could ask you a few questions about your experience finding work?

~~~
mrcactu5
it was a nightmare due to most programmers' ironic contempt for computer
science, let alone mathematics. they consider it a waste of money.

I moved to another country (Puerto Rico) have 2 excellent data scientist jobs
and have enjoyed every day since.

------
michaelpinto
After reading this I have a dumb question: The person behind the post is a CS
major but only played a little bit with the C programming language in college
— is this pretty common these days?

~~~
danieldk
Yes, I have seen many CS graduates who couldn't write C or C++ if their life
depended on it. In fact, I have seen CS graduates who could explain the theory
behind, say, parallel computing in detail, but could barely write scripts.

Knowing everything about painting doesn't make you a good painter :).

~~~
dagw
_Knowing everything about painting doesn 't make you a good painter_

Then again no one automatically expects an art history major to know how to
paint (even though there no doubt is quite a bit of overlap).

------
lucasnemeth
I believe there is some kind of inferiority complex, we don't believe software
engineering is actually worth it. Probably, it is the result of an academic
mindset that is taught at colleges, where the applied fields are seen as less
important than the "pure" ones. But good software engineering, that is,
writing complex systems, with a lot of requirements, maintainable, scalable,
nice APIs, etc. it's very, very hard. And we know it! If we applied our hiring
methods to writers, we would be asking them to improvise a rap rhyme, when we
wanted to hire a novelist.

------
deluxaran
My opinion on this is that most of the interview processes is pretty old(over
20-30 years) and back then a good programmer was also a pretty good
mathematician, and now most of the people that do interviews just use the same
old patterns because, maybe, some of them don't know any better or because
that is what they found in some books they have read.

I tend to hate the interviews that ask me to solve math and logic brainteasers
because I don't see the value in them regarding my knowledge of programming.

------
biot
Math puzzles are great if the problem is easily understood, the solution
achievable without a math degree, and you ask them to solve it by writing
code.

For example: "This database contains 100,000 problems with standardized
parameters. The problem definition is defined in the file spec.txt which you
can grab from our code repository. Write the code to solve these problems
efficiently, passing each solution to a remote service via POSTing to a REST
API, the documentation for which you can find here. Bonus points for parallel
execution. Feel free to use any editor/IDE and reference online documentation,
Stack Overflow, etc. that you want. If anything's not clear or you need a hand
with something, just ask as you would if you were an employee already. Ready
to get started?"

The great thing is that once you've identified a candidate, you can do remote
screen sharing and have them write code before they even have to come into the
office. I've interviewed a fair number of remote people this way and it's
excellent for weeding out the people who can talk the talk but can't program
worth a damn. And it limits bias because you don't care about much beyond
their communication ability plus their technical ability.

------
keithgabryelski
My observation is that a lot of interviews come down to "stump the chump"
questions; a question that is meant to show a single issue the interviewee has
under their belt and is used to gauge the entirety of the interviewer's
ability. Math puzzles/logic puzzles are in the same category: they require
domain knowledge that probably doesn't translate to any job I've ever worked
on.

That aside, one must have a way to measure the abilities of a candidate -- and
asking the same set of questions to many people allows you to compare the
answers as apples to apples.

I generally don't restrict my people from asking any particular question, but
I will ask them to consider what a failed answer really means for the specific
job (questions are generally adjusted then).

As an aside, some questions of mine that aren't specifically about coding:

* do you code outside of work (a love of coding translates to good coders)

* send me a link to some code you've written that you are proud of (let see what you got)

* tell me about a problem you had where your solution wasn't correct (how have you dealt with failure).

------
mariozivic
IMHO, the post is more about the interviewers not understanding what is
important for success in the job they are interviewing for than about anything
else. If you need a person that will have to switch technologies, languages
and paradigms, you have to test for that, make sure a candidate has done it
before or is capable of doing it in expected time with expected depth.

If one is good and quick in problem solving or has high GMA, that does
indicate that he has the capacity to handle new and difficult things in
general, but says nothing about the speed with which he can handle a
particular new thing. Author's example with JavaScript is very good
illustration how difficult can it be to learn a new paradigm for the
first/second time.

------
cicatriz
Here's a writeup about a recent study that showed interviewers couldn't
predict GPA any better when the interviewees answers were accurate versus
random: [http://www.danielwillingham.com/1/post/2013/10/why-job-
inter...](http://www.danielwillingham.com/1/post/2013/10/why-job-interviews-
dont-work.html)

Anyone who supports math puzzles (or whatever else) in an interview would have
to argue that their perception of the candidates performance offers a clear
enough data point that it doesn't dilute other information available to them.
Given Google's study finding data otherwise, they certainly have the burden of
proof.

------
10098
Dear god, what kind of startup hires a person with only basic Java and Python
knowledge, then hands them K&R and expects them to churn out production-
quality code?! That's unfair.

~~~
14113
The kind whose interviewing tactics don't hire staff with the skillset they
need.

------
eaxitect
Totally agree, asking math puzzles (sometimes really hard ones) to develop a
copycat iphone app? Interviewing like this is really off the rails.

I really understand that a startup with scarce resource would like to do its
best shot. However as discussed long ago
([https://news.ycombinator.com/item?id=2385424](https://news.ycombinator.com/item?id=2385424)),
it is really frustrating that asking math puzzles are assumed as the best way
to hire the best for the job.

------
Tyrannosaurs
On one hand I completely agree, on the other my experience of most CS
graduates is that you can't code, at least not in the way that anyone codes in
the real world so it's not a great thing to spend too much time on. That's not
the fault of most graduates, it's what and how they're taught. Most people
coming out of university know a little bit about a lot of languages and
theories. That's good for giving them an overview but not great when it comes
to having actual usable skills on day one.

Because of this I've pretty much given up on hiring graduates based on their
technical skills so instead I'm looking for someone smart, who gets that
they've got a lot to learn, who is interested in technology and can get on
with the other people in the team.

I don't think asking people math questions per se is a great idea, but if
you've studied a maths degree it's a good way of working out if you're smart
and if you were paying any attention at all during university.

(Incidentally this may be different in other countries (I'm in the UK) or in a
company where you're able to attract the very best who have picked up really
solid skills, but for most organisations that's not the case as most graduates
spent more of their own time in the bar than coding.)

------
mcgwiz
Dear poster, don't imply all startups are equal.

If a startup asks you to solve math puzzles, it's possible that the work you
will be doing heavily involves the creative use of math or information
analysis. (This is more broadly valuable than many people recognize.)

Also, it's also possible that that particular startup doesn't know how to
effectively interview.

It doesn't sensationalisticly mean all Startups (capitalization yours) don't
know how to effectively interview.

Also, rather than focus on your ability to learn, I would humbly recommend you
reconsider the basic nature of employment. An interview should be considered a
two-way conversation. You're not selling yourself as a slave, you're entering
into a mutually-beneficial, private, voluntary arrangement. Thus, even someone
who goes into an interview willing to accept anything and everything they
offer could be expected to ask simply, "And what exactly will I be doing?" But
better yet, grill them about every nitty-gritty detail you can think of.
Although some insecure interviewers may be taken aback (I'm guilty of
asserting the interviewer was wrong on more than one occasion, both times
still receiving an offer), I for one am impressed when a candidate
demonstrates a sharp, critical and skeptical mind in this way.

------
theanirudh
Even after reading Jeff Atwood's post[1], it still amazes me how many
programmers fail the fizz buzz test. We dont even get the chance to ask tough
programming qustions. Simple questions like fizz buzz, loops and recursion
were good enough to filter out a lot of applicants.

[1] [http://www.codinghorror.com/blog/2007/02/why-cant-
programmer...](http://www.codinghorror.com/blog/2007/02/why-cant-programmers-
program.html)

~~~
hmsimha
Is this _really_ the case? I read this a lot, but have a hard time imagining
that there exists a wealth of people who have such a hard time with such a
simple task, and yet I am having a hard time finding an entry-level job when
they are (presumably a substantial part of) my competition.

~~~
GFischer
It is. There are a lot of really bad programmers out there.

However, you're probably not looking at the places where such programmers
would apply... try an entry-level job here in Uruguay (pay: about U$ 800 /
month after taxes), you'll get a lot of people that fail fizz-buzz .

The original poster (Imran Ghory) was from the UK, and Reginald is from
Canada. Neither are Silicon Valley.

[http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-
dev...](http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-
who-grok-coding/)

[http://weblog.raganwald.com/2007/01/dont-overthink-
fizzbuzz....](http://weblog.raganwald.com/2007/01/dont-overthink-
fizzbuzz.html)

------
eksith
This may be another reason people are eager to start their own company in lieu
of working for someone else. If the questions are rubbish and completely
unrelated to the actual job, then there's a huge disconnect between the
interviewer (or HR company, as a lot of places outsource that) and where the
actual work is to take place. I blame both.

The irony is that, in an effort to hire the "smartest" people, they leave out
the wisest. Which is arguably more useful.

~~~
jzzskijj
_This may be another reason people are eager to start their own company in
lieu of working for someone else._

If it is so, then it is a good thing. Right?

~~~
eksith
Well, if they really enjoy the challenge (and it is challenging), then yes.
But I think there's something sad about being _forced_ into it because hiring
practices are archaic elsewhere. It doesn't have to be this way.

I don't like it that so many new startups fail and I have a feeling many of
these (besides lacking an idea, failure in implementation etc...) are due to a
lack of other options. If you can't get hired with the skillset you have, even
though it should be more than enough, it can drive you to do desperate things.
Including becoming a founder.

~~~
capisce
I'm sure there are a certain amount of people who have simply given up on or
refuse to subject themselves to the standard interview process and will either
become freelancers or get their jobs through networking.

------
codecrusade
1\. Most IQ tests are Bullshit 2\. We all know what happened to the company
famous for " Who moved mount fuji" 3\. Math Puzzles are good if they are of
the IMO level- but these things need a lot of concentration and joy to solve-
Not under stress interview conditions. 4\. Expecting someone to show
brilliance by solving a math puzzle in under ten twenty minutes is a lot like
a public willy wagging competition 5.Even more disgusting is the semi dumb
questions at Mckinsey inerviews like - "Estimate the number of mineral water
bottles in London" 6\. 7.In 'Jobs', Walter Issacson says Steve was never into
much of these puzzles- I can understand the reason. 8\. ' I think a lot of
what people call intelligence just boils down to curiosity'-(great quote from
an inspirational
friend-[http://www.flickr.com/photos/elizabethbw/8373942339/](http://www.flickr.com/photos/elizabethbw/8373942339/))
9\. People who ask these kind of puzzles end up creating a lot of CPU without
any GPU. Very Little beauty. Very Little love. Disclosure- Im a member of
Mensa Inernational. No Offense meant.

------
tbassetto
Our current hiring process at my startup:

\- After a first non-technical call, we ask the candidate to create a very
small project based on our SDK. We send him the documentation and a very small
sample. He can almost use every tools he wants to create that small project
and, of course, we do not set any deadlines. It allows us to see how the
candidate architecture his applications and it gives us a project to discuss
during the following call. \- If all goes well, we invite the candidate on
site to present our code/project and eventually brainstorm together. So that
both parties can see if they can work together and the candidate has an
insight about how we work, how our code looks like.

Clearly, it's far from perfect and we are often considering changing it.
Imagine if every company where you are applying would ask you to create an app
from scratch with their SDK? We may lose some candidates, but at least we hire
only people that fit the company's culture.

~~~
nappy-doo
I have experienced "interviews" like this from the other end. I told YC funded
founders I'm not interested in their job if this is how they interview. In my
opinion, it shows inability to make a decision.

I am an excellent developer, with years of experience in the industry. I know
lots of technologies, and already have a great job. There is no reason for me
to spend personal time writing your projects, when I would be rewarded by
spending personal time on my employer's projects.

"Interviews" like this will only grab candidates with nothing better to do
than to fulltime interview with your company. In my opinion, the best people
already have jobs, and you're excluding them from the process.

~~~
epo
"I am an excellent developer, with years of experience", but seemingly unable
or unwilling to complete a small practical test. Sounds to me like they are
good at weeding out the wrong people.

~~~
nappy-doo
Check my comment history. I work at Google. I stand on that.

~~~
lawnchair_larry
What makes you think "I work at Google" provides sufficient data to an
interviewer such that they should exempt you from their interviewing process?
The fact that you have a job somewhere else says very little.

~~~
nappy-doo
I'm not saying I'm immune from interviews. I'm saying it's proof I have chops.

Technical interviewing in a broken process. I've given almost 200 technical
interviews at Google, and I've seen all kinds of results. But, I believe
Google's results. Having worked at Google longer than anywhere else I've ever
worked, I can say that the people are incredible, and it's a direct result of
the interviewing process. We interview someone for a set number of interviews
(N≤8 nowadays) and we make a decision. I can count on one hand the number of
people I think are deadwood.

All I'm saying is the "interview" process of having people do projects for you
is broken. You will filter out a lot of people with jobs they are kicking butt
at.

------
gregjor
This is sadly common in a community keen on logic, evidence, and avoiding
fallacies in thinking. Worse than puzzles are pointless faux psychological
screening questions like "Tell me about something painful that has happened to
you and how you dealt with it."

I would (and have) asked if the interviewer or organization has any evidence
to show that interview puzzle performance (or shit like Myers-Brigg) predicts
job performance. No? Not surprising. Google did look into it and found no
relationship. ([http://www.businessinsider.com/how-google-
hires-2013-6](http://www.businessinsider.com/how-google-hires-2013-6))

Programmer interviews are so crazy and sometimes sadistic that I catalogued
some of the more common interview patterns:

[http://typicalprogrammer.com/thirteen-patterns-of-
programmer...](http://typicalprogrammer.com/thirteen-patterns-of-programmer-
interviews/)

------
czarpino
While I agree that puzzles and mind games are silly ways to appraise coding
skills, they do give an insight about a person's raw intelligence, or
knowledge, or _potential_. As CS is an application of math and programming is
an application of CS, being good in math does not necessarily mean proficiency
in it's application; same goes for CS. IMO, a good programmer must, at least,
have:

\+ __knowledge __\- generally mastery of math /CS concepts and can be thought
of as _the_ potential

\+ __application skills __\- modeling a real world problem into a theoretical,
computable, and (ultimately) programmable form

\+ __execution skills __\- implementation (coding) of a solution including the
ability to utilize requisite tools /technologies such programming languages,
DBs, OS, and so on

That said, hiring process should cover each of these areas and programmers
should work on all these as well.

------
swelly127
I have the exact same problem as OP. Getting tons of job offers because I've
been doing competitive math and algorithms since grade school but really have
hard time understand technology. I'm pretty ambitious and I want to join a
small, high growth startup and have the excitement of being part of a founding
team but I'm afraid of letting people down.

I could learn heroku/RoR/whatever other technology but news things are always
coming out and some people keep up with it so easily. I'm not sure being a dev
is right for me if I take so long to understand such basic stuff. But I love
coding and algos! I write python scripts to do all my homework... and then run
them in codecademy labs because doing it in unix makes me so confused.

If anyone has had the same problem please let me know how you got over this
hurdle. Thanks.

background; sophomore, cs major, cornell

~~~
tylerkahn
You say that unix is confusing. Unix isn't confusing. It's just unfamiliar to
you as it was to me at one point. The way you get better is that you push
through the unfamiliarity and keep going until you solve the problem you're
facing. Sometimes it's painfully slow to acquire the knowledge you need, but
that's just part of the process.

All that knowledge accumulates over time and you build skills about how to
learn new things.

That's what allows people to pick up new technologies easily. Hard work,
previous experience with similar technologies, and some intelligence (which
you obviously have already).

I would recommend that you install Ubuntu in a virtual machine (VirtualBox is
a good choice) and see if you can get some Python programs running. That
process alone will teach you a lot.

For what it's worth, RoR and the Heroku stack are not basic and you shouldn't
feel bad for not picking the up quickly. There's so much context that you need
to have to understand what's going on and to use those technologies
effectively. I bet if you polled your classmates the majority of them haven't
even heard of Heroku.

------
jpgvm
When I hire programmers I try to favour ingenuity, knowledge and as best as I
can gauge it, work ethic. For instance I might ask them about a theoretical
task, possibly something like a scheduler or packet filter etc and give them
domain specific data about how it will be used and ask them if there are any
optimization they could make if they had this data about the systems use case.

Or I might ask them to describe how an event loop works.. or what the I/O path
between their program and the disk looks like in as much detail as they can.

Someone that loves the field is going to have a decent idea about these things
even if they never had to build one before.

caveat: these examples are very system level but you can substitute them with
appropriate web, financial etc domain specific knowledge.

------
CmonDev
Start-ups can afford asking candidates puzzles? I thought everyone was
struggling to find developers.

~~~
seabee
Struggling to find good developers maybe? (Or at least ones that get through
their weird puzzle interview process)

------
fayyazkl
Finally some one pointed out the importance of the ability to actually code
and produce something that works. Algorithmic problem solving ability is far
less utilized in actual every day job compared to being able to code. Just
imagine how much of your math skills did you actually need going well through
all those bad experiences? Would you still be considered slow learner and
fired if you knew how to code pretty well but just wasn’t so good at figuring
out shortest path in a graph. Isn’t it possible to know the CS basics well
i.e. familiar with complexity, big Os, basic data structures and sorting and
being able to learn any advanced standard algo when needed by looking it up?
Just wondering….

------
jsun
I think a lot of companies use brain teasers or math problems to test general
mental aptitude, whether it works or not is under serious debate, but in my
opinion that's the right thing to test for (if it's even possible).

The reason is smart people can figure out git, or databases, or objective-c,
or whatever, in a fairly short amount of time.

For example, my co-founder learned objective C off free online video tutorials
and built an iOS app (talking an app with serious firepower and back-end
transaction logic) from start to end by himself in less than 3 weeks.

That's why we're not as concerned about what you know right now as what it's
possible for you to learn in 3 more week.

------
conductr
I can relate on the opposite. I am not great at those complex math problems.
But, I have been coding for 15 years at >20 hours a week average. Mostly web
stuff. I've built dozens of full products, that we're complex, and I generally
feel like I could build anything I wanted. Every time I use a new site I can
visualize how I would have built it, usually not a question of if I could;
time permitting.

Yet, I have never had the balls to pursue it professionally. I build stuff and
usually never launch it. I have learned several times over that marketing is
not my strong suit.

That said, I'd actually like to work for a startup. Hit me up if anyone wants
to talk.

------
rexreed
If you're running a startup, the most important thing to hire for is fit. Do
they fit in your culture? Do they fit a need that will help you achieve your
milestones? Do they fit in the overall growth trajectory of your company? Do
they have competency in the specific area you are hiring for and/or where your
startup is building overall competency? Can they manage themselves and their
time well?

The likelihood of failure of a startup approaches 100%, so you should optimize
for likelihood of survival, not for IQ.

If you're not a startup, then the top ranked comment applies. But it doesn't
really otherwise.

~~~
Thrymr
Except that what a lot of startups mean by "fit" is "they think just like me"
or even, "they have a similar background to the rest of the team." Sure, that
may make them easier for you to talk to or hang out with, but it reduces the
diversity of the team, and increases the likelihood of groupthink. The other
things you mention (after "fit in your culture") are not what most people mean
by "fit". "Fit" is an intangible that can be used by screeners to keep from
going out of their comfort zone.

------
jasey
The interview is a 2 way street. While the company makes you jump through
hoops to see if your good enough, you also have a opportunity to determine if
you want to work for them.

I like to ask "what will I be working on in the next 6 months" that way you
don't rock up and than the second day they through you in the deep end of
building a iPhone app.

Granted, startups only have a vague idea of what they will be programming with
short periods but it helps.

Also ask "what will be my performance indicators". If they don't include
"being able to very quickly learn new technologies" its hardly your fault.

------
Xyik
In my experience, only the really big companies focus heavily on algorithms
and math puzzles. That's because they don't really need to hire anymore
people, they just want to steal 'smart' people, and they don't need to iterate
as quicky. Start-ups and smaller companies have in my experience, typically
asked full-stack type of questions that dive into things like networking
protocols, databases, scalability, and so on. And I believe thats the way it
should be. Start-ups that focus heavily on math puzzles and algorithms are
doing it wrong.

------
Jugurtha
The "Kevin Bacon" stuff was about degrees of separation (Does the expression
"Six degrees of separation" ring a bell ?).

Not long ago, Facebook made that 4.74 degrees of separation on its networks.
Meaning a maximum of only 4.74 persons are necessary to connect any two random
persons on the network.

[https://www.facebook.com/notes/facebook-data-team/anatomy-
of...](https://www.facebook.com/notes/facebook-data-team/anatomy-of-
facebook/10150388519243859)

You can also find an article on Wikipedia about the "Kevin Bacon" reference.

------
fnbr
I found that Facebook was really bad for this. I'm a math undergrad, and I
applied for a bunch of data analysis positions with them.

I was asked, as part of my application, to take a programming quiz. The quiz
consisted of a graph theory problem. I did pretty poorly on it, given that I
have no real knowledge of graph theory.

Had they asked me a question about statistics (or something similarly related
to data analysis), I think I would have actually been able to answer, or at
least been at a point where my programming knowledge- not my math knowledge-
was what was holding me back.

------
joeblau
I would say that you should keep at it. There are strong parallels between
math and programming, but interviewers should definitely be asking you to
write pseudo-code on a whiteboard and do a paired programming session. That
would probably be a good way to relieve the awkwardness later when they
realize that your programming skills aren't as strong as you'd like them to
be. Definitely keep at it, soon you'll be able to think of a Markov chain as a
for loop multiplying two arrays and not only as a matrix multiplication.

------
anuraj
It is a good strategy, if the company is interviewing freshers as programming
is teachable and the assumption is that new inductee will take few months to
become productive. If you can't wait, the best strategy is to give a live
coding problem and test the person's proficiency in the required
language/technology. I invariably do the latter as my requirements are always
very specific. Most start ups I suppose, are themselves undecided on
product/market/technology choice and thus the former strategy.

------
rehack
This is a great post. And also from the other side of the fence. As typically
we see, these kind of posts, from people who did not like Math puzzles, and as
a result suffered in the interview rounds.

But this one talks about getting inadvertent benefit of being good in Maths to
get selected for programming, and suffering the consequences later on.

Also, it highlights the importance of what is mostly taken for granted and
thought of as mundane stuff, of programming - the idiosyncrasies, jargon, and
best practices of various languages and OS environs.

------
etler
Some reasons why math puzzles might be popular:

* CS majors take math in college, but there's lots of other stuff going on with their CS classes so it's hard to remember math class. If you can actually remember anything from math class, you must be smart!

* Programmers like math, even though it's not their job, so interviewing is the only opportunity to have fun with it!

* We had to deal with this crap when we were interviewing so now it's time to make someone else suffer! >:)

------
taude
While we're at it, can we stop treating and thinking of web development (which
seems to be a lot of dev positions these days) like it's rocket science?

------
sudomal
I am willing to bet that tests give an advantage to applicants with no
commercial experience, as well as those that have no life outside of
technology. If that's what you want in employees then sure, it's a good way to
find them, otherwise just look at their code samples and give them a trial.

Programming isn't difficult and you don't need to know complex maths or be
able to solve mind bending puzzles to be a great developer.

------
mindwork
I am stopping to talk with people who ask for such a bs.

Check out the last technical interview task that I got ``` Objective: Write a
program that prints out a multiplication table of the first 10 prime numbers.
The program must run from the command line and print to screen one table.

Notes: \- DO NOT use a library method for Prime (write your own) \- Use Tests.
TDD/BDD \- IMPRESS US. ```

I mean I can impress you but how will this correlate with production code?

------
VLM
Something I've always wanted to ask, are contractors hired the same way? I've
never contracted although my father did in his retirement years. I'm curious
if modern contractors have to put up with this kind of behavior at interviews,
or if its a more professional atmosphere oriented around the actual job
requirements.

------
Killswitch
I'm absolutely horrible at math... I think I graduated high school (my only
schooling) with the equivalent of just above grade school in math... I can
code no problem though. I'm very good at it. Anybody asks me math puzzles I
say thanks for your time, but I am done with the interview.

------
yeukhon
I just saw this on HN...
[http://www.datagenetics.com/blog/october12013/index.html](http://www.datagenetics.com/blog/october12013/index.html)

This is like solving your submarine problem. Jeese.

------
meshko
I don't get it. He got hired? He learned how to do his stuff? If we require
people to know how to work right out of college, no fresh grad would ever got
a job.

------
enterx
You speak wise, my friend.

Isn't XY years of records in the same field of interest working for a
successful companies a good sign that I can code?!

Ask me theory - pay me to code.

~~~
sokoloff
Sadly, it's not. I can't tell you the number of 5-8 years' experienced
candidates from respectable companies who couldn't solve very easy interview
problems.

Yes, I get that a whiteboard isn't an editor, and you don't have google/SO,
and some people just freeze in an interview, but I've long ago stopped
assuming people can code just because they've got coding on their resume for
successful companies. (For all I know at the interview moment, they didn't
have a coding role, or may not have even worked there.)

------
trendspotter
tl;dr

Stop asking this fine young lady math puzzles to determine her programming
abilities. She is good at solving your seemingly pointless math puzzle,
because she was practicing problem-solving since she was ten. But she is not
anywhere near as good at programming, yet - which caused her problems at the
actual jobs she had to do after she was hired.

------
shurcooL
Why not just look at the person's recent commits?

~~~
PhasmaFelis
Because most paid coding work is not public, and many excellent commercial
programmers prefer to do other things in their off time.

Honestly, this is a weirdly naive question. Gung-ho startup culture does not
represent the industry as a whole, and you don't need to eat, breathe, and
sweat code every waking moment of your life to be a great coder.

------
shindevijaykr
really true

------
dschiptsov
So it boils down to "show me your code" and then "please write a few test
examples". To staff up a cheap coding sweatshop this method is good-enough.

In _most_ cases an applicant must be able to read English (to google some code
to copy-paste and occasionally search through documentation) and able to
install and run Eclipse.

The real problem with hiring is that a HR middleman is ignorant and can't tell
a good code form a restaurant menu. So he must give a very few simple
exercises from common text-books with known answers.

The even bigger problem is that almost no one needs _coders_ , everyone wants
_programmers_ which is a complete different set of _analytical and
engineering_ skills.

Coding is just a process of translation of a ready-made by someone else,
poorly understood (if at all) specifications into a spaghetti [Java] code by
calling poorly understood methods of ready-made classes, coded by someone
else.

Programming is a process of understanding and describing reality (in terms of
design documents, protocol specifications, and then, least importantly, source
code in a several languages).

The criteria of success for a coder, btw, is when it just compiles (unit-
tests? what unit-tests?) by the industry-strength most advanced compiler of
the most sophisticated industry standard static-typing language (static typing
is a guarantee from stupid errors, everyone knows) which is even _verified_ to
run correctly on the most advanced VM which incorporates millions of man-hours
of optimizations, unless.. Never mind.

Success of a programmer is when it, like nginx or Plan9 or OpenBSD, is good-
enough.)

------
progx
Because they don't know you, you don't have a well known name, they don't know
what you can and if it is true.

E.g. if somebody hire John Carmack (ID Software), nobody will let him do some
math test or ask him trivial programming questions.

But you are not John Carmack ;-)

It is like in every other job: if you are not a rockstar you are nobody.

~~~
josephlord
Did you even read the article?

The author was not saying she was above simple coding tests but that she was
an inexperienced programmer who was GOOD at the maths puzzles and got the job
then struggled and the interviewer's assessment of her software development
ability would have been better with some software related questions.

~~~
progx
Experienced or not, if you have a known name, nobody ask you silly questions.
Thats all what i want to say.

We life in a world of casting shows, now we (the programmers) are in that
shows too. They run only in companies.

