Well, first make sure there actually is some "mission" there to "believe in". In 99.9% of the cases people work on perhaps technically exciting but impactwise boring industry projects, whose main mission is to make money. Requiring passion is a euphemism for being over-workable. That you'll work outside working hours, you can be called during vacation etc, because of course this job is the mission of your life, right? Otherwise, you're not passionate...

In practice, these "passionate" people are often young and naive or just really ambitious and work their ass off to build their resume and will be on their way soon enough.

A good engineer contributes high value and knows this. And therefore will make the company pay up, and will not take any bullshit. And being that good, they will be picking where to work and you as the company compete to get them. In these cases the interview is about the engineer judging the company and looking for exactly things like the requirement to "believe in the mission" or whether the conversation is on a professional, adult level.

That's definitely true in the general case. Having passion means wanting to do the best overall thing because you care about the thing going well. The best overall thing is working hard to prevent long hours which lead to burnouts. If you have managers and senior leaders who share the engineers passion, this problem is self-correcting.

Source: I frequently lecture our (junior esp) new hires about working too many hours. Especially during incidents. Yes this is exciting. Now go sleep and see your family. Come back when you are rested and ready to play at full speed.

I also have uncomfortable talks with people who frequently say "meh, close enough" about whether they actually want to be here. My team performs at a consistently high level.

It's kind of mutinous, but it's not like there's anything to be gained from loyalty to management who aren't loyal to employees.

It goes both ways. The current equilibrium, at least in the US, is that (SW/IT) engineers leave after ~2 years, and it's causing quite a bit of friction. But it's hard to move out of the equilibrium.

I don't think it's so much an equilibrium so much as a battle, denoted by "friction," but I'm sure it would come down to each saying the other one defected first. I think we can figure out where the disloyalty started, calculated from the first principles of capitalism.

Passion, imo, is an attitude - and is reflected in quality of work and teamwork. I do think it is often used to trick people into getting less than they deserve, but doesn't have to be the case.

When I say I want to work with passionate people, I don't mean people who are willing to work 80 hours a week for 10 dollars an hour because they love coding or want to solve world hunger. I mean I want to work with people who give their best, put the user/experience first, and are genuinely motivated to do good work. This doesn't mean you have to fake smile, or get taken advantage of, it just means you have bring some positivity to the table.

This is the issue with signalling passion - it causes people to drive their expectations of you higher. You have a higher chance of not living up to someone's standard.

Yes. Makes me think of Zappos, the shoe store. They're big on demanding employee enthusiasm.[1] But in the end, they're just a shoe store.

[1] https://www.zapposinsights.com/about/core-values

I've seen the contract-to-hire stuff come back up recently. There are a couple big flaws with that model, beyond possible abuse, though.

1) You basically are excluding yourself from any candidate that still has a full time job. It would be crazy for them to leave their current gig for a place that might not actually bring them on full time.

2) It doesn't scale, bringing on new team members properly takes time and effort. Not only are you potentially wasting their time, you are also wasting your team's time, and you can only do this kind of evaluation so many times.

I do agree though that the standard interview model doesn't make sense. Memorizing leetcode problems doesn't map to good engineering, and take home problems filter out a lot of good engineers that won't bother spending the extra time.

I fully agree with you about temp-to-hire or work-for-a-day models. And I think if the company has such a process in place, it is the sign of a well-developed culture. It is exactly the point of the blogpost -- evaluate using the right metric for the job. However, this is rare in practice, and I would say for the same reason the well-established culture is rare: it requires a lot of work to be done by the very same great people in advance. It is a chicken and egg problem. I saw countless times in multiple companies the signs of immaturity that prevent them from giving people access to their production: secrets in git, shared accounts, lack of established onboarding and offboarding processes, no processes for credential rotation, absence of audit logs, legal issues, you name it. The majority of companies can not afford a work-for-a-day option.

Maintaining the dedicated challenge is another option for them, but it has its downsides, too. In our experience, the main one is that you either invest in creating the grading infrastructure upfront or spend a lot of time manually grading the submissions. Checking the correctness of the code is a hard task unless one can actually run it and see how it performs under a barrage of tests. I'm not saying there should not be a code review, of course. I am saying that the automated assessment of the code should be done before you start spending human time. Machines are cheap, your engineers are not. And at this point, one doesn't need AutoIterative, but has effectively reinvented it :)

We walked this path ourselves over the years. We did fizzbuzz style interviews, that was suboptimal. We graded challenges manually for a long time, which was tedious and error-prone. We made all the mistakes and tried to fix them. We were using the wrong metric.

Qualitative improvement was when we started using the right metric, and automating its assessment was the next logical step.

There is your problem. You are testing for something unrelated to the job.

Interesting, why do you think was this the case?

There’s also the aspect of working with the rest of your team on whatever problems you are solving and not siloing yourself to just the problems you’re working on.

That and when you’re hit with new and interesting problems that have never been solved before, you cannot look those up in the leetcode manual and memorize them to solve. You have to actually create something on your own and apply whatever you’ve learned from programming in the past.

It’s like playing a survival video game with the detailed how-to always at your fingertips versus being in the wilderness having to survive on your own wits without a guide.

Any sensible developer learns early on that mostly the coding is the easy stuff - what Is the problem I am solving here?

    - using http apis and transforming the resulting data
    - using database queries and transforming the resulting data
    - navigating a large codebase
    - figuring out what tasks are important to accomplish
    - researching things you don't know
    - debugging a complex issue
    - evaluating tradeoffs
    - general engineering intuition

thanks, can be useful tips for my future staff recruitment.

That's understandable any one with that much proficiency on leetcode would be wasting their whole day on that site than building real things.