I can't emphasize this enough. Successful interviewing is about pattern matching and what this really speaks to is more people means greater risk someone isn't properly calibrated on their pattern matching and their feedback negates someone else who's pattern matching is spot on.
Interviewing sucks...
The best jobs I had I just started on -trial- or whatever doing good work on their GH and from then i'ts pretty easy to know if we're a match or not.
(Paid) Trialhires should be a more common thing.
Companies should hire and fire more easily. I just don't understand I work mostly as a contractor so they really can fire me with 1, 10, or whatever days in advance...
It's not like I'm an employee with protection to being fired or compensation or whatever...
Why so much hassle?
For fresh graduates this might be more viable, but internships are already a thing.
Once you are in your... 30s 40s 50s etc, maybe family and mortgage... You're not going in for a two week trial hire.
ANd it may not make sense for companies either. A lot of positions I hire for need 3 months to be productive. The level of business and client knowledge, as well as prices and policy understanding required for tech positions is high. That may not be the vocal HN experience which is a lot about interchangeable tech on modern frameworks but I think actually comprises a lot of enterprise IT. Basically we need to invest a lot in you before you are productive and we can truly judge fairly your actual on the job performance.
Heck if you work for public sector, you may not get your laptop and Id in first two weeks at all :-)
Whenever I read this advice, I get "indie game developer" vibes. Indie game developers wear many hats and need a lot of breadth for obvious reasons: they don't have a lot of funds, they don't have a lot of people, they don't have a lot of specialist work you'd need someone for full time, but they do have a lot of different things that need to be done.
Then I compare it to your regular corporate job, and it's the opposite in many ways. Tons of people. Tons of funds. Some people very specialized, some people somewhat generic for flexibility purposes. It makes me question why a developer in a corporate setting would need high levels of "business and client knowledge", or even "prices and policy understanding". Not because they aren't useful in theory, but because there's almost always someone with far more knowledge and decision-making power pulling the strings, to the point having such dedicated knowledge is more a waste than anything. The developer can't get to their level without sacrificing development time, or being with that company for a ridiculous number of years.
And we already know companies in general aren't optimizing around long tenures.
And "business knowledge" is meant to be at a technical/tactical level, not at a strategic level. For example, an ERP developer implementing a new HR functionality benefits tremendously from being aware of HR law & process; a developer implementing T&L functionality benefits from being aware of T&L processes and business requirements; etc. This makes it a productive conversation of peers between functional and development teams, and they help each other create true and accurate requirements and specs that cover the edge cases.
A developer that ONLY knows the technical aspect, in my world, will virtually forever be a "junior" developer, as I cannot send them to meet with functional teams solo and expect useful requirements to be gathered or correct code to be produced.
The "client knowledge" is for process & procedures. Again, a developer that is junior/new to my project (they may be senior otherwise) will not have sufficient understanding of how our current public sector client needs code created, reviewed, approved, migrated, validated, etc. There's heaps of procedure... I'm not saying that's necessarily a good thing, but it's a fact of life in much of enterprise IT.
Overall point being - 2 weeks trial would not work on any level. Developer would not know process and procedure, and would not have sufficient understanding of client's business and functional requirements and processes, to be productive yet for all but most generic and trivial of tasks.
Finally, to your last point, my project / department / team / org does optimize for long tenures (that is of course empathically not the case in some other business units in same company that I'm aware of have different business plans and methods predicated around fast turnover). Each person is consciously an investment in continued training and support. We are pragmatic about turn over, but we do optimize around and crucially for people sticking around.
My 100 Croatian Lipa, FWIW :-)
In my country all companies are having a 3 months probation period, when they can fire you without notice or reason, as the laws allow it.
A trial period could be the same thing but it could also be "We usually extend permanent offers to about a third after the trial period." If it's a formality that may be one thing. If it's an extension of the interview process, that's something else.
I think, to sibling poster's point, there's a massive difference in approach and reality to both company and employee in "hop on, maybe we'll fire you if it doesn't work" (probation), vs "hop on, maybe we'll hire you if it does work" (trial).
I for one am not at a point in my life where I'm even remotely interested in trial hire, either as hiring manager or an employee - FWIW, YMMV :)
I think it’s due to conflicting goals. The department hiring wants to lock in the employee so they can cross it off their todo list, and fix the cost. They don’t want to train a consultant who’s still lining up other work. Once the consultant has been trained he or she is in a better negotiating position since they haven’t agreed to a salary yet.
Corporate wants to require a probationary period so they can wiggle out of it with least expense in the unlikely event they have to.
Ideally after a probationary period the employee can renegotiate their compensation, but this is seen as bad faith and holding the company for ransom and creates bad feelings.
He complained about being short staffed and not being able to handle the cooking work while being sociable with customers (he’s one of those guys who sits down with his customers).
I asked him what happened to his last chef. He said he trained her up and she quit, so now he’s screwed. I asked him if he could have kept her if he paid her more. He looked at me like I was crazy and said she was already being paid too much. I responded, Oh, so you couldn’t afford to pay her more? He said it wasn’t about that, it was just crazy that he should have to pay her more.
I kept my opinions to myself and just said “I hear ya. That’s rough man.” He said “Loyalty is dead”…
I didn’t make up a word of this.
Not saying it's a perfect process, but just providing a counterpoint that our process actually seems more likely to help someone with the rounded set of interviews we have than we would with fewer.