Hacker News Reader

Comment by Afton | Hacker News Reader

> Wargame out plausible solutions to it if one didn't have your team's context on your particular situation,

My least favorite interview ever, was essentially "Implement this generic problem that our team had to solve, but you don't have the context of our infrastructure, and I'll criticize you every time you deviate from the actual solution we came up with because your solution wouldn't work in our context". It really felt like a "read my mind" type of problem.

No further point. Just glad to see you point out the relatively obvious point that you need to evaluate a question for someone who doesn't have your current context.

View on HN

A good counter to this problem for the interviewer is to pick something that is extra-domain to your problem space. A previous employer I worked with used "Design the object model of a Chicken" as a starting point. The interviewers would then act as a potential client and we'd go back and forth with the candidate over their approach.

Definitely rough on candidates, but it does give a reasonable window into their thought processes and who the interact with other people.

We do this, but in an interactive way, to see the approach taken, additional context given, adjustments made along the way. This really shows how a candidate thinks and if they can on-their-feet. Often we will run out of alternatives before coming to a solution, with many avenues explored. Rarely we will discover a path that may have worked, possibly even better.

I was put through that once, it sucks. You're completely ignoring all the wrong turns you took to get there, the number of people involved etc. Expecting someone to just jump into your shoes and pull of the same trick is not very constructive. What if you framed the problem wrong? Maybe this is the candidate that would have helped you come up with a superior solution given enough freedom and time?

Hmm, this could be a risky approach. If you do it right, it could be a fun, interactive way to suss out a candidate's approach to solving problems, preferred architectures, etc.

However, it also feels quite artificial and stressful, which is a bad combo for a lot of people. Unless the position actually requires rapid fire system design and architecture, I'd be cautious using it as a primary filter. For most positions, designing a system architecture includes include some amount of research, reflection, iteration, etc.

In other words, you're evaluating something the job doesn't actually require (typically), and you're potentially missing out on people who might be brilliant architects given a little time to absorb the problem and think through options.

Reply on news.ycombinator.com