I'm not sure what exactly you're reading in my words, but I don't really understand why you think it's my "effing job" to provide training for inexperienced developers. My contract stipulates no such thing, and despite what you seem to assume, I have been in fact hired to find solutions, and write code.

It's a little disconcerting to see someone make such self assured inferences about me, based on a single comment.

when i hire someone, their job is to do whatever it takes that is in their capacity to move the project forward. if it takes a larger team, then getting new team members up to speed is part of that. and if that new team member is unfamiliar with the frameworks the team is using then training them on that is part of the job too.

Are you just telling me that you don't want to do your job properly as a hiring manager, which in my opinion would be to get the best people for the job, and that you prefer to pass the buck to your team to train them?

I mean, sure, that's fine if this is stipulated from the start, but if you expect someone to solve leet code, do programming homework, and then when they get hired they have to also navigate your extra requirements and teach people the basics of their job (because probably you couldn't be bothered to pay enough) then in my opinion you're taking advantage of these people pure and simple.

And to top it off, I know managers sometimes fools themselves that the team is invested in the "project moving forward", but that's rarely the case. As an individual I probably don't give a damn about the project, unless we're solving one the big issues of the world. The bullshit CRUD application you work on, or the latest cryptocurrency is just a means to get a paycheck for most of the people, and if you expect anyone to fake enthusiasm for it you're just deluded.

the best people for the job are not necessarily those that need no training. there are a lot of things to consider. part of that is that while new hires may need training, they also bring experience and knowledge to the team that others can benefit from. training doesn't only go one way.

you seem to prefer working on your own, neither willing to teach nor learn from others. that's fine if you can find a job as a lone developer, but i don't consider this a suitable attitude for working on a team.

> Are you just telling me that you don't want to do your job properly as a hiring manager, which in my opinion would be to get the best people for the job, and that you prefer to pass the buck to your team to train them?

Not all jobs are simple enough to hire people into with generic skills. People need training. Even if it's just "I think that other team should prioritise this feature for us; who do I ask?" People need to ask questions and bed in over time. If you've just done simple CRUD apps in small orgs you may not have seen this, but that doesn't make it not the case.

> And to top it off, I know managers sometimes fools themselves that the team is invested in the "project moving forward", but that's rarely the case. As an individual I probably don't give a damn about the project, unless we're solving one the big issues of the world. The bullshit CRUD application you work on, or the latest cryptocurrency is just a means to get a paycheck for most of the people, and if you expect anyone to fake enthusiasm for it you're just deluded.

You seem to keep on inventing things no one is saying to respond to. If you have a load of unrelated things to get off your chest that's fine I suppose, but it seems you actually think people are saying this and you're making points in response to them.

I care, but I care as a result of some projects moving forward being part of my annual goals and affecting my bonus. I agree with the spirit of the post though.

Aka "hands off management", "or absentee boss" or "sink or swim". Love it! Let me float an idea though, I might be dreaming here, but what if there was a better way than just dumping people and resources and hoping for it to work?

How about you encourage the team to actively monitor where onboarding takes time, year by year, learn from that, make onboarding materials which encompass institutional knowledge, and make the process as much self serve as possible?

Or assigning a "buddy/mentor" like persona that is responsible for this specific onboarding, so the rest of the team don't get distracted + the expectations on delivery are lowered for the "buddy"?

> it takes that is in their capacity to move the project forward

It takes quiet and uninterrupted work and focus time, and spending effort on making onboarding as smooth as possible. Just hoping your devs will do all the work of onboarding + their own work, and you doing nothing, that's just...what I expected I guess.

you are reading way to much into what i said. nothing what you are suggesting has anything to do with it. we all have work todo and we all need to contribute to training the new hires in some form. this has nothing to do with hands off management. i am not saying: here is the newbie, get them up to speed, but: we hired someone new, and we need to figure out the best approach to get them integrated. for me that includes that they work with everyone on the team for some time. including me if i am still involved in the development myself. i'll do my part of the onboarding and everyone else will do theirs.

being that buddy/mentor is part of your job, and i expect everyone on the team including me to be able to take on that role as the situation demands.

moving the project forward takes quiet and uninterrupted work and focus time

and it takes making sure that all team knowledge is shared with everyone. where do you get the idea that i do nothing? it is my job to allocate resources properly, but it is also my choice how to to do that.

you seem to look at onboarding as a kind of burden that i throw onto you on top of your other work that you'd rather not have to deal with. i see onboarding as part of the process to grow our team, exchange knowledge and experience and enable us to do ever better work.

when i am starting a new team then i onboard/mentor everyone myself, until the team is grown enough and some of the team members have enough experience to share that role. eventually, the team will be large enough to divide up into multiple teams, but i am still the one doing the hiring, and i'll be involved with onboarding until the company grows so large that it no longer makes sense to do that personally. but at that point i'll still make hiring decisions because i feel that hiring the right kind of people is to important to completely delegate.

the attitude that i expect from my team is that everyone is made welcome and we all do our best to get them integrated. onboarding materials can't replace that attitude which i see as necessary for the team to work well together.