News for hackers. Stuff that matters.
Re:Coding Interview Cheatsheet by barrkel on Saturday October 14, 2017 @06:41AM (#15471610)
The primary task of a developer in a modern "agile" team is to take a small bite-sized piece of functionality and alter or add code to implement it.

A very large number of job candidates aren't very good at this. So something like it needs to be tested for.

Personally, I love code. For me, an exercise like this is like whittling or molding clay, tactile and creative. I wouldn't want to work for a company that isn't interested in my craftsmanship, independent of everything else at higher levels of abstraction or closer to the business. Why? Because it will hire other people who don't care, and the code will be ugly, and it will be an eternal uphill battle to stay sane.

Re:Coding Interview Cheatsheet by pavlov on Saturday October 14, 2017 @08:00AM (#15471783)
You make the job sound rather dire. Whittling on an assembly line; the meticulous craftsman who polishes corners of industrial furniture. I’m not convinced there is much future for the kind of programming that pretends to be a guild of humble craftsmen inside industrially directed corporations.

Regardless, the coding interview process doesn’t seem to measure creativity or craftmanship. Consider industrial designers, people who actually sometimes do mold clay as part of their job. If a company is serious about hiring an industrial designer, would they administer a test like this: “You now have 45 minutes to whittle a miniature bust of Mozart out of this piece of driftwood. Make sure to talk while you’re working so I can understand your thinking.”

Re:Coding Interview Cheatsheet by barrkel on Saturday October 14, 2017 @03:59PM (#15473917)
Whittling on an assembly line

That's what modern programming is, as I see it. I mean, as you get more senior, you get more control further up the assembly line, but it's still shaped like an assembly line and ideally the programmers are replaceable, because otherwise they become a business risk.

I'm not necessarily a fan, of course. I invest myself in my work; that means I like a sense of ownership, where code is almost like a garden that grows over time. But the business will be concerned that if code is owned by people, resourcing is less flexible and, in the worst cases, individuals can become bottlenecks.

BTW, if you've seen a skilled sculptor at work, you might not be so glib about your 45 minute bust. But of course programmers are not like industrial designers; they're like the mostly unacknowledged craftsmen. Coding is closer to carpentry than architecture.

Re:Coding Interview Cheatsheet by walrus1066 on Saturday October 14, 2017 @07:28AM (#15471713)
Trouble is, this ability is very hard to test for. A test is always an isolated, well defined problem, where the solution is written in a vacuum.

But this is completely unrepresentative of the actual kind of programming tasks at work (in my experience).

Modifying the behaviour of existing code, that you didn't write, in a way that minimises technical debt, is a completely different challenge.

Re:Coding Interview Cheatsheet by flachsechs on Saturday October 14, 2017 @07:52AM (#15471762)
your argument begs the question of whether or not we can successfully test for this trait to begin with.

i don't think we can. the outsized productivity impact a good person can have far outweighs the statistical probability of getting one if you simply accept all competent interviewers, i.e. the expected value is so high that you can blindly hire until you find one, given sufficient financial resources. without the financial resources, you only hire people you already know are good, which is the general pattern i've seen over 20 years working in this industry.