> If somebody has been promoted multiple times in programming roles...then you know they can code
That's not necessarily true. There are people in "tenure" roles as I like to call them. They're not ostensibly bad, but they're far from good. They get promoted to senior developer and have pay raises each year. They're not bad enough to be let go, but after 5 years, they're still around and earn a senior title. They're not really in charge, but they're technically in charge with time at the company and the title.
I'm not saying throw deep algo questions at them, but promotions don't mean coding chops.
Re:Hiring without whiteboards
by notacoward on Wednesday March 15, 2017 @11:57AM
(#13876996)
You do have to look at the role. If their role is to code, and they've been promoted recently, I stand by my claim. If they've moved into more of an "architecture" role or the promotion was more than a couple of years ago, then yeah, they might have lost it.
Re:Hiring without whiteboards
by wccrawford on Wednesday March 15, 2017 @02:03PM
(#13878296)
My father often told me that there are 2 ways go get rid of a bad worker. Fire them, or promote them. Eventually, they'll be promoted into a situation where they'll have to be fired.
I don't take "multiple promotions" to mean anything in itself. If they can talk about what they did and why, then I consider that they're probably good at their job. And that's the point of interviews, IMO.
Re:Hiring without whiteboards
by JamesSwift on Wednesday March 15, 2017 @02:46PM
(#13878658)
Government / military like to promote problems away. Helps to keep the person away from the work that needs to get done. The good thing about that sector is that there is a lot of room for lateral promotions to other offices and so then they become someone else's problem.
Asking people to reason about complexity is great, but that's not the way such interviews usually go. More often, the interviewer asks about complexity only so that they can compare to their own solution copied from the best of a hundred other candidates and then hand-tuned for days. It's a gigantic ego trip, and not even a fair fight. Candidates can see that, and it tells them a lot about what kind of person the interviewer is. Hint: it's not a pretty picture.
I was fortunate to go through an interview process recently where I had to do coding interviews, and it wasn't just a big ego trip. Second time in thirty years, vs. dozens upon dozens (all passed) of the worse kind. I could tell the interviewers had actually been trained, because I've been on the other side of that desk. They didn't care about the code I wrote, so much as how I approached a new problem, dealt with edge cases, explained various decisions, responded to challenges, etc. That's how it should be, but doing this stuff right is hard. Very few who pretend to do it have invested the time to do it properly, so they get results that are worse than useless. That's why there's so much hatred of the approach. Most people have never seen this kind of interview done right, and it's not their fault that's the case. It's on people who went from copy-paste programming to copycat interviewing.