Remote Non-Senior Developers, Part 1: What Your Company Should Look For

When I tell developers I meet at conferences or elsewhere that I transitioned from a career in nonprofit management to becoming a software developer I usually get smiles. And then, when I add that since becoming a Dev I've only worked remotely, the smile changes to skepticism. I understand hat skepticism. People have views of what will help a junior Dev be successful, some companies have had bad experiences with non-senior remote developers, and there are lots more stories out there. But as remote work and distributed teams become more prevalent in the field, companies shouldn't feel like they can't hire, train, grow, and mentor less experienced developers as a result. Last month at the United Silver Spring Ruby meet up, I spoke about being a non-senior remote developer (note: non-senior does not explicitly mean junior although I was a remote junior developer). Folks of all experience levels were interested to hear what I had to say because many can't envision what a non-senior remote teammate might look like. Here's s little bit about my experience, what I think makes a successful remote non-senior Dev. Part 1 will cover what a company should look for when considering hiring someone and then part 2 (coming out next week) will go over what a less experienced developer should think critically about before deciding to go remote. 

I won’t lie to you. It does take a special type of person to be a remote worker regardless of their level. This is why some companies decide not to have remote employees at all. And it is a little riskier to hire a remote worker with less experience because do can have a higher risk of not being successful if they are not great (I say great because they do need to be better than good) at the things that make remote workers of any level good remote workers. Here are some characteristics you want to look for when hiring for a remote non-senior developer. 

1. Someone who takes initiative. There are going to be bumps and issues and as a non-senior dev. In order for the employee to learn and grow as much as they possibly can, they’re going to need to make some decisions, put improvements in place, and get the rest of the team on board with what they need. Make sure that as a company, you look for someone who has done this in the past or has the potential to do this.


2. Good communication skills. This is necessary for any developer but especially when remote. How can they articulate their thoughts, the research they've done, a problem they're facing, etc. 


3. Learn about their past. Are they a new professional or just new to development? When I became a developer I had about 7 years of prior professional experience and had already been working from home for 2 years in different industries successfully. I might not be a senior developer technically, but I’ve got all the other skills necessary to be successful.


4. Make sure the person understands what remote work is all about. Ask them about the best and worst parts of working remotely. I don't like working remotely because I can work in my pjs (which I don't do, for the record). I like it because I have a schedule, more work time without a commute, and a quiet distraction-free workspace. I also have opinions about the parts of working remotely I don't like. I’m aware of all the good parts and bad parts of remote work and I know what i’m getting into when I accept a remote position. You want to ensure you’re hiring someone who also understands these aspects or has at least thought through them.


5. And maybe most importantly, someone who isn't afraid to say to a slack channel that they are stuck, frustrated, or need help. Without this personality trait, the individual won't be successful because asking questions is probably the most important skill a developer can have.

I find the best way to learn about all of the characteristics above is to ask behavioral interview questions. Instead of the interview where you decide if you'd like to chill with the candidate, ask about scenarios. For example, tell me about when you were stuck on a problem, what did you do? What if no one was available to help you? What was a time you had an issue with a teammate, how did you address it and how was it solved (if at all)? 

Now finding the right candidate is half the battle, but you also want to make sure they’re set up for success. A person isn't an island. They can only exist and thrive if they're put in an atmosphere to do so. Companies sometimes feel they don't have enough resources or structures in place to support a non-senior person but if you have the right candidate, you actually just need a few small things to ensure success.

1. A good manager who has had some experience/training. This person will be vital for support and working through issues that may come up on the team. They should be an ally and be able to recognize when issues are actually opportunities to help the team as a whole grow and learn more about things like diversity, empathy, mentorship and more. 


2. A kind, caring team. It is easy as a non-senior Dev to be scared of asking questions but if the team they are put on is supportive, thoughtful, positive, and constructive it will really go a long way in creating an environment with lots of psychological safety where it is easy to learn. 


3. A system of regular check-ins. It's great if you have a good manager but that manager (or even a tech lead) need to be regularly checking in with this person, especially at the beginning. I think 1-1s are a vital part of a healthy team culture regardless of experience level or if folks are remote, but it’s even more important when you don’t see each other every day in person.


4. A partially remote team. Even if your current team of remotes are only senior, having a partially remote team means you understand some of the baseline difficulties of remote work regardless of level. It also hopefully means you have some processes in place to allow for easy, async communication and remote pairing tools that are widely used and understood. I'm not saying it won't work if your first remote hire is non-senior but it's definitely going to be a steeper mountain to climb. 

That's it. Really not as involved as you thought it'd be, is it?

Here are the original slides from the talk I gave: https://speakerdeck.com/asheren/remote-non-senior-developers

Stay tuned for Part 2 next week.

And if you’re interested in hiring a remote software developer or want to speak more about the points made here, get in touch!

Mentorship: Wants vs. Needs

Mentors generally have the best of intentions. They want to help, they want to teach, they want to give back to the community oftentimes because they received assistance and mentorship to reach the level they are at. But sometimes, what a mentee needs doesn’t quite match up with what a mentor wants to give. In conversations about mentorship, I feel this piece isn’t frequently addressed. There are plenty of conversations about mentorship and plenty of common topics that are discussed. I always hear about how to find a mentor or mentee, how to have a successful relationship, and i’ve written/spoken about these subjects in the past here and here.

One of the most important aspects to consider in both personal and professional mentorship is do the learning styles of the two people match up? I have different mentors for different subjects. I have some people I talk to about being a woman in tech or about work/life balance, etc. and I have other mentors that meet with me more frequently to cover technical skills. For me, I consider these technical mentors to be both personal people I meet with and more experienced developers I work with every day. Thinking about learning styles is important for both. People learn and teach differently. When establishing a relationship with a personal mentor, make sure you’re working with someone who understands how you think and make sure you understand how they explain things or walk through code with you.

Companies with a focus on team health and personal growth have good intentions and look for senior developers that have a vested interest in mentoring in order to grow their less experienced developers. Less experienced developers look for teams and team members they can learn from. When looking for opportunities, talking to senior developers about how they mentor is incredibly important but even better is when you can pair or ask a technical question to see how they explain a concept and whether they use language and an approach you can understand. One of the most important questions to ask when pairing or interviewing at a company is “can you repeat that?” or “can you explain that in a different way?” Those questions reveal mountains of information about how they might interact with an individual on a regular basis, and how much one can expect to learn from a person or team while working there.

Additionally, for companies who feel mentorship is an important team value, consider including your least experienced developers in interviews, and not just in the culture-fit interview portion. Involve them in pairing session or in one of the technical interviews. It will show candidates that you are serious about mentorship and the growth of the whole team, and will ensure that you hire someone that your less experienced developers learn from effectively. While this likely isn’t the case for everything related to hiring, when it comes to mentorship on a team, It’s not about what the senior developer or company wants, it’s about what the less experienced developers need.

A learn/teach mismatch can be extremely frustrating and emotionally taxing. A mentor might get frustrated explaining the same concept over and over again, while a mentee (especially one who’s new to the field) might think they don’t belong in tech or just can’t understand. This same experience can be true in the context of work. A more senior developer might think the members of their team aren’t growing or aren’t learning. They may get frustrated if they’re re-explaining concepts. Less experienced developers feel stunted in their growth, feel bad about asking the same question more than once, and feel themselves like they aren’t meeting their potential. The broad implications of this are, at best, general dissatisfaction and, at worst, a lack of desire to play the role of either mentor or mentee in the future.

Chrome Extensions and a Return to Meetups!

Well, I missed my "blog post a month" by a week or so, but I finally got an idea for a blog post! A few weeks ago, I finally made it back to Arlington Ruby (as a part of me trying VERY hard to start going back to meetups and getting re-acquainted with the community I love so much) and learned about making chrome extension from Casey Watts. Nope, it has nothing to do with Ruby but it was really interesting to learn about. There were two components of this presentation that I enjoyed. The first was the actual technical content of learning how to do a chrome extension and the second was the presenter's teaching methodology.

Let's start with the technical content. Did you know that making chrome extensions is super easy?! In about 30 minutes, we already created like 3 chrome extensions. There are 2 things we learned... bookmarklets and actual chrome extensions. According to the presentation, a bookmarklet is "a bookmark that runs javascript on the current page instead of taking you to a new page" (like a regular bookmark would).The basic premise of both bookmarks and chrome extensions is altering the "location" field on the "add page" form in order to execute the javascript.

An extension is only slightly more complicated than a bookmarklet... at least the examples we did during the meetup, but i'm sure that this is where it can get really complex with more sophisticated ideas. An extension has a manifest.json file which outlines the name, version, description, javascript files (or html or css) you want to pull in, and where you want the extension to work.

Finally, we spent a little bit of time talking about examples of chrome extensions people might want to build, how to distribute and deploy a chrome extension, and some security things to keep in mind when either downloading or deploying an extension.

As I mentioned earlier, I still assume that making a more complex extension is more difficult. It seems like it could potentially involve a significant amount of code and because of how the code is pulled into a chrome extension, could be complicated to mentally keep it all straight and organized. All in all though, I had no idea that building an extension was so straightforward and I can't wait to think more critically about extensions I use or actions that might make sense to make an extension for.

The second part of this presentation that I liked was how it was taught! It is really difficult to teach something technical without really knowing the group of people you are teaching. It is even more difficult to do this when you know that there will be a pretty diverse level of skills in attendance as well. Casey did a great job! He started by framing what we were doing and what the end goal of the "lesson" was. He then had us pair up, which enabled everyone to work with someone on the parts of lesson that were self-guided. It was great to bounce ideas off of someone else and, we all know that often at technical meetups it can be difficult to meet other people. The guide that he walked us through was really clear and easy to understand. You could move through it faster if you were more experienced or slower if you were less so. It was a lesson but felt very laid back, informal, and fun. Finally, we worked independently in small chunks of time but then came together in between those times. When we came together as a group, Casey made sure we were all paying attention and as a result I think there was much more group participation than if he had just hoped that everyone was engaged instead of really enforcing that they do so. I feel like everyone left having met/spoken to someone AND actually having learned a bit more about chrome extensions.