 Hello. Okay. Yeah. Just a quick five minute talk. Sorry for hijacking your JS for again. So I'll be talking about the art of onboarding your next engineer. Right. So it's, I know it's a technical session and everybody was looking for a technical talk, but I think this is a very important thing that a lot of us are probably not doing as good as we could probably do. So it's just like some small benchmarks that I feel I've created for my cell that whenever some new guy is joining my team, I try to follow some of these principles and they might help you onboard your next engineer better. Right. So yeah, let's get started. So the first thing is the day zero. Right. So what a lot of us do not realize is that onboarding become onboarding starts before the guy has actually joined. Right. So the first thing that we need to do is like, if a guy is probably joining your team tomorrow or in the next week, then a friendly follow up actually goes a long way, just a small call telling them that we, you know, looking forward to have them join your team. Right. And ask them about the dev setup that they'd probably be needing. Right. Any specific things that they might need, stuff like that. So just a friendly follow up before they've actually joined and, you know, the clicker is yeah. And then basically this very important thing that I feel should be replicated across organizations is this thing called buddy assignment. Right. So I feel whenever a new guy has joined your company in the first few weeks, they should always be a buddy assigned to him, which would be the go to guy for him to, you know, ask questions, get onboarded to, and all those things. We'll talk more about the responsibilities of a buddy as we go along. But at this point before the guy has joined, I feel there should be a buddy assignment for the person. Right. Moving forward week one. Right. So the guy has joined and this is day one for the guy. What, what should you probably do to make his first day seamless and probably memorable? Right. So the first thing is basically a warm welcome by the buddy himself. So since we've already assigned the buddy on day zero, there should be a go to guy who, you know, welcomes the guy with a warm smile on day first and has a one one on one in probably the morning. Right. This one on one should probably include things like the vision of the company would be probably trying to build how the code is architectured, what the different projects such as look like and probably ask him a little about his preferences and competences about what he'd like to work on. Right. Basically just asking some very basic questions about him and trying to understand what he'd probably like to work on goes a long way in giving him a feeling that he's probably welcome at this new place. Right. Yeah. We all talked about preferences and competition. And the last thing is giving him the breathing room on day one. Right. On day one, we should probably leave the guy alone after the first one on one. He already has a lot of joining documents to sign. The HR is on his neck. They're asking him to submit all those weird documents. So yeah, day one, let the guy breathe, let the guy see what the office is like and just have a good one on one with him in the morning. Now that we have passed day one, what should the day two to five probably look like for him? So the first thing is basically give him all the tools and access that he needs to get his job done. This includes slack, bid bucket, whatever you guys use. Right. So give him the tools for the job, give him the proper access. And this also is a good check to, you know, ensure that your access control, your IM policies are in check so that he gets access to only the things he needs. Right. And we do not obviously want to overwhelm him by giving him too much on the very first week itself. So yeah. And second thing is basically a deaf setup. If your project basically has special setup needs, which ideally it should have very minimal of and then help him set up his first project, give him a code walkthrough, talk to him about the good practices that you've probably developed over time. You know, a lot of different companies have their own coding standards, coding guidelines. So if your company has one, probably give him a small walkthrough of that so that he knows what he's walking into. And the last thing is basically assign him his first task. So the first task is very important. It should neither be too small nor too large. And it should probably involve like the entire, you know, stack of how things work. So it should probably start with creating a task on Jira or whatever you use to, you know, manage your tasks and then assign it to him. And then basically you should start working on it so that he gets the feel of how the entire organization works, not just randomly allocating him a task and expecting him to read through the code itself. Right. So once he's passed that first week and he's probably working on his first task at this point, you should have a detailed code review for his first task. Right. This code review is extremely important because you'd like to, you know, imbibe certain practices within him that he should follow, you know, moving forward. So leave like as many comments about the coding standard coding style that the guy has used, you know, different things that you might have picked on and be as polite as possible here because this is just your standards or guidelines. Right. They might not be universally acceptable, but a detailed code review goes a long way. So that his future PRs look acceptable to you. And there's minimum, you know, back and forth in the future PRs. The next thing is task planning. So now at this point, since he's already completed his first task, you should probably sit with him, talk to him about the project is just contributed to and ask him to, you know, contribute to the planning of the next task. And the last most important thing is demo his progress. So at my current organization, we have this concept of a demo day, wherein people, you know, demo day, town hall, whatever you might call it, where people demo to other people, what they have built over the last week or any interesting stuff that they've been working on. So just giving him the, you know, time and opportunity to demo whatever his first task was, basically goes a long way. The idea is to give him make like appreciate him for the smaller wins so that he can go for the bigger wins in the future. Right. And that's probably it. By the end of the week, two, you have a ninja who's ready to, you know, delve into your code base and be the next good developer.