On asking job candidates to code

The final round of on-site interviews usually eats a whole day, and is preceded by a whole battery of time-wasting phone interviews, which themselves eat as much time as a coding challenge and often involve coding with someone else over the phone or Skype.

There are companies that are not Google that have multiple rounds of on-site interviews.

I can certainly still program, but interviewing...I'm tired of it. Tired of being asked picayune questions like I just graduated. Maybe I should I change my CV title from 'Senior Software Engineer'... that actually implies 30-something, late 20s. but what? "Part time CTO and dog's body for a few small startups/companies"?

I know I can do most anything I put some effort into, the relearning process is not hard. But everyone wants a warm body they can immediately plug in. I get interest due to my CV, but they want to stick me into jobs I'm too senior for. I need to figure out what to change... or tell recruiters, no absolutely not, no more front end work, ever!

well, my advice is start planning your career change now - I wish I had 10 years ago, instead of merely idly thinking about it.

More established companies will probably have 30 to mid 30 as the median age, and will have much more professional hiring process (relatively)

Also there is a saying that goes around: A's hire A's, B's hire C's

There are cases where you will be declined as "overqualified" or "no cultural fit" when they mean "will replace my job or at best make me look bad" and "too old" respectively.

I wouldn't give up yet. There are a lot of software architect positions if you have the relevant experience. Median age is higher than 30 I'm pretty sure.

But the "we don't have enough developers" is a blunt lie, "we don't have enough excellent developers" is also a lie. "We don't have enough rock star developers who are ok not being paid enough and have no aspiration to become team leads and just want to code all their career and work overtime" is probably more accurate.

To me, the most useful question is this: "here is an example project that we'd be likely to do, how would you build it?" Then you just let them walk through the steps they'd take.

From there you can launch into why they made the choices they made, trade-offs, philosophy, etc. When you hear people explain how they would make something real, you start to learn a lot of things about them without even needing to ask, and so you're less likely to get scripted answers. They're also probably in their comfort zone at this point, so you get to see them in a more real way.

I don't necessarily mind "homework" style projects, but I tend to shy away from that sort of thing as it's not always respectful of the candidates time.

Two questions I usually avoid (but see getting asked all the time): puzzle questions, and language trivia. I don't ask puzzle questions because I've never seen it correlate to something useful. Most puzzles require an "aha" moment where your subconscious bubbles up some kind of answer, but the easiest way to short circuit that part of a persons brain is to put them in front of strangers with a time constraint. Puzzles might give you a clue as to a persons overall IQ and confidence, but it won't tell you a lot about how they can do the job.

Puzzle questions are also "expensive", in that they usually put a candidate on edge, and they set off the candidates bullshit detector. Let's keep in mind that we're going to reject the majority of candidates, statistically speaking, but you still want them to think highly of your company. If they feel like they're being rejected for a BS reason, you've just created animosity towards your company. It's important that the people you reject still feel respected.

I don't ask language or framework trivia, as I don't think it's useful. I might lob a softball about a framework just to make sure they've actually used it, but I'm not going to ask something hard.

Codility.com is a software as service company that automates this.