[Goopplesoft]

> 5 minutes of resume discussion > 45 minutes of coding

As anyone else found that a good resume discussion is often much better than the coding component? I've concluded that implementation difficulties, decisions made (tradeoffs, technologies, etc.) and the collaborative environment around projects, are much better signals than the code part of my interviews.

If you've dealt with a broad range of tech and can ask the right questions, it's relatively easy to get a strong signal from a candidate by having a deep discussion on their work on prior projects. Both are needed and very useful.

[majormajor]

Yeah. If they can't tell me about what they've built before, and aren't a less-than-one-year-away-from-school new grad, I'm going to be wondering how they deal with real problems regardless of whatever they can do algorithm-wise.

If someone can talk about what approach they took, what other approaches they considered, what made it hard, what made it easy, how often the requirements changed, etc, then I'd rather ask them questions about that then spend the whole time in code. Just do some small spot checks to make sure they aren't taking credit for the work of others.

[Goopplesoft]

> Just do some small spot checks to make sure they aren't taking credit for the work of others.

Agreed, asking tough technical questions on this front gives a really solid indicator of a 'bullshitter'. For example, I often ask people to diagram a prior project architecture they worked on, and then ask them very fine details of how things work and try to challenge them with alternative approaches to see how they react. I get to experience working with them during the interview through which I learn if they're smart and capable.

[Clubber]

Absolutely. If a person can't tell good from bad with that, they shouldn't be interviewing.