Comment by placardloop

2 days ago

The “real problems” most companies want people to help solve involve the evolution of products that last for years, involve repeated design discussions, in depth research, and applying retrospective learning. I don’t need someone that can just glue a Rails API together. If I did, I can literally just download that from the internet for free.

If my problems could be solved in the time span of an interview, why would I waste my time doing that interview instead of just solving it?

I don't see the issue here. Nobody expects candidates to build actual product during the interview. Having a (targeted, scope and time-limited) design discussion or giving your candidate some made-up context around an engineering cycle and then doing a retrospective with them are practical and useful ways to interview a candidate.

I'm also not sure what the alternative is? Just not hiring?

  • > Having a (targeted, scope and time-limited) design discussion or giving your candidate some made-up context around an engineering cycle and then doing a retrospective with them

    You just described a contrived, “unreal” problem.

    > I'm also not sure what the alternative is? Just not hiring?

    The alternative is to come up with questions that are representative of skills related to “real problems”, as you just did, and use those instead. Unfortunately candidates consistently complain that such questions aren’t realistic.

    • I've had some success with just describing what we're doing and seeing what the candidates ask.

      Mind, I work in very small companies and never had to give input for filling 10 positions at once... just one at a time.

      2 replies →