Remix clone Hacker News

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?

▲

0_____0 2 days ago | parent [-]

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?

▲

placardloop 2 days ago | parent [-]

> 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.

▲

nottorp 2 days ago | parent | next [-]

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.

▲

nomel 2 days ago | parent [-]

I've tried this, but it becomes very hard to justify, with clarity, why it's a yes or no in the feedback, in a way that can be understood well as it passes through all of those up the chain that are involved with hiring.

And, I've also had people speak very well, doing great with the verbal explanation and questions, even good pseudo code, and then be unable to write a simple for loop, of any kind, in any language. These people also often have a resume full of short runs.

So, I structure mine around a, fixed, work related problem that lets me clearly justify the yes/no in a way that upper management can stomach, but then just bias my feedback a bit based on the "personal interpretation" things like what you describe (which I think are usually better indicators).

Also, resumes are 90% fiction, from what I've seen, especially from certain demographics (not allowed to perceive that though). I don't bother believing them or talking about them, unless there's time after.

	▲	nottorp a day ago \| parent [-]
		> well as it passes through all of those up the chain that are involved with hiring Yes, this mostly works in small organizations. I'm mostly in positions where I have to pass the feedback once, or at most twice up the chain.

▲

0_____0 2 days ago | parent | prev [-]

OK I think we're on the same page, and just had a semantic issue.