It's a start-up with a lot of different projects. It is expected that the work environment would be chaotic. People who look for a no-surprises type of work week should probably not apply to such a kind of workplace.
> Good simple solutions aren’t flashy.
Maybe showing off your skills is making a good and simple solution?
Sure, the work is chaotic. But why would the interview process need to be chaotic? You want to get the best signals of ability that you can, and one thing you can do to help that is to make sure that you’ve given an assignment that will be evaluated consistently on your end and understood uniformly by the participants
> Sure, the work is chaotic. But why would the interview process need to be chaotic?
Because the interview is meant to measure how well someone would perform on the work?
> You want to get the best signals of ability that you can, and one thing you can do to help that is to make sure that you’ve given an assignment that will be evaluated consistently on your end and understood uniformly by the participants
Well sure, all else being equal, but if the cost of consistency is an assignment that doesn't reflect the actual work environment then that may outweigh the benefit.
But why conflate “technical skill assessment” and “ambiguity handling” into one big stressful test?
Doing two small tests toy can measure each skill independently
A clear coding test to get technical skill and then some in person requirements gathering exercise or something to measure ambiguity handling.
You’ll get better insight into their abilities with less effort for the interviewee AND the interviewer (if the startup is really that chaotic, do you really think they are doing a careful code review on a zillion different bespoke takehomes?)
> Good simple solutions aren’t flashy.
Maybe showing off your skills is making a good and simple solution?