✔||🤢 Commit or Vomit | Switch(true)

This could easily have been an if/elseif/else.

You could have done:

if(someExpressionA) console.log('yes')
else if ((someExpressionB 
    && someExpressionC) || someExpressionD) console.log('nope');
else console.log('maybe');

Since you're returning on each case I wouldn't even bother with elses...

if (useMissedAppointment) {
  return 'nope
}
if (userHasAngularExperience || useHasReactExperience || (userHasVieExperience && userCanStartImmediately)) {
  return 'hire'
}
return 'maybe'

Of course I'd also extract that second conditon into another method, but that's another matter.

I think the cleanest and most expressive is still this

const hasFrontendFrameworkExperience = userHasAngularExperience || userHasReactExperience || userHasVueExperience;

if(userMissedAppointment){
    return 'nope';
} else if(hasFrontendFrameworkExperience && userCanStartInstantly){
    return 'hire';
}
return 'maybe';

While the code is valid, I think the real issue here is just the amount of conditions you're trying to parse through. Using switch (true) feels more like a band-aid than a solution I would accept say in a PR.

I'm a fan for using switches when we're actually comparing the value in switch(value). Someone mentioned checking for a match in the zodiac. Perfect use case for a switch statement.

When you have to resort to a hacky solution, chances are the problem lies more with the code leading up to this decision than the decision itself.

Why the need for the case statement?

if (userMissedAppointment) {
  return 'nope';
}
const userMeetsTechRequirements = userHasAngularExperience || userHasReactExperience || userHasVueExperience;
if (userMeetsTechRequirements && userCanStartInstantly) {
   return 'hire';
}
return 'maybe'

Also, imo, there's no need to repeat "user" in these flags. You could just say canStartInstantly, for example. There's no ambiguity regarding who this refers to.

How about that (pre-enterprise example :))

//allocate in one place binding of all rules with results
const conditionsEnum = {
  nope: ignoringConditions,
  hire: hiringConditions,
  maybe: mbConditions,
}

let result = '';

//find first truth in there
for (let field in conditionsEnum) {
  if (conditionsEnum[field].some(condition => !!condition())) {
    result = field;

    return result;
  }
}

values in object are just arrays of functions:

const ignoringConditions = [
  () => false,
  () => false,
  () => false,
]

const hiringConditions = [
  () => true,
  () => false,
  () => false,
]

const mbConditions = [
  () => false,
  () => false,
  () => false,
]

Hope my nickname speaks for itself

I'd say probably vomit, but I'm sure there are cases where this way is just easier to read than if/else/return early/etc. Hard to say with placeholder-var-names.

I can't believe some people put hearts

Honestly you made me really curious about the performance... The switch normally are the first choice to avoid writing long if-else chains because the code "jumps" directly to the right place without evaluating all the other conditions... I'm curious to understand if also in this case these considerations are valid or not... I'll try and, if so, it will be an heart

Vomit.
Either a verbose aggregation of desired Boolean checks OR return from currying some composable functions that return a similar aggregation.
I am slightly partial to the second as I believe anyone looking for FP would be.