4 ms·
Ask HN: when and how should programmers be judged on their actual written code?
I am checking out great programmers for a project and came across someone with code samples linked from their resume.
I wonder if would-be hirers, if having no programming background miss out on the opportunity to accurately evaluate a potential software professional by being unable to evaluate their code output in a direct manner, whereby another programmer is better positioned to evaluate such output.
Of course there are plenty of other ways to evaluate potential consultants, track record being one, but should codebase quality be a large factor? What would be examined?
This leads me to the idea that a site could be setup for this purpose. Here, excellent judges and code relevant to the client is the key to making any subsequent judgments useful for hiring when the hirer has not clue about programming.
- jacquesm 17y agoI would only go by track record, not by code samples because it is way too easy for someone to get a chunk of code somewhere and display the sample as theirs. Track record is much harder - if at all - possible to fake.
- adrianwaj 17y agoI was thinking that a user profile could be setup and link to code on Github or Sourceforge. If they had code on a client's server, you'd have a way for that client to positively match what's on their server with whatever the profile is presenting as belonging to it.
- jacquesm 17y agoYes, but even then. That code might have a history, it could have passed through several maintainers before it landed with that person. Especially open source projects usually have plenty of contributors to any part of the code. It's a tremendous exercise in trying to establish provenance. edit: On another note, code quality is only one metric. There are others: productivity, being a teamplayer and so on. Those are at least as important as code quality. Someone that can not work with others, is dead slow but produces 'perfect' code might be an asset to one project but a total loss in another.
- adrianwaj 17y agoExcellent point. I suppose the only way to authenticate code is to run a live test, but even then it could be faked, and tests aren't representative of real client work.
- TallGuyShort 17y agoPerhaps a better alternative is to have them write code during the interview. That way everyone has the same chance to produce code, everyone gives you code that you know is theirs, and you have the added benefit of seeing how they think while they're writing.
- seasoup 17y agoAfter interviewing someone in person, so that you do not waste their time, have them take some time to program a take home assignment in a language of their choice. This assignment should take no more then a couple of hours and they should be prepared to discuss why they implemented it in this way, what alternatives there were, and why they did not use them. Ask them to also write any testing code that would go along with the code, so you can see how they write tests.
- Tichy 17y ago"This assignment should take no more then a couple of hours" Actually asking an applicant to code a couple of hours is asking a lot. Usually I bill by the hour, a couple of hours coding could quickly become expensive. At least if you do that, make sure it is an interesting exercise (I like the problems from thesixtyone for example). Maybe another possibility would be to agree on something together with the applicant, so that he can choose something he benefits from.
- adrianwaj 17y agoThis is the most thorough solution, but may be a burden to the candidate. It may be justified though. If you knew people were going to be honest with what they submitted as their own, I wonder if there's a market for online professional judgement of code quality from say a pool of 40 experts. I guess these experts have to be paid too.
- petesalty 17y agoAh, and here we have the crux of the problem with the software engineering hiring mindset today. Over the years I've hired many software engineers and I've never hired anyone based on their ability to write code, in fact I never even ask about it. It's completely irrelevant. Why? Because I've never hired code monkeys. Those I outsource. I hire engineers. Engineers need to be problem solvers, and based on the proper interview techniques we can ascertain if they're problem solvers or not. These people can learn just about any language quickly so familiarity is not an issue. Want to know if someone understands recursion, ask them about recursion. Ask them about the theory of recursion, how to use it, where it's appropriate and possible downsides. Ask how they've successfully used it in the past, when they've used it and it's been a problem and how they solved that problem. Ask them when might be a good time in a project life cycle to reactor non-recursive code. But for gods sake, please, please, don't ask them to write a Fibonachi generator. This either proves that they just finished college, or have one memorized for just such an occasion. Hire engineers, not code monkeys. P.S. If you want to see some of the worst examples of this kind of abuse apply for any Ruby on Rails job at the moment - the stories I've heard boggle the mind.
- adrianwaj 17y agothanks - do you mean that many of the RoR contractors are monkeys or that their hirers do not know what to look for? edit: but when it comes time to code-monkeys, how do you hire?
- petesalty 17y agoNo, I don't mean RoR contractors are code monkeys. I mean that if you're an engineer that specializes in RoR then you're expected to have such an phenomenal breadth and depth of understanding that few, other the DHH or Katz, could fill the requirements. The important thing to understand in your hiring process is not only who you're hiring, but why. If you're just looking to hire a bunch of code monkeys that can crank out fair to mindling code, then look no further than odesk.com. For about $8 an hour you'll find some not bad coders. If you want real engineers to solve problems, well, you'll need to do more work.
- makecheck 17y agoYou can't really trust anything they give you (they could have copied and pasted it from something interesting that they Googled, or for that matter any open-source project), so you have to judge code in person. And you can't, because a whiteboard is not a place to write code. Instead, ask them to describe their accomplishments in detail, including the approaches they took to achieve those things. Ask them how they would solve some hypothetical problems that you pose. This kind of discussion can't really be faked, and tells you immediately what kind of thinker they are.