 conference, I'm sure everyone's pretty tired, but hopefully you'll enjoy this. And yeah, last session, last talk session, so let's close it out strong. So today we're going to talk about something that lots of people care really deeply about. A topic that spurs conversation, arguments, agreements, jokes, and so many other emotions. We are going to talk about the Justice League. The Justice League started in 1960, although there have been lots of different formations and iterations throughout the years, including Justice League of America, Justice League International, and a few different formations of the actual Justice League team. In the last 55 years, there have been over 150 members. That's a lot of Justice League members. Some, like Superman and Wonder Woman, were born with their powers and have abilities they've been able to shape and make better over time. Others like Batman and the Green Arrow developed their abilities, and even others like Green Lantern and the Flash were gifted theirs and then mentored to success as a part of their superhero training. And that's not the only difference between the members. The age range of just the core members of the Justice League ranges from early 20s to hundreds, maybe even thousands of years old. I think we can all agree the Justice League has had a pretty successful run. They beat hundreds of enemies, foiled dozens of plots against them, and saved the world hundreds of times. And they did this all by working together. Even Aquaman was able to contribute sometimes. Not only did they work together, but they worked remotely. That's right. The Justice League is a remote team of colleagues who each work primarily in their own location and when necessary, come together to headquarters for trainings, gatherings, team bonding, etc. Not only is the Justice League a distributed team, they've also faced other HR challenges over their 55 years of existence. They've remotely onboarded dozens of people throughout the last five decades. And not all of them were senior superheroes. They all come from different backgrounds, have different abilities, and were at different experience levels when they became a part of the team. So that's actually what we're going to talk about today. Remote opportunities, hiring remotes, and deciding if you want to be remote or not as a non-senior developer. Did you know that the youngest person inducted into the Justice League was Cyborg? He was only in his early 20s. He started as a Teen Titan, which you could say was his apprenticeship, and then became a part of the Justice League. And while some people think that Cyborg was young for the team, you can also think about the more experienced folks. It's an assumption that senior developers make better remote hires, but that's not always the case. Sometimes even the most experienced folks, people who are senior that you think will be great additions to the team, can be cowboy coders, and ultimately might decide to leave. Sort of like Batman. We already know that hiring is difficult. But if you're ruling out non-senior developers simply because they're not senior, then you're missing out. In today's talk, we're going to cover a few topics. We'll talk first about the characteristics to look for when you hire someone new, and then what you as a company should have set up so that remotes can be successful, especially if they're not senior yet. We'll then talk about developers who want to be remote, taking a hard look at what a person needs to be successful in that situation, and talking through the right questions to ask yourself if you're thinking about trying to join a remote team. So why am I talking about this? Well, I was a partially remote senior employee in my last career, and then a fully remote one since becoming a developer a few years ago. As a non-profit executive, I expanded our team and created the first distributed team the organization had ever seen, which often involved me working from home to set an example and be able to empathize with the remote employees. When I became a developer, I started on a remote contract, traveling to the office two days a week, and then worked at a company where the engineering team was partially remote. I'm now lucky enough to work at Collective Idea, which is an amazing software consultancy, possibly with some upcoming availability, and a handful of remote employees. So being able to work remote without being a senior developer is definitely a topic that's really important to me. So let's dive in. A recent study from Sherp Herald mentioned that each year, U.S. employers lose $1.8 trillion in lost productivity. Some of the reasons for this lost productivity include $90 billion to excessive commuting and $33 billion for balancing work with caregiving for older relatives. This is, I just picked out these two out of a long list of different reasons. A 2014 study said that 82% of remote workers reported lower stress levels. And remote work is becoming a more regular option for a variety of folks. A McCrindle research study said that 55% of respondents reported being more productive when working from home. And a whopping 80% said that they would stay with their employer longer if they allowed remote or telework options. A study from Global Workplace Analytics found that regular telecommuting has grown by almost 80% between 2005 and 2012. A Melbourne University study found that people who worked from home started their workday earlier, worked up to three hours longer, sometimes in lieu of having to commute, were more productive, felt more energized, had less stress and less distractions. And finally, a study by the Harvard Business Review noted that some companies saw worker productivity increase by over 13% after permitting remote work. So as we get started, I also wanna clarify and define who I'm talking about when I say non-senior. Because remember that non-senior might not mean junior, and might not mean new professional. It could be a junior, it could be somebody with a year or two of experience who's mid or sort of still at a junior level. It could be a mid-level developer. It could be somebody with decades of professional experience who's just new to software. And remember, every company defines experience level differently. So what's junior at one company is sometimes senior at another. A lot of companies are nervous about hiring remote developers, especially if they're not senior. I've seen dozens of job descriptions that say a company is remote friendly. But once you have that first chat with them, if you even get that far, you're told that that option is really only for senior developers. As a company, you might be open to the idea of remote workers. So how many people here have a remote or partially remote team? Now, raise your hands if you hire remote developers that are not senior. Fewer. And keep your hands up if you hire remote junior developers. Yeah, I noticed that number of hands very much decreasing. But how many people here think that they would want to hire non-senior remote developers, but you're just nervous about doing it? It's a struggle, I get it, right? Remote junior or mid-level developers can be gamble, like taking a stance if you're partial to Marvel or DC. These companies fear that the folks they hire might sit in their home office stuck on a problem, might not be effective communicators, or might simply just not be working. In a brief and completely unscientific survey posed to a Slack group comprised primarily of engineering management folks, many mentioned they were wary of hiring remote non-senior engineers. Unless the team was entirely distributed and even then there was still some caution mentioned, the three concerns mentioned before were widely noted. Other companies have had bad experiences and are reluctant to try again. Because remote work is not for everyone, right? And non-senior remote work definitely requires certain critical characteristics. So just like the Justice League looks to make sure they're finding the right people that will add to their team, you need to do the same as well. So here are the key characteristics to look for. Look for someone who takes initiative. You want someone with drive and motivation who can identify when there are issues and when they have a problem and will work to solve it. In an interview, you could ask a question like, tell me about a time you recognized a problem that needed to be solved. How did you realize a problem existed? Did you do anything about it? If so, what? Next, find someone who asks questions and not just technical ones. Every hire adds a new perspective to your team and is able to look at projects, stories, and tasks from a different point of view. You want someone who'll be comfortable voicing that even if they aren't in the room. So hire someone who asks questions. You could literally ask someone, tell me about how you feel about asking questions. You could also ask something like, when was a time you needed to ask questions where you were a little hesitant to do so? And how did you overcome that? And look for people who communicate when they're blocked. Cuz technical questions are also really important. You can't see this hire. You won't know if they look frustrated, if they're struggling, or if they're actually making progress just slowly. And you won't wanna break their flow or yours by constantly interrupting to make sure they don't have any questions. This is one of the biggest concerns I hear from engineering teams about hiring non-senior remote folks. So in this case, you could ask a question like, when was a time you were really challenged by a technical problem you needed to solve? How did you approach it? Did you ask for help? Tell me about that. And of course, overall you want someone who communicates in general, right? Most companies are most concerned about this related to remote hiring, regardless of experience level. Will someone communicate when they have questions, when they have issues, when things are good, or especially when things are bad? So ask a candidate about some specific scenarios. For this characteristic, I actually recommend a few related questions. At least one that focuses on a negative situation. Something like, tell me about a time when lack of communication led to an issue. What happened? Was it resolved? If so, how? One that looks at their personal style. How do you like to communicate as a remote member of the team? How do you ensure that you're communicating effectively? And maybe one that looks at a positive situation. What do you think is a really effective way to communicate and how have you utilized this in the past? Also, be sure to look at the entire person and their evolution. So what I mean by that is, don't just characterize folks within their technical experience level, but think about their life experience as well. Are they switching careers or completely new to being a professional? This makes a huge difference. I'm a less experienced developer, but I've been a professional for over a decade and half of that working remotely. If they're switching careers, they might have significant prior experience as a professional, and might have a greater ability to demonstrate excellent communication or entrepreneurial skills. Continuing to look at the candidate as a whole person, think about if they've worked remotely before. If so, you should be able to ask them a question like, what are the best and worst parts about working remotely? This helps you determine their effectiveness as a remote employee. And if somebody hasn't worked remotely before, you could ask them, you could assess this by asking something like, what do you think the best and worst parts about working remotely will be? Someone who talks about loving remote work because they can chill in their pajamas all day might be a little bit of a concern. Finally, look for someone who's interested and invested in continuing to learn and can be self-directed. So in my last job hunch, I heard over and over again that companies just wanted somebody who could learn effectively. Which was actually pretty frustrating because that's a really vague quality. I also noticed that rarely did a company actually ask me about my previous experience learning a new skill. So a great question here would be something like, tell me about a time you needed to learn a new skill, technical or not. How did you decide you needed to learn that particular skill? And what did you do to learn? Okay, so in summary, that's you wanna find someone who takes initiative, asks questions, communicates when blocked, communicates in general, understands being a professional, is thoughtful about remote work and wants to keep learning. Thinking about these candidate characteristics, you should also think about your interview process to make sure it really reflects the type of person you're looking for. Now, this could be a whole different talk topic, but if you're concerned that a non-senior remote person isn't going to communicate, a take home code challenge is not going to help you assess that. In each of the characteristics I mentioned, I also suggested a question you could ask. These behavioral and situational questions are really important. They're also hard questions to answer, and probably questions that candidates haven't been asked in the past. So you'll get a really good sense of how they communicate because they won't have a rehearsed answer. Going through the job hunt process, I must have been asked, tell me about yourself, dozens of times, like dozens and dozens of times. By the middle of the process, I could literally tell you about myself, while not even paying attention to the actual words that were coming out of my mouth. Skim my resume, ask me to tell you something interesting about myself, and then please move on to asking better interview questions. Now, the other thing that's often worrisome from an employer's perspective when thinking about making a remote hire is knowing what they need to provide. So how many people here feel like they're not equipped to bring non-senior remote folks onto their team? Not that many, that's good. That's awesome. I've got news for you. If you find someone with the characteristics that I mentioned, what you actually need to provide is not as daunting as you think. Bringing on a remote non-senior developer is the same as bringing on a non-remote one. First, you need a good manager. Sometimes I think this is actually one of the toughest things to provide in tech or in most industries, because good managers can be really difficult to find and even harder to keep. But it makes a big difference in advancing the overall career trajectory of a newer developer. Next, you need a kind, caring team. Don't underestimate the power of positive reinforcement, constructive code reviews, and positive pairing experiences. Also, don't underestimate the detrimental effect an emotionally unintelligent team can be to an individual's confidence and ability to execute and grow quickly. Once you've got those two things out of the way, the other two are really easy. Check in periodically to ensure that the person isn't forgotten about and have a partially remote team. Don't hire a non-senior developer if it's your first remote hire because it will probably suck for everyone. Now, how many people here think they'd like to move into a remote role or love the remote role they currently have? According to a 2015 Gallup poll, 37% of the U.S. labor force works remotely, and that number is only rising. There are a lot of important questions that you need to ask yourself, though, before doing this. There are developers at all experience levels who think that working remotely is truly living the dream. Sometimes it seems like the case, right, working from places like the beach, amazing foreign countries, and other fun places. This is me working from the Renwick Art Gallery, which is one of the perks of working from D.C. is that I can work from any of the Smithsonian museums for free. I really have pretty decent internet, which I was pleasantly surprised about. So for me, the situation often is ideal, but I thought long and hard about my choices and what the pros and cons of working remotely have been, as have others. I recently posed a question on Twitter asking people to share their most favorite and least favorite aspects of working remotely. And yes, I know that this isn't a Marvel or D.C. sledge. For most favorite, I got answers like no commute, ability to live anywhere, flexibility, family involvement, peace and quiet, dress code, and having a comfortable office setting. But for the least favorite things, there were also thoughtful answers, like difficult communication, limited social opportunities, missing out on what's going on in the office, and loneliness. Loneliness or some form of isolation or lack of social interaction was mentioned a lot, like I think by almost everyone who answered the question. So remote work isn't for everyone, and there are hard questions that you need to ask yourself and think critically about before deciding to go remote. First, do you ask questions? It's really easy when you're remote to become afraid of asking. You can't see what people are doing. Sometimes you don't know who to direct your question to, and posting a question in a large Slack channel can be pretty scary. I mean, what if no one answers? How many times do you repost your question? You need to ask a ton of questions and really force yourself to do so. Whether it's in Slack channels, messages, or in meetings, when I started out, I actually set a goal of asking 100 questions a week. So this number was completely arbitrary, but the point was that it forced me to ask questions in order to accomplish my goal. And once I started doing so, it really got me over the hump of being nervous about doing it. I didn't really track it. I just forced myself to ask 100 questions a week. That sounds like a really big number, so I'm just going to keep asking questions. How do you guys get feedback about how long to be stuck on things for? It's hard to assess at a new company how long you should be working on a problem before asking for help, and this changes company to company. This is even more difficult when you can't see other people to know who's around, what they're working on, or how often other folks at your level are pairing or asking for help. Keep regular notes about various tasks and how long it took you to complete different parts of the task, and then review that with your team or manager to decide what things you should be spending more time on and what things you should ask for help with sooner rather than later. Next, set aside time for pairing. I found it really helpful, again, when I was starting out, to have regularly scheduled pairing times with people in our calendars. Sometimes we use this time to complete a few tasks, like that I was 90% done with and then ship. Other times it was used to start something brand new, something often challenging that I knew I would need to pair on in order to be able to create a plan of action and move forward effectively. Setting regularly scheduled times to pair with various teammates helped ensure that I was getting the help that I needed without being as afraid of bothering people. You also want to talk about what's not working and be prepared to propose solutions. There are going to be bumps in the road, and if you don't talk about them, identify what they are, and figure out things to try to improve these issues, your experience as an employee will likely get worse and worse as time goes on. You also want to be proactive, not reactive, so come up with solutions to try. Having remote developers at different experience levels is still fairly new for most companies, so offer a fix, offer something to try, somewhere to start that you can sort of iterate on later. Next, find a way to fill the gap of not being in an office. This is probably one of the biggest downsides to working remotely as a non-senior. There's a lot of stuff that you don't get when you choose to not work in an office. You don't get the chatter, the random information, the overhearing terms, and being a part of random discussions that occur about different technical approaches. You don't want to miss out on this from both a social point of view as well as a learning one, so fill the gap. Co-work, go to user groups, make programmer friends, et cetera. I try to co-work once or twice a week. There's actually a pretty decent-sized group of folks in the DC metro area that either work remotely or sometimes work remotely. So for example, we often co-work on days where there's a meetup that evening. Finally, think about how you work. Can you be self-directed all day, every day? If you're stuck, can you figure out things to learn or do until someone is available to help you? You have to be brutally honest with yourself on this one because if you're going to get distracted or be afraid of asking questions and putting yourself out there on Slack, for example, or company chat, then it's probably not going to work. And beyond questions related to your personality, there are some real technical considerations. Have you ever tried to do a whole day of software development with bad internet? Awful. You need great internet to be a great remote teammate. You'll be pairing remotely and having lots of video meetings which often takes lots of bandwidth and good connections. And if you're going to want to move around a bit, co-work or be able to have options of where to work from, invest in a good pair of headphones with a mic that allows you to hear folks better and block out some of the background noise wherever you are. Okay, so in summary, you need to ask questions, get feedback, schedule pairing time, talk about what's not working and suggest solutions, fill the gap of not being in an office, be self-directed, have good internet, and get some headphones. Just like companies should make their interview process fit who they're looking for in a new employee, you should also make sure to decide what you want to see in a remote job. Ending up at the wrong company as a non-senior developer can be really isolating. And in the wrong atmosphere, detrimental to your confidence and potential for growth. So you want to make sure that you find the right spot as well. Consider your must-haves and your nice-to-haves. Write them down so you don't lose sight of them in that crazy job hunt process. And think about what questions to ask to potential employers. Some of my favorites include what is the best part about working for the company and what do you want to most improve? How often do you bring the team together in person and what do these in-person gatherings look like? How do you support remote folks to make sure they're included and ask about onboarding? How does it work? How do people get ramped up at any level? What do the first few weeks look like? And to your manager, what do you think are the most important characteristics of being a manager? You can also ask them behavioral interview questions. For example, tell me about a time when a remote hire didn't work out. Why do you think this was the case? And what did you change to prevent it from happening again? Or, tell me about a time you've mentored, paired or learned with a remote less experienced developer than yourself. What went well and what was challenging? If I'm interested in a company but I'm not totally sure about them, I'll often throw in some of those behavioral questions to see if they have some real-life examples I can listen to. And just like when employers ask candidates unexpected questions, most interviews haven't really been asked the questions I just mentioned. So you'll get better answers because they often aren't rehearsed and require the interviewer to think on their feet a little bit. We've covered a lot of ground today. Lots of companies are afraid of hiring non-senior developers. Companies need to look for the right set of characteristics, and developers really have to evaluate themselves and their working styles to see if they'll be bold enough, brave enough, and outspoken enough to be a remote developer. We don't have a boom tube or superpowers to help our teams communicate. And it's not as easy for us to fly or use our invisible jet to get together. We do have lots of other tools at our disposal. We can still have successful remote teams with diverse levels of experience. So the next time you come across a great individual who's got everything you want but is just shy of what you hope for technically, don't just ignore them. Think about what you could be missing. A new perspective, a great communicator, a person who could teach your team in other ways while leveling up. And if you see an opening for a remote developer position that catches your eye, think about yourself and your personality to assess the potential for success. Either as an employer or an employee, a great opportunity could be presenting itself. Just make sure to ask the right questions. And remember, even the Justice League works remotely. Thank you. And I have some time for questions. Times and distribution and policy. Yeah, so it's been different at a couple of companies where I'm at currently. It's just east coast through central, I believe. The last company that I was at, it was west coast through Amsterdam. I don't know what time zone they're in. So different companies have different rules. You need to figure out what works well for your companies. I often think that if a company has a really small... I could see companies not wanting a big 12-hour difference, let's say, but I think that if companies have issues with a three-hour difference and they're remote-friendly, that's sort of a red flag for me because it probably means that a lot of the communication doesn't happen asynchronously and maybe some of those, a lot of those kinks aren't worked out. So that depends on, it's different at every company. My... Currently, like my personal standard that seems to work with my team is I spend 30 minutes on something easy, 45 minutes on something that is like a challenge or stretch thing for me. It depends on every place. At my last company, for easy things, it was maybe five minutes, but I also worked with someone who, when I asked them a question, I needed to ask the question in a sense of like, this is how I've been working on this. These are the things that I've tried. These are the Stack Overflow articles I've read. This is what I've solved. This is where I'm stuck. He sort of wanted all of that laid out to see, right, to see like, more time there. So it's really a matter of looking at tasks, looking at tasks and really talking and having open communication with your team and with your manager and your tech lead about what they want to see from you. Because some companies do want to see you struggle a little longer, some companies are like, it's not worth you spending more than 10 minutes on this, just ask quickly. But it very much depends on the company. All right, well, I'm around. There's not that much of the conference left. But I'll hang out up here for a little bit. And yeah, I'm around this afternoon. Thank you.