"Prices" was meant to be "process", but too late to edit :(
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.
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 :-)