Hacker News Reader

Comment by anderber | Hacker News Reader

This seems like a reasonable process. However, for me personally, I have a big portfolio of side projects with open-source code. And it irks me if a company asks me to prove my programming skills by wasting my time doing some silly tests, where if they just read my code we would be able to skip it. From all the places I've worked, the companies with the better programmers were the ones where they actually looked at your past code and had hardly any exercise or test.

I think the 6-week "probation" period is an excellent idea. Since most of the time you can recognize if they are a good fit or not.

View on HN

One problem I have with this is that tons of people like to push the "GitHub is my resume" thing, but 75% of the time they have 25+ "forked" copies of major open source projects with maybe one or two extra commits on top.

It can be a real drag to try and suss out who actually has real contributions or real original work on their GitHub. Our approach for hiring is to actually have people cherry pick out one or two items they're really proud of and have them send a brief overview / sample.

That approach is also nice, because it gives you a great interview starting point to dig into a technical item that they (should be) comfortable with and passionate about.

I think that's reasonable too. I wasn't try to say "github is my resume" because in my site I point out specifically projects that I made, and link them to the repo.

Making the person pick out projects they are proud of is a great idea.

Your cherry picking idea is fine, but your reasoning for it is bs. If someone wrote the code (or read it enough to grok it), asking them some questions on the internals will sift out who just copied some free repos.

A great portfolio is a huge plus (and I've hired people purely based on their open source contributions, usually remote), but as mentioned elsewhere your previous code tells me very little about what you're like to work with day-to-day. We usually do something like "here's our mobile app, let's start the process of building it in React - walk me through the process as you go".

We all know devs who write beautiful code but are impossible to work with ;-)

the companies with the better programmers were the ones where they actually looked at your past code and had hardly any exercise or test.

I don't do side projects. I work 40+ hours a week on a computer, when I get home, I'm spending time exercising, with family and friends are just doing nothing.

If a company doesn't think I'm "passionate" because I don't have a Github account so be it.

Also, I'm not going to do a dog and pony algorithm white board coding test. I'll draw out architecture on a white board but if you want me to code, sit me behind a computer and test whether I can solve a real world business problem.

I'm most likely being interviewed to either write/architect a bespoke internal app or yet another software as a service CRUD app. I'm not being interviewed to create software to put a man on the moon.

Sorry for the misunderstanding. I didn't mean that everyone should have side projects. But if you do, why not judge some of it based on that? And if you don't have open-source code to show, then some kind of test seems appropriate.

That code may be the result of months of polishing and cooperation.

An hour of pair programming lets you know what it's like to work with someone. Are they reasonable to discuss things with, etc. On top of learning about their programming and problem solving skills.

It's also a result of me calmly working instead of nervously taken part of an interview. The one thing that I've noticed is that it's very hard to judge someone's personality in these kinds of situations.

Yeah, that's a fair point. Interviews are a little insane however you do them, and still you need to figure out some way to hire people.

I do like this "homework" interview variation: You get to work on a task at home before the interview at your own pace for a few days. Then you come in and talk about your design choices, and are asked to add a feature or two to your code.

> the companies with the better programmers were the ones where they actually looked at your past code

How common is it to actually be able to do this? I've worked at Google and Amazon and Goldman Sachs; I can't show any of that code. I've occasionally dabbled in coding little scripts or projects at home, but nothing terribly challenging or complicated.

I'm not sure how common it is. But if someone does have open-source code that you can review and they'd like to showcase, why not do that? I guess that's all I was trying to imply.

Usually my suspicion is that the code is just a cloned repo or similar.

I have however dug into github code that seemed legit, with the candidate claiming to be one of the primary developers of a popular Xbox360 emulator. I surprised him by quickly finding obscure bugs, including a couple buffer overflows and a way to cause a math exception in the host process.

It does feel kind of unfair to those whose code is locked away under NDA.

A pairing exercise isn’t only testing your programming skills, it also tests your ability to work with other people and get on with them, which is not only important but much harder to train than the technical side of things.

Which I understand, but I also see this as flawed since the person being interviewed will have their guard up and be nervous. This will skew what their personality is really like.

If interviewer has any clue, then they will know that and will account for that in their judgment. Almost everyone is nervous and will not perform at their best.

It can test many things, especially if you physically sit together. I used to have a coworker with an unusually severe fart problem.

Reply on news.ycombinator.com