Opportunity as a Service

For the past 6 months I have been mentoring Nathan, an intern on my team from the Year Up program. Nathan joined us in September from the Year Up program out of Bellevue College.

The Year Up program is a job training program that teaches technical and professional skills to young, motivated individuals. They seek to close the opportunity gap by providing these skills to ensure success regardless of their background.

At Microsoft I work in the Enterprise 360 organization which runs the entire Microsoft enterprise network. Our team builds React and ASP.NET applications to create self-service experiences for our community of network engineers and Microsoft employees at large.

I'm very grateful my manager gave me this opportunity to mentor Nathan. It's helped me become better at translating coding terms into more approachable language. It's incredibly rewarding to be the catalyst for someone who's very hungry to learn, and watching them grow throughout the process.

I want to share a few stories and things I've learned about mentoring over the last six months. If you're a manager or leader in your organization, I highly recommend into looking into these kinds of programs. It is a great way to hire amazing talent and further develop the mentorship skills of the people on your team.

For Loops and Four Loops

Perhaps one of my favorite stories to tell from this experience happened within the first days of Nathan joining our team.

I wanted to see where Nathan's technical skills were, so I put some code on a whiteboard:

x = [1, 2, 3, 4, 5]

for i in x:
  print(i)

He took a wild guess and said: 4. When I asked him he he proclaimed: "you said it was a four loop?". Clearly there was a skill gap that we needed to close.

Aggressive Learning Curves

Starting any development job, there's always going to be a learning curve. Even with years of experience, you still have to learn how things are done on the team you're joining.

For those just getting started, joining engineering teams is really intimidating. In academic settings, there's an expectation to push out code for assignments as soon as possible. Starting a job, it seems like if you're not shipping you're not performing.

I always make sure to set the expectations that early on I expect 90% of your time should be spent learning, and you can expect 10% of your time to go to delivery.

Start Small, Go Slow

My first change at SAP Concur was a string fix, and it took several hours from start to finish. I needed to change "adminstrator" to "administrator". It probably sounds silly that it took hours but if you look at the steps involved:

1. Get access to the repositories
2. Clone the repository
3. Find the misspelled word
4. Make the change
5. Push the change
6. Get reviewers to review and approve the change
7. Merge the change

Making that one change exposed me to a lot of the processes I'd be interacting with over the next year or so. It was a small text change, but there was so much that went into it.

When you're on-boarding someone, give them a small byte-sized task that will help them go through the motions of making a change and see it go into production. Build up the muscle of interacting with version control and CI/CD tooling so that when they start working on bigger tasks they're already confident about one aspect of the job.

It's Right To Be Wrong

One of the initial hurdles in teaching Nathan was the fact that we weren't able to use the same language. Most folks who are new to programming haven't developed the language skills to describe the technical concepts we interact with every day.

In order to build these language skills, a few things have to happen:

• The person teaching the language has to be able to step out of the world they're comfortable in, and deconstruct it into the smallest pieces.
• The person learning has to be able to learn and retain the information as well as be able to explain their thought processes so that the teacher can identify rogue paths.

If you ask: "What is 2 * 10?" and they respond "I don't know" it's hard to know what the disconnect is. Whereas if they say "12" it's easier to see where their head is at. As long as they're giving their best effort to answer these questions and check their understanding, these skills will develop in time. If they're insecure about making incorrect statements it will take much more time to tighten up that feedback loop.

Part of the Team

As I mentioned before, my first task at SAP Concur was pretty quick. Some of my other tasks weren't. I remember a few times where I had single tasks that took me days, weeks, or even a sprint or two. The tasks required a lot of digging in and deep dives. Those killed me.

Before Nathan joined our team, we had thought about coming up with a project that he would own from start to finish. I was supposed to start spec-ing out the project and coming up with tasks, but I'm glad I never did.

I thought about whether or not that's how I would want to work on a team. Coming in as an intern already makes you feel like you're second-class on the team, and then working on a segregated project just further cemented that. I knew from my internships that working on an intern project never quite felt like "real" work.

Iterative Delivery

We were kind of stuck at a cross roads at the beginning. He wasn't at a point where he'd be proficient on his own, and throwing him into our codebases would've been overwhelming and I think he would've just spun his tires trying to get going.

So, for the first two weeks I had him start with learning React. The first effort was to have him try to make his own To Do application. I helped with a few questions here and there, but it was largely his own effort. It didn't look good, and didn't really work. I could tell from reading the code that he didn't understand what a lot of it did, and that's mostly what I expected.

Once he'd gotten to write a little bit of code on his own, I wrote a To Do application in React for him. I gave it some very basic functionality, but it was missing some components. So instead of having him start from the ground up, he got to see how some of these things worked and was able to change the code to make it do something else.

I'd look at his code at the end of each day and recommend changes and check his understanding of each line, making sure to avoid any massive knowledge gaps. The code got cleaner and more clear with each passing day. I could tell he actually understood what he was doing.

There was a lot of time spent upfront doing white board sessions and doing some handholding through topics, but in my eyes that was all time well spent. If I had just let him struggle through things (instead of struggling the right amount) he would've still learned, but it would've taken longer and he wouldn't have seen the returns on it.

He still worked hard and learned things on his own, but I found that he was getting stuck in very different places. He'd figure a lot out on his own, get stuck, and then get much further before getting stuck again.

If I felt like he was asking questions I thought he could figure out on his own, I'd tell him. I'd explain a few topics, and then leave him with a few to figure out on his own and check in with him later to make sure he got it. There was an understanding that if he needed help, I'd help; but I wanted to give him more room to grow and succeed.

Ownership

After Nathan got comfortable with the HTML and React To Do applications, I wanted him to start contributing to our team's projects. We had some accessibility bugs that would require some HTML changes. Given his newfound comfort with HTML, the work seemed perfectly suited for him.

He went through the entire flow of cloning, branching, committing, and pushing code a few times to get those bugs fixed. We use a tool called accessibility insights that he was able to run against our code to watch the bugs disappear as he made the changes.

Since he was the main one contributing to these efforts, we gave him ownership of the accessibility space. Instead of having to come up with small pieces of work for him to do, he became "Mr. Accessibility" and handled all bugs that were reported. He spent a lot of time doing research and learning about the space, and then used that knowledge to deliver for our team.

It's easy to want to give interns a "little bit of everything", but I think there's a lot of value in having them commit production code and take ownership of a small aspect of the team's work. Giving Nathan that space to succeed was probably one of the best things we did for him during his entire internship.

Eventually he started taking on bigger tasks and contributing outside of the accessibility space, but it was a good foundation for him to be a part of a delivery team and go through the code review process a few times until he had it down.

Conclusion

Being able to provide this kind of opportunity to students who would otherwise find it difficult to break into the field is incredibly rewarding. These students are incredibly hard working, talented, and bring diverse perspectives to the team. We're very excited to be welcoming Nathan back to our team as a full-time employee.