Hello, everyone. And I hope everyone is having a really good conference so far. I am also a firm believer in what they call soft skills which is strange because it seems to be the kind of skills that are the hardest to develop. I am also based out of Chicago. I'm a hockey girl. Baseball happens in a season that is way too hot for me. So, let's get started.
Remote mentorship is extremely important because those first few years of any new career is daunting. It can feel isolating and overwhelming when there isn't someone to shadow or tap on the shoulder when things get hard. So, we're going to spend the next 20 or so minutes going over practices to help set juniors up for success. But before we get into it, again, I am Amy Arambulo Negrette, and as mentioned, I am a software engineer that has been around professionally for 15 years. And during that time, I have spent a lot of it interviewing and mentoring juniors and interns.
So, let's get started in where the problem is. So, there's this expectation that we have. Now, granted, it's been a while since I have been in school. But the idea of an internship was glamorous. There were activities and field trips and you rubbed elbows with leaders in your space. Like that movie The Internship but with less numbers and more dated references. But then the start date, and things are different in remote culture. All the highly-publicized perks from the social media era start, Foosball tables and indoor slides just aren't there. They don't feel the buzz of being surrounded by the crowds and the tech. And as veteran technologists, we still see it. And we know where the fun channels are. But it isn't as obvious when you're just looking down that long list of Slack channels.
Who do you talk to when everybody is just a name tag? And that's where that anxiety comes from. It's coming from the uncertainty and frustration and the total disconnect between the expectation and reality. So, let's step this back. The first thing we have to remember is where our team a members are coming from. They're freshly out of school, or for most interns, they're still in school. For most of us, school was a long time ago. And in higher education, the way school operates is so incredibly different from the way businesses operate. Schools are back to being in-person. They prioritize attendance over rest. Solo contribution over collaboration. And siloed work over collaborations.
So, when they come to you, you'll see hesitation. Sure, they'll take that 5-page long list of onboarding tasks that you give them and they'll knock those out. Very often, the minute they get to their first real task, they'll freeze or they'll burn a couple days on a tangent and stress themselves out trying to find their way back.
So, the first thing you need -- ooo... it's trying to cover my slide. Don't do that. Sorry about that. The first thing you should do is try to set some work hours. This has always been a problem not just in interns, but in junior engineers. I know when I started, I would work a bunch of extra hours that in retrospect I probably shouldn't have because I was enthusiastic and ready to work.
And that's just going to happen. That happens when you're young and enthusiastic and ready to work. And you just have all of that energy. And you'll just work until you're not working anymore. And this establishes poor behavior and a total lack of boundaries which, by the way, will be the theme throughout most of this talk.
Working hours isn't just working hours. They aren't even just productive hours. Any time you said "Working hours," what you say is if you want to talk to me, you can talk to me during these hours because these are the hours I can focus on what the company is doing. It's hours I'm not spending on school work or I'm trying to also help a different community or any of that -- any of that. This is dedicated focus time I have to whatever this job is.
Excuse me. And it's easy to let that get prioritized over the things you actually need to do like taking care of yourself and making sure you have breaks and time. And also, there aren't intern lunches. So, make sure that they do set up that time. In remote cultures, those of us who are used to this -- to the way this office works is this is an hour I have to myself. I'm gonna eat, maybe read my Slack and catch up on some emails. But otherwise, I'm gonna make sure that I'm prepared for the next block of my day. If you do not already have that discipline already in check, it's going to be very difficult to develop it without any kind of guardrails. So, make sure they split up time where you know that they're not just burning 8 hours after coming out of classes.
And also, make sure that you know how many hour they're actually expected to work. Maybe the intern program you're running is only 20 hours a week and not 40. Maybe you have sometime during the week, but most of it happens on the weekend. Don't set up their intern projects in a way where they're expected to do it and they don't know how to tell you, no, these are not what my working hours are. I thought I was sign up to have them work in this other time. And as -- as a team lead or a team -- or intern mentor, it is up to you to actually know what those hours are and not expect them to tell you.
And also, know what their holidays are. Because I've worked with a lot of people who aren't on the same calendar as me. Or maybe they have personal holidays and personal time that they want to take that is not directly reflected through the company calendar that they happen to live in. So, you don't want them to think, it's okay to work through my holidays because something critical has to go out. In most cases, your intern should never be working on critical work. Your junior should not be launching products. Not by themselves. Have a senior. Have a lead helping -- helping them and structuring it so that they can contribute without them bearing the responsibility of something going wrong.
And if you establish these practices early, they feel confident later knowing when they can or cannot answer questions or do work or do check-ins. And if they're able to establish this as a junior it will be less frustrating for therm as they move on in their career. And even as going to school, being able to set aside that time for themselves so they do not burn out in those first two years.
The second part is active collaboration. Now, I work in developer relations, but I used to be an application developer. I used to be an IC. I used to be knee-deep in code at any given hour and the only collaboration tools we had back then were version controls and that person who is sitting right there.
So now there are so many things you can do. You can use VSC Code paired programming mode. You can use screen shares. You can use Zoom calls. There's so many more options that you have now that there's no reason you can't see what they're doing while they're doing it. And this does take a lot of your time. As an intern mentor, you will find that just the hand holding alone is going to take serious chums. But if you dedicate even a week to active pairing with your junior what you won't come into is a check-in and finding that they have been frozen for a week trying to debug an unfamiliar library or running into environment problems. Because if they don't know what to look for. They don't know what to ask. This happens to people even as senior engineers. Where we're expected to onboard a new library or supposed to migrate over to an infrastructure and we spent too much time trying to figure out how to shoehorn something that we think is going to work. And someone who has dealt with this architecture before will say, that would never have worked in the thing you're trying to do. Why don't you try this thing instead and that saves you time. That saves the company money if that's a thing you're concerned about. And also, it reduces so much friction and makes it so much easier for juniors to learn.
Excuse me. So, this can even happen, as I said, I do DevRel. So, I do a lot more writing and CFPs than I do actual code now. More me, it's become part of my working process just to have someone in the document after I've written them, and leave it alone and say, can you tear this apart and tell me everything I did wrong. When a junior sees you telling someone, explicitly, how can I make every single sentence of this better and they see this long list of constructive feedback. Why don't you move these words here? Use a different phrasing for this. This phrasing seems a little combative, why don't you change it? And they see you internalize that, make changes, reject changes that you don't agree with. They see a healthy working model.
And they know -- they also know how to accept feedback and gratitude. Being able to do that. And getting into that, let's talk about proactive feedback. This goes in lines with being able to ask questions. You have to establish that part as I mentioned. And for juniors, any task that takes more than 4 hours, that's whether you should maybe check in midday. If they're working off-sync hours from you, tell them at -- when you've worked this amount of time, just toss me a Slack message telling me what your progress is. I'll get back to you when I get back to Slack.
This way, if they're constantly running into roadblocks, you can see the kinds of things that they're actually running into. Is it that they don't know how to attack a problem? That is a thing that is extremely common in juniors and interns and that's why they're there. They're there not to be able to produce, but learn to work.
And if they -- if you pair with them in -- during this process of proactive feedback, I have been running into this wall, you isolate. One of the things that they're having problems with. They watch you attack the problem. They watch you, oh, it's like, let's Google this error message. Oh, we'll copy and paste this code from StackOverflow. It's fine. They'll figure out what your troubleshooting strategy is. You'll find out what their troubleshooting strategy is. And you'll find where there's is causing friction and how they can become more efficient. This is gonna help them in their academic life. This is gonna help them in their professional life later. And the more you establish the difference between professional and academic environments, the easier it's going to be for them to work.
Every single intern I've ever had, every single intern I've worked with or they send me a message on Twitter or Discord or something. One of the things is, they thought they would be caught out for copy and pasted code. Honey, we have all seen StackOverflow. We have. We've seen -- we all Google our problems. We've all copy and pasted code directly from the documentation. That's what it's there for. But because they don't want to use StackOverflow or GitHub because the way their academic process is, is that there will be scans running on code to detect plagiarism. Which to me, I find very confusing, especially when the point is dictate a very specific process a computer can learn.
But once you -- once they see you being able to do that in DevRel space when we're doing -- when we're doing juniors and interns, one of the things we do, we copy directly from pre-existing marketing. That is a strategy that is not a cheat. The strategy is, using consistent messaging, which means copying and pasting words. I've also done this as an engineer. Where we have a component. This was when -- this is life before Git, by the way. This is when you just used a version and you could only do trunk-based things. You could not do single files. You would just copy and paste code from library to library and it would work. Because that's what happened. And that is a way professionals work efficiently is by not reinventing the wheel.
So, now let's talk about onboarding goals. Now, hopefully this should be out of your hands. And it should be self-explanatory. We give them a checklist. They do the checklist. And they get paid. Or they don't get paid, but they get credit. Whatever the contract for this intern is, it happens at HR. And hopefully not from you. But I've missed a paycheck because my information has gone wonky through no fault of my own. And anything bad that can happen to you is twice as bad when it happens to an intern.
So, they will suffer a more direct impact than you skipping one check. And there is more important things -- like getting paid -- than getting your intern's blog post out on time. So, this isn't just payroll, it can also be background checks, employment contract. And, again, these things happen. Maybe it doesn't get submitted properly. Maybe it's being done under a different, but similar name. And that can cause friction in their day-to-day lives and no one wants that. If your intern is part of a formalized intern program, contact the intern program's manager and make sure their affairs are in order. And if they're not, don't let them continue work until it's done. No one wants to work if they're told they're being paid or given credit and that actually doesn't happen. Now, if you're not part of a formal intern program, or you're a junior in your first job, make sure they've contacted HR and ensure all of their onboarding work is complete. And while you're at it, make sure the actual dates and expected hours are what thing it is per their contract. There is a huge different between a 19-hour contract and a 40-contract.
Now, let's talk about program deliverables. This can be part of your formalized intern program or just your onboarding project for your junior. Have a firm date on what they're supposed to do and what their current priority is. Know what their definition of success is such as we want you to submit code with a blog post. The difference between that and what we want to accomplish, like supporting a product launch, are two very different things. You can satisfy the deliverable. That is in-line with their contract. And still be very far off on what your team's priorities are. So, product priorities can also change. How are juniors supposed to weather that? Make sure any of the deliverables that they're expected to have, again, per their employment contract, is still fulfilled. Maybe that means they hang back off the re-prioritization and they just complete the previous amount of work. As a senior, we all know how to deal with that. We keep doing the thing we need to do, and if anyone asks why we haven't shifted priorities, we say, hey, we need to complete the our in-progress tasks before we can spin off. Give your intern that kind of path out in case they ever get caught in that conversation. And if they know that's what the answer is, they're less likely to feel burdened by what's going on.
Or maybe you're actually able to shift priorities with the intern. They're not so far in their project yet and you're able to realign the deliverable to be closer to the team's priority. That is, of course, ideal. But more often it's the other thing that happens.
And now there are team deliverables. That's the thing that -- where priorities shift. Again, make sure their actual contract deliverables are fulfilled first. But things change, especially in uncertain times. In remote culture, juniors cannot tell if this is normal. Or if everyone is just having their own quiet, private little panic attack when the Zoom call is over. Team leads obviously are responsible for navigating the team through such changes. However, they also need to communicate what to do when these changes happen. And how not just individual team members, but very specifically juniors and interns are specifically impacted. Do their tickets change? Do they foresee per usual because now they're the only contributors on their project? If they are the only contributors, how do they get feedback on something working on that's different than the team priorities. Again, seniors, we just keep chugging until our work is done. But also, we make sure that the juniors understand, it's like, if you feel you're not in alignment, so long as you get your work done, it's okay.
And finally, the check-ins and updates. If your team is pretty full, don't make the intern give an update. It's a lot of progressive issue to be talking directly into a staff meeting of 25 people. However, if your team is on the small side, let them share what they're learning. We all get a nice lift about what juniors learn and what their perspective are. And they should also meet one on one outside of these meetings several times in a week. I'm personally fine meeting my lead once a week, maybe, if he wants. But that's because I know what work I need to do, and we all know how long it's gonna take me to do it. For new people, it's very easy to be left on an island. And if they don't know the way to call out of this island, it just stresses them out. So, once a week with the team lead. Once a week with their intern mentor or their junior mentor, whichever. And once with a technical resource that they can bounce questions off. The technical resource, you can ask actually once every 2 or 3 weeks.
And this is just to make sure that they are learning things outside of the assignments you give them. Otherwise, they are only going to learn those very specific things. And if they -- this way, also, if you have people talking to these juniors outside of their team, they're able to talk -- understand how engineering works both as a social and a business system.
Okay. Communication. Communication, I'm not sure if you've gotten on the theme with this, extremely important. Especially when coming to new people. It's what makes or breaks anyone's first job experience. The quick lesson for this is to make sure your junior feels comfortable asking questions and contributing to conversations without double checking their own judgments every 5 seconds. Easier said than done. Again, set boundaries. This is how you reach out. And the type of commercial communication you feel comfortable with. I prefer a casual conversation with immediate feedback. If you have issues with what I'm doing, let's talk it out or Slack it out before turning it into a committee meeting. But also, don't message me after hours and expect an immediate response. I have a 36-hour SLA on any communication, and frankly, I think that's generous.
And this is all depending on what you're comfortable with and what your priorities are. As for junior and interns, I say out loud that they should feel free to ask questions at any time. The rest of us are adults and we know when to answer non-critical questions. But also, they have to have the understanding that when they're not answered the next day, it's not because we didn't like their question or we didn't think it was worth asking, it's because it's outside of our work cycle. We'll get back to them immediately and set up time. And understand how meetings work. Unless you have prior experience with a topic, wait until a topic is completed before answering questions. And don't wait and ask people if they're coming to a meeting unless you're planning to reschedule. We all have our own calendar and priorities we have to look after. Can't always answer that.
And finally, make sure that they understand that setting boundaries isn't criticism. We don't need an apology. Just understand that your message will be answered in an appropriate time. Respect our time the way we respect your time. Also, introduce them around. Very rarely does a team work alone. If you're working with clients or other teams, such as marketing or DevOps or security, make sure to introduce them to someone who is open to answering questions and will also likely be answering their tickets. Establish a cooperative relationship and support. If you're there during that introduction, they know how to deal with that conversation and they see use at establishing social expectations on how to deal with those teams and people. Have them give their name and what to do, and discuss what they're working for. Do that for every meeting. If you're including them on a project, make sure you're there to show them what a smooth meeting will look like. If it doesn't go smoothly, show them how to get things back on track and resolve conflict. No one at that meeting should be running things solo. And it should also give some protection against personality conflict until your juniors are ready to handle those things on their own. And finally, tickets and PRs.
all that tracking stuff. I hope we all have access, but I have been in jobs for months when I didn't realize I wasn't part of an ACL they should have been. If you don't know, you don't know. No matter how long you have been around. And these things change from organization to organization, even team to team. If you have an organization like this, a have someone watch them do the tickets to make sure the checklist is followed. If you're on cross functional team, you will do this several times for each team's different Jira format.
And finally, let's talk about the career and culture. Now that's all said and done, hopefully we have a solid working environment. But we all know that work isn't just work or we wouldn't be here on a weekend. There is a lot of practices that are established in the first couple years that set up how you deal with people outside of your immediate work place and what your future in tech looks like. First of all, it's the career ladder. This isn't a hypothetical series of steps you move along in your career. It's a very specific set of titles and expectations that are directly related to what your duties and pay are. If you start in a smaller startup or a consultancy, you have a wider breadth and it's wider experience than in a large business. However, the ladder will let you know if you have done more work than is expected and how to be promoted very often there's a requirement for years of experience and requirements. These can be products pushed, pipelines built or performance metrics for each. It's a good way to lay out what you want the next steps in your career to look like can and what the skills should be.
The next is networking, the people kind. If we're here, we know how much is to be gained by engaging other people in our industry. We learn about new use cases and products and personalities. And resume scoring systems are throwing applications into black holes. And very often a referral from that network is going to set you apart in the crowd. I'm to the saying go to a party with your resume in hand going from person to person. But if you establish yourself with an interest in a technology or diversity group, you can find yourself opening -- with an opening with someone who can set your resume aside. It's not enough to get you the job, but it will definitely get you a push when you need to secure an interview.
And now, events. There are very hard to navigate early in your career. There's a lot of demos and swag and it's really easy to get swept up. And because of that, also real easy to get FOMO when you don't get to go to a lot of conferences as they are quite expensive. A lot of the biggest conferences have a virtual component to it which will be a fraction of the price to a full conference. And announcements from the largest cloud providers will also be posted on YouTube for free. So, if you go to these events, prioritize meeting people. Find talks you enjoy. And talk to the other people who attended. Maybe even reach out to the speaker themselves.
But also, remember that it's for work. Not a comic book convention. I say that as a full-time nerd. But we have fun. But being in trouble and disruptive is going to get you a reputation. And trust me, that reputation will follow you.
No one will remember the person who sat on the wall quietly the entire time, but they will remember the person who got so drunk at an after party they had to be escorted out. And finally, prepare their exit. Not when they start, obviously. But remember, this cycle for a journey is 9 to 18 months in tech because there's always new stuff to learn and better paychecks to cut at different companies. You should endeavor to keep them for longer. But also set them up so that they can grow outside of their company. We all know people who wanted to return to jobs in companies they liked because they were treated to well. And having a good review and a good production from an intern one season will likely get you a new intern and possibly a full-time hire later.
Finally, what should they know when they leave? Again, set your boundaries. I will say that again and again until I see people start doing it. Make sure your juniors set boundaries for when it comes to working hours. How to communicate, when to communicate and what that should be working on. They should feel comfortable enough to identify and say when they feel uncomfortable and should set bound arise. And collaborate. Learn to live in documents with other people, even if the thing is littered with suggestions. And consider them without taking offense. Maybe there's better structure to what you want to say or a more recent study or product that would better fit the requirement.
Also, if you spend a lot of time in documents or tickets and you haven't made too much progress, they need to identify when and who to ask for help. Maybe it's not always a technical resource you need, or maybe the documentation you were given was out of date. There's always reasons to collaborate. And the reason is never gonna be, I just don't get it.
And finally, they need to learn how to work. This is about getting feedback, but knowing the structure of projects and deliverables. Know what the priorities are, and if they do, or do not apply to you. And know what you need to do right now. Know how your tracking systems work and what your definitions of success are. And know what need to be asked about right now and what can wait until your next one-on-one check-in.
And one of the best things you can do for juniors and interns is let them know they're not alone. They don't need to reinvent the wheel for most solutions, but they also need to know how to use that wheel and where it's applicable. I personally love helping people new to the industry trying to break in. Tweet questions @nerdypaws or at Amy-codes.com. I probably sped through that last part.