Yacoset

This pair of articles are surprisingly comprehensive, nuanced, and worthwhile: http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer http://www.yacoset.com/Home/signs-that-you-re-a-good-programmer

From the follow-up[0]: ""Bad programmer" is also considered inflammatory by some who think I'm speaking down to them. Not so; it was personal catharsis from an author who exhibited many of those problems himself. And what I think made the article popular was the "remedies"--I didn't want someone to get depressed when they recognized themselves, I wanted to be constructive." Which I think is fair enough. Besides which, there's plenty of feel-good 'you can do it!' material out there. Some of us prefer a more vigorous pep-talk. Frankly, my impostor reflexes were far more triggered by the 'interviewing is broken' posts on here in the last couple of days; I've got two literary degrees and a big vocabulary. I interview well, despite the fact that I know (counts) two algorithms. I am haunted by the idea that it was my vocabulary that got me hired, and not my engineering potential. YMMV, etc. [0] http://www.yacoset.com/Home/signs-that-you-re-a-good-programmer

the "signs of a bad programmer" post [0] was a response of the experiences of this post. [0] http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer

I wrote this years ago to get it out of my system, and after Infogami went to the big web host in the sky I ported it and my other nonsense to Google Sites. The slightly updated version of the same article is now here: http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer

"I’m suddenly self-conscious about the prettiness of my code — it doesn’t matter if I can solve the problem, since I’m also competing against candidates who can solve the problem, so the real competition is probably about how elegant and idiomatic our code is." This is an incorrect assumption, at least when I interview people. A live coding interview has (almost) nothing to do with the "quality" of your code, and doesn't necessarily even demand complete correctness. It's about observing your process, and trying to simulate what it would be like to work with you: Do you approach a problem with caution until you're sure you understand it, or jump in head first and start writing code you hope is correct? Can you verbalize your thought process and communicate it to others? How good are you at reasoning about the runtime behavior and correctness of your solution? Do you consider edge cases and naturally want to test them? Things like that are won't show up in a take-home coding test, and tell me a huge amount about what kind of programmer you are, and whether I want to hire you. See: http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer - there's a lot of truth to this article, and many of these flaws will be glaringly obvious in a live coding session. And yes, of course some people interview poorly or are just having a bad day. That's unfortunate, but I'm not about to give up a powerful interview tool just because it can have false negatives. Until I find a divining…