

Hiring Software Developers - HeshamMegid
http://hesh.am/2013/11/hiring-software-developers/

======
RyanZAG
_> "Can you even remember when was the last time you had to write an algorithm
to traverse a tree?"_

Fairly often? There are lots of things taught in comp sci classes you could
have used for your example here, but traversing a tree is not one of them.
Huge amounts of software will have something as basic as traversing a tree and
if you can't remember how to do it even 20 years out of comp sci classes, I'm
not sure you should be writing code anymore.

I'd think that refusing a candidate who can't work out how to traverse a tree
in 5 minutes for an interview isn't a strong candidate for any coding
position. At least I wouldn't hire someone who couldn't. (Give it a try if you
doubt me, if you've done any amount of coding you should be able to work this
one out very fast without ever stepping foot in a CS class, although you might
have to spend 2 mins on Wikipedia first to see what a tree is)

I agree with the article though: best way to hire someone is to give them a
trial run. However, most employable developers will laugh in your face if you
ask them to come work for you as a trial run without pay. At least, I
definitely would.

Paid 1 month trial of remote work is a good bet, but relies on your candidate
not being employed already - and if they're any good, they are probably
employed already. I guess you might catch freelancers though, but freelancers
are not going to agree with the rest of the points in your post.

~~~
parallelist
He says "traversing a tree to find the shortest path". Sounds an awful lot
like he is confusing graphs and trees. You don't really tend to path find with
trees. Am I right?

Trees are very useful. Graphs are occasionally useful. But you can't really
say what is useful until you know it. One of the sadder truths of
education/learning.

~~~
tel
Definitely. In a (directed) tree there are exactly 0 or 1 paths between two
nodes. There's no such thing as a shortest path. In an undirected tree there's
exactly 1 path between any two nodes---even worse.

You might be representing a graph with a tree however if your nodes are
labeled and you want to talk about the shortest path between two nodes
quotiented by those labels.

------
blister
I've hired several junior developers after just chatting without really
getting into deep technical details. With junior developers, I'm more
concerned with the individual being a good fit for our team culture and
dynamic.

With more seasoned engineers, I mostly just ask about projects they've worked
on before. The good engineers that have been a great fit with the team are the
sort that (when prompted) get really excited when I ask about their previous
projects. They go into great detail on cool hacks they made and challenges
they were able to overcome. People that aren't a good fit usually give simple
answers to direct questions. If I have to goad the developer along during the
interview process, it's a non-starter.

And, to agree with some of the other commenters, none of the best engineers
we've hired have ever been unemployed during our courtship phase. We make
every effort to accommodate their work schedule, including having interviews
during lunch time or in the evenings and weekends. Good developers are
generally not out of work for very long, if at all. If a guy wants a job with
us and isn't currently working, it's almost always a sign of some deeper
problem.

~~~
10098
You do realize that disclosing details of a proprietary project that I've
worked on might be a no-no? A lot of us have signed a paper explicitly stating
that we're not allowed to do this.

------
infocollector
Nice article, except I disagree on one point: Forget about a general Github
account. Even having a Github account/or a Github project used by a billion
users - does not prove that one is a great programmer according to me. Perhaps
this a Github advertisement? (Python lover + mercurial user + No Github
Account = bad programmer :-)

~~~
pags
Or that not having a GitHub account with a billion stars makes you a bad
programmer.

Or (gasp) not having a GitHub account at all.

Chances are, if you're a full-time software engineer, you're already spending
a significant chunk of your waking life thinking about\working on code, just
by showing up to work for >= 40 hours per week. Whatever happened to well-
rounded employees?

~~~
IanCal
In my first interview, one question asked was "How do you maintain a healthy
work/life balance" which was really encouraging.

------
skyraider
One problem with "go do a task" interviews is that you can't gauge a company's
interest in you, the candidate, before doing them.

I remember doing a task-based interview once, getting an offer, and having it
retracted after I asked to meet with the team before accepting (they just
moved on to another developer who would accept without meeting the team
first). This was a reputable, respected small company. Clearly, task-based
interviews let them determine who was competent and who wasn't, but I was the
only one who was invested in the interview process.

Payment helps and it's great to see some companies pay for project interview
that aren't even directly related to their technical needs. The company
invests money and the candidate invests time.

------
Phlow
I have gone through a couple of interviews at large companies recently. I have
over a decade of experience, and I can tell you that I know what I'm doing. I
have a real problem with these whiteboard handwritten algorithm problems. I'm
not sure why companies insist on conducting interviews in this manner. It
doesn't represent anything close to how I actually go about solving problems.
Hell, I RARELY actually write anything down anymore, so the slowness and
errors I make in writing just make it that much more distracting.

Why do these companies not just give you a computer and an editor, hell, even
one with code completion enabled, and let you solve the problem that way?

I agree completely with this article. I have not once needed to write an
algorithm to traverse a graph, or find the shortest path, etc. I have RARELY
ever needed to implement a common data structure myself. That's what libraries
are for. People that write library code wouldn't be able to properly write
these data structures in the allotted interview time. It makes very little
sense.

Something else to note. Traveling from one coast to the other for interviews
almost certainly has a mental cost. I have noticed it personally, that the jet
lag reduces my concentration and ability to process.

I'd be interested to see statistics on what percentage of hires were actually
successful when coming from the same coast vs the opposite coast.

------
10098
> Things like traversing a tree to find the shortest path.

No one is going to address the fact that there is only ONE possible path to a
node in a tree? This guy seems to have no idea what he's talking about, no
wonder he dislikes algorithmic questions. Instant no-hire.

------
seivan
Reasonable and sensible article about hiring. Nice work.

~~~
aestra
I don't think just asking for a github instead of a CV is sensible or ethical.

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

------
pleiades7
Great article! I had an interview where they asked me a brain teaser question
that I could not answer. It was completely unrelated to what I do day to day.
These math based brain teaser questions are really out of place.

