Hiring Software Developers | Hacker News Reader

Hiring Software Developers

hesh.am

26 pointsHeshamMegid27 comments

> "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.

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.

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.

The shortest path in a tree is kind of a pleonasm.

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.

I've found this sort of generic statement ignores the practical aspects of a hiring decision. Maybe we need to qualify the definition of 'coding position', but I'm thinking of my entire devops team. I'm pretty sure I'd get some sideways looks if I asked many of them how they would implement tree traversal. And my devops team kicks ass. I don't know that a filter on tree traversal helps me in hiring more people for that team.

In keeping with the article, what we really care about is whether someone can be productive and learning how they are productive. It's not uncommon to find a disconnect between computer-science competence and acceptable developer output. I've watched candidates execute whiteboard graph traversal & shortest-path exercises quite well, but their actual code output is just silly. We're still working on finding the right way to detect that ideal mix of "smart and gets things done".

Would they be able to operate on folders and subfolders recursively ? That's tree traversal, and important for devops ... maybe you're talking about doing it in context vs out of context ? or your devops are mostly sysadmins ?

Certainly, and yes that is tree traversal, but we don't refer to it in that manner. We refer to this in the context of recursion and iteration. Our interview process for devops is focused much more on practical application.

Po-tay-toe, po-tah-toe I suppose.

I think you've hit on the exact issue here: it's not that anybody disagrees that their coders they are hiring need to be able to do tree traversal. The issue is simply that we have given a complicated name for something very simple that every coder already understands. It's simply a communication issue.

>Paid 1 month trial of remote work is a good bet, but relies on your candidate not being employed already

Most importantly it relies on the candidate not having any other options. Why would anybody interrupt their job search for a month just for a possibility to fill your vacancy?

For a month's income, and a much better shot at a job. In the context of the job search, that's a pretty good deal.

Is it? I can only speak from my experience but I've never been in a situation where I had only one job offer after a couple weeks of search. Neither any of the candidates I'd been interviewing had that interview as their only option.

It could be a way to go if you are hiring in a small town with no competition and the prospective candidates value not having to move much more than possible better offers elsewhere. Same if the candidates are not able to get many offers and appreciate the value of just a good shot for one.

I think the source of the perennial confusion over this issue is that some software development is actually engineering, but most is greese monkeying. The software mechanics resent the engineering questions but the engineers can't understand how you could not ask them. In truth the work of both camps is fundamentally different.

> The software mechanics resent the engineering questions but the engineers can't understand how you could not ask them.

The "software mechanics" resent an engineering question being used as a hurdle for a job they know does not involve "engineering". While the employers are looking for a "software engineer" at a "software mechanic" price.

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.

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.

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 :-)

second that. I find amusing when they say "don't bother applying without github account" smart way to lower the bar.

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?

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

It also ignores anything you've done close-source for work, any projects you've done that didn't use git, any projects you contribute to that don't happen to be hosted on github, anything related-but-not-code that you do (speaking at conferences, etc).

I've found when people talk of a "github account" they just want to see some code, not that github is in any way required. Kind of like calling a cola a Coke, or a copier a Xerox. Have yet to hear a negative comment about my bitbucket account.

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.

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.

> 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.

Reasonable and sensible article about hiring. Nice work.

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

https://news.ycombinator.com/item?id=6728417

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.

Reply on news.ycombinator.com