Hacker News Reader

Comment by Tade0 | Hacker News Reader

I'm leaning towards blaming this on the interviewing process.

Last year I spent some time interviewing job candidates and what I learned from this is that the recruitment process in IT, in general, is broken.

A typical candidate is first faced with some kind of task to weed out the lower 20% of applicants. After that comes the proper interview during which the candidate is asked various questions like what was their major or how is the abbreviation "SOLID" expanded.

In my experience, none of this correlates highly with future performance and this may be the reason why regardless of the school they attended those students performed roughly the same.

Time and time again the one thing that seperates the best from the rest is their ability to perform code reviews. I have yet to find somebody who's a poor developer, but a great reviewer.

View on HN

I believe it.

Real programmers read far, far more code than they write.

Reading code, and writing readable code, are perhaps the two most valuable skills in the profession.

I would extrapolate this out one layer higher and say that communication is the most valuable skill. This expresses itself both verbally and in written form.

That's a good way of looking at it. Code is also a form of communication. By writing code, you're communicating the the computer, with other developers who will come and read it, and with your future self who may not remember what you were doing.

I'd assert reading code being far more valuable, especially when dealing with others' unreadable code.

Interesting. Do you have candidates review code?

I have done this.

Print out a page of code and review it with a candidate. Have them explain what it does, or how they might go about figuring that out, and what kinds of improvements they might make. Include some glaring bugs or code style problems if you want to ask those sorts of questions.

I feel like small fragments of code work well for refactoring questions, whole programs tend to have a bunch of boiler plate code, but going over a bigger program to find the real core features quickly is also a valuable skill.

I've done this with SQL too. Printed out a real statement from an application and ask about performance, optimization, what the application might be doing, etc.

Or load a 100,000k line application in their favorite editor and ask "okay, try to find the frobzing subsystem, I want to know how it frobz bazzes". (I haven't done this yet...)

I have and it has, so far, never mislead.

We have a sample repository with a simple, but broken, web application. We ask our candidates to review the code as they would if a coworker had submitted it as a merge request.

it gives quite a bit of insight about what aspects they latch onto as issues of note. Do they catch the insidious, subtle issues or just the low hanging fruit? Do they understand what stdlib function arguments expect as input? Do they just pass your review through a linter and call it a day?

Reply on news.ycombinator.com