Switching Roles: From Test Engineer to Software Engineer

It’s a regular weekday afternoon and I’m sitting at my desk in the WillowTree Durham office. I’m enjoying some fancy dark chocolate peanut butter cups from the kitchen while working on my current React Native project. I’m a software engineer (SE). 

If you’re reading this, you might be wondering how I got here. I started at WillowTree as a test engineer (TE) about two years ago and just recently transitioned to a developer role. In this article I’m going to talk about my transition from a TE to an SE and what I learned about switching roles. 

Let’s rewind back to 2021. For a bit of background, I joined WillowTree as a test engineering intern during my senior year in college. I had switched majors a couple times and didn’t know exactly what career path I wanted to take, though I was pretty set on some sort of engineering track. One thing I liked about WillowTree was that personal development, growth, and career exploration are encouraged. After my internship, I joined full-time and focused on my TE skills for the first year or so. I really enjoyed being a TE, but eventually, I realized that what I really wanted to do was become a developer. Part of my motivation was that I like creating things, particularly if they look cool. So frontend development was especially attractive. 

Now that you know a bit about me, let’s get started with the story! I can break my transition from TE to SE into 5 main sections – and stay tuned for some bonus notes at the end. (Disclaimer: I’m sure that everyone’s progress from one role into another varies widely, and this is by no means a standard guide – just my anecdote.)

Part 1: Getting close to the application code

Test engineers at WillowTree deal with lots of different types of tests, like UI, component, and unit tests to name a few. I think that any kind of test experience is helpful on the road to the developer track, but I personally found that writing tons of low-level unit and component tests helped the most. For me, learning how to unit test was a big part of learning how to develop, because I needed to understand how the code worked in order to test it well. As an intern, I worked on writing backend tests in Kotlin. Later, as I decided to focus on frontend, I switched to writing more tests using Jest and React Testing Library, which got me started with learning React. 

As I was ramping up on my first project, I also got recommendations from my developer teammates for courses that could help me get familiar with the languages and tools used on our project. WillowTree provides a professional development budget, and I’m a big fan of platforms like Udemy or Frontend Masters, so I used my budget on courses through these sites. Other platforms recommended by engineers include Coursera and Laracasts (a webcast platform for learning web development). And if online courses aren’t your thing, additional tried-and-true methods include:

• reading through official documentation and putting it into practice
• reading professional development books (e.g. O’Reilly books)
• following tutorials offered by the technology vendor
• finding popular blog posts (e.g. Medium) or YouTube videos about the technology

Everyone’s learning style is different, so choose whatever resources work for you.

Part 2: Teaming up with the devs

As I started getting more comfortable with the languages and frameworks on my project, I wanted to try my hand at this developer business. The first step was letting my manager and teammates know that I was interested in picking up some development tickets, so they could offer me those opportunities. Then, I could 1) pick up low-hanging tickets on my own, or 2) pair with other engineers to work on bigger tasks. Pairing with other engineers in particular created a lot of learning opportunities, whether I was driving or just tagging along. After absorbing enough of their knowledge, I started taking ownership of developer tasks that had a more significant impact on the project – which was a great way to show skills and maybe even get some Lattice¹ 🥬 feedback.

Part 3: Talking with mentors and showing off some side projects

Talking with my long term mentor (LTM)² and my manager were hugely important during my transition. They provided some really valuable guidance on where I needed to focus my efforts to facilitate the transition to SE. Since I was aiming for a JavaScript developer role in particular, my focus was, well, JavaScript and React. Once I was feeling pretty good about those, I also started poking at neighboring tools like Node and Next.js. 

Taking courses on relevant topics and completing tickets on my project was a good start, but I needed a way to show more skills outside of that. Enter side projects. One personal project that I used as evidence for my potential to be a developer was the Name Game. I hear the Name Game is usually part of the engineering interview, but since I hadn’t interviewed as an SE, this was news to me. When (after more than the two days allotted in the interview, I admit) I completed the Name Game, I had a project that I had built from scratch which showed a variety of engineering skills. It also provided more opportunities for… 🥬 feedback from my mentor (you may see a theme emerging here). I worked on a couple of other personal projects besides the Name Game during my upskilling period, and overall, I think they played a big part in my transition to a developer role. 

Pro tip: if you work on a side project trying to learn a new skill, present that project to your LTM (or another engineer who is a pro at that skill) and ask for their feedback on how you can refactor or spice up your project for an extra challenge. I’ve found that everyone I reached out to, whether my actual mentor or other developers on my team, were more than happy to provide resources and guidance.

Part 4: Almost ready – scoring an unallocated role

Bear with me – we’ve been on this journey for a few months now but we’re getting close to the end (sort of, we still have a few more months to go if I’m being honest with you). 

Once my manager, mentor, and I all felt pretty good about my ability to succeed in a dev role, it was time to find that role. Starting out, it was expected that I would be placed on a web team in an unbillable frontend dev position, and then transition to being fully billable. Things didn’t quite go according to plan…

~A quick aside~

As I was getting ready to leave my TE role, the manager I had since joining WT left the company. This was a bit of a downer since he had been very supportive of my goals and was the person most familiar with my work. But it didn’t turn out to be the setback I thought it might be. My new manager was equally supportive and was able to champion me because I’d taken some time to fill out my engineering rubric³ with as many things as I could remember from the past year. Keeping my engineering rubric up to date was by far the most common advice I got as I was going through this process, and it definitely helped!

~Back to the story~

Things didn’t go as planned, and instead of being put on a project right away, I was unallocated⁴ for a few weeks. During that time, I started looking into React Native (RN), and eventually I got put on a RN project for my first un-billable SE role. This offered me a couple of great opportunities to do development work on a client project. However, it was a short-lived glory, as the project came to an end just a couple of months after I joined. Ideally, you would be able to stay on your project for longer, do some awesome work, become billable for at least 3 months, then get that SE title. But it wasn’t meant to be, so on to the next step!

Step 5: Leaning on Lattice

After I got off my first RN project, I continued on the RN train by joining the RN summer cohort, as the season permitted. The cohort was a group of WillowTree engineers who were in-between projects and interested in learning React Native during the summer of ‘22. We were assigned a 2-week course to get us up to speed on the framework and completed a project (a food ordering app) as part of this course. Being in the cohort provided a structured environment where I could share my progress and questions in a dedicated Slack channel, participate in bi-weekly stand-ups, and pair-program with others who were working on the same skills. Overall, it was a great chance to focus all my time on up-skilling and gaining even more development experience. After a few weeks, it placed me on the Meals on Wheels project, one of WillowTree’s low-bono client projects using RN. At this point, I had been out of the TE role for a few months, and I’d accumulated a decent amount of un-billable project experience, and – you guessed it – 🥬 feedback. 

However, with allocation being unpredictable, I hadn’t gotten those 3 months of billable SE work that I needed to officially transition roles the standard way. As end-of-year evaluations were approaching, my role within WT felt uncertain. Would I get evaluated using the platform TE criteria or the SE criteria? Since I was quite far along in my transition, I was told to fill out the rubric for the role I wanted to have. So the month before end-of-year evaluations were due, I shared my updated SE rubric with my manager, who shared it with other relevant leadership. As the evidence in my rubric and Lattice was compelling enough, I was actually turned into a software engineer! With final approval from HR, my role was officially changed, and I immediately celebrated by eating a few more peanut butter cups. Although I didn’t get to this point the way I expected to, it all worked out in the end.

The bonus steps

But wait – there’s more! During my role transition, there were a few other miscellaneous things that made a difference:

• Attending internal developer events, such as platform Grow sessions⁵, to meet and learn from fellow software engineers. 
• Mentoring other trees. I got to mentor two engineers during their onboarding period while I was a TE, and this was a great way to also learn about my own strengths and growth areas.
• Talking to coworkers who have gone through the same role transition. Because the paths that people take towards software engineering can vary, different people may have other insights, tips, and tricks.

So that’s it, folks! All that is to say, I don’t think there’s one single path to transitioning into software engineering at WillowTree. The way someone else could approach it, and the opportunities that different projects provide could be very different. From my experience, I think it’s mostly about gaining those skills in a way that works best for you, keeping track of your successes in Lattice, and leveraging your fellow trees who can support your growth. Thanks for reading!

Footnotes

1. The platform used at WillowTree for sharing peer-to-peer feedback, as well as viewing rubrics and keeping track of personal goals.
2. A fellow WillowTree engineer who meets with you regularly and helps you work towards your professional goals. Every engineer at WillowTree is assigned an LTM after their 90-day onboarding period.
3. Guides used to set standards and evaluate performance at different levels within Engineering at WillowTree. The rubrics, split into categories from Code Design & Architecture to Team Collaboration, specify what is expected of engineers at each level and are a big part of the promotion process.
4. Not on a client project. During unallocated time, engineers typically focus on professional development and side projects.
5. Weekly learning and networking opportunities, organized by team/discipline, where people can share ideas, tools, and projects, or do team bonding activities.