|
I have brought up a dozen or so freshies over the last thre years, with mixed results. My approach has changed since the beginning. Initially I would spend a lot of time; casual chats 1-1 and with teams to establish personal bonds, long sessions going over documents, the domain, active support and coaching over progressively harder tasks. This was not successful at all. Now, I just drop them off a cliff. Within the fist week, I have a short chat to get a feel, and throw them a non priority not too difficult task with no deadline. The ticket contains barely enough information. I add them to a few chats, point them to the docs home page and say goodbye. Based on the turnaround time and the quality of the work submitted abd how they go about seeking help I get a REALLY good gauge about their aptitude and attitued. They are either active about doing the task or they putter around and come up with excuses. Don't care much about code quality unless it's actually horrendous. This is great at catching ppl that faked their was through the interviews, the leetcode monkeys and other less desirable traits. Based on this the next task either involves a lot of collab or little to none. As and Bs get a difficult independant task, C's get an easy to medium task that needs a lot of interaction. In both cases they are "prod" issues that, the importance of the delivery and the deadline are stressed, they have to do an internal and external demo at the end. Team members are on standby for support or takeover if absolutely needed. This approach is WAY more sucessful. And stressful as well for the newb, but trial by fire seems to be the best way to get people integrated and being productive. Everything is learning on the fly, domain, process, culture, tools, everything. Compalined about not enough docs? Ok you go make the docs? Didn't like some part of the process? You make sure it changes. Didn't get enpugh support? You schedule the support call. The biggest learning for me was that the amount of time spent coaching was inversely related to the "success rate".
For those who genuinely wish to learn whatever the approach is makes little to no difference, for the others it makes a massive difference. Some hate it initially, but the consensus is that they all appreciate being a valuable contributor. Noone wants to be stuck in the back cleaning up docs or writing sorry tests for so done else's shitty code or doing wild goose chases or ,"ramping up" for months. We have a strong team/collab culture. Everyone is "nice" the worst thats going to happen is that people leave you on read. My advice to all is to not worry about "bothering" people. Bother as many people as possible, ask all the dumb questions. You DM 10 people or post in a GC with 50ppl the same question in a minute. If I don't have the time I won't respond, but someone else will. If you need I'll stay on a call with you for hours while I do my work.
So I actually think the amount of support available remotely is much more than the office, if you get over your hangups. Struggling and being lost, wasting hours or days on the dumbest issue are all part of the process and there's no way around it, so the sooner you get comfortable with it the better. We work in domains where Google runs out of answers very quickly, the SR guys are still figuring things out and half the time noone knows what in world is happening right now. Getting on your own two feet is your responsibility. |
It makes a lot of sense to me, and resonates with the experience I've had both as a noob to programming (or to a new role) and as a person responsible for onboarding.
A controlled trial by fire with asking for help if stuck encouraged.