Interview with a Coding Bootcamp Graduate: Cara Ponzini

The opportunity to learn from experienced engineers.

I have an undergraduate degree in geology and studied geochemistry, so I've always leaned towards the sciences. After practicing law for a number of years, I found I wasn't using my analytical skills as much as I would have liked and started looking for a new career.

I am a back-end (services) engineer at Walmart Labs. For my role, I had to have solid foundational programming skills, good communication skills, and be willing to learn. When I was hired, my team was looking for a junior engineer that they could develop.

Many years of previous work experience gave me the skills to be a contributing member of my team, even though my technical skills were fairly beginner. I learned how to program through a six-month full-stack software development bootcamp in Portland.

I didn't see a way to learn on my own while still working. As you might imagine, being a full-time attorney and a parent doesn't leave a ton of time or mental energy for other things. I decided to do an immersive bootcamp to give myself structure and the accountability of showing up daily, just like I did for work.

I chose Alchemy Code Lab. Of the bootcamps I visited, they had the most comprehensive curriculum and put quite a bit of focus on holistic career readiness, not just technical skills. They also have a strong commitment to diversity and actively work towards inclusivity in tech.

Not as scary as it was for some other folks, I think. We covered a wide range of material in a short period of time, which many say is like "drinking from a fire hose" (it was a lot like the first semester of law school, but I definitely don't recommend going to law school to prep for a bootcamp). However, because of this, you get to know the folks in your cohort pretty well, since everyone is operating under similar stress levels. It develops your ability to effectively work with and communicate with others under pressure, which are great skills to have in the real world.

At Alchemy, we did a mix of individual and group projects, so I got a good feel for what it's like to puzzle something out on my own versus breaking up a project among teammates.

When I started at Alchemy, I don't think I'd written any code since monkeying with a GeoCities website decades ago. Alchemy gave me a good foundation in both front- and back-end programming, but most importantly, I got practice figuring out how to problem-solve, research, and learn how to use new tools.

At the end of each learning module, we simulated a scrum sprint, working on a project for a set period of time. Operating in a worklike environment eased the transition to my actual work environment.

Alchemy also has a big focus on preparing students to navigate the tech community. Having alums or other speakers come in and talk about their jobs, challenges, teams, and other day-to-day tasks that weren't necessarily technical provided good insight into what to expect at a startup, consulting firm, or larger company.

Two things come to mind when I think about landing my job: the hours we spent whiteboarding JavaScript array methods in VanillaJS and Shannon helping me transform my legal resume into a tech resume and update my LinkedIn profile to highlight the skills I had from being a lawyer that would transfer to tech. Practice-talking my way through logic gave me confidence in the technical part of my job interview, and my former career acted as a conversation starter for recruiters and the engineering manager who hired me.

The most challenging part of my job, I think, is individual to my situation, and it's that I feel slow. I'm fortunate to work on a team with six engineers who have been in this field for at least a decade, some for multiple decades. The challenge is that sometimes I forget that I haven't also been doing this for a long time and can get frustrated when I'm not able to solve a problem as quickly, or sometimes at all. However, when I look back at where I was when I started in this role and where I am now, there's no question that I've learned so much from working with these folks. My teammates are all good teachers and are able to explain complex concepts in ways that are easy to follow.

I work on a team.

This week, I'm on call, which means I support our services in production, answer questions from other teams, captain any production deploys, tune alarms, and generally try to pick up admin tasks so that the rest of the team can focus on sprint work. We rotate on call on a weekly basis.

When I'm not on call, I'll log on in the morning for stand-up, which is our daily meeting where we each talk about what we worked on the previous day, what we plan on tackling today, and whether we need help or are blocked on anything. For the rest of the day, we try to tackle sprint work, sometimes solo and sometimes in pairs. My team likes to pair-program, so I'll often spend time screen-sharing with a teammate.

Several days a week, we have an extra meeting in the morning for grooming tickets, handing off on-call responsibilities, or (my favorite) learning about technologies other teams are using within our organization. At some point in the afternoon, I like to try to look at pull requests and see what others have been working on. Since my team is dispersed across the country, a few of my coworkers have signed off by the time I'm done for the day, usually around 5:30pm.

We are currently working on decomposing some of our main service's functionality into microservices. One of these uses GraphQL, which is fun. I like the concept of a caller being very specific with a request and getting back only the information they need, while limiting the number of data sources being accessed to only what's necessary on the back end. It's a nice contrast to a traditional REST [REpresentational State Transfer] API.

This is a tough one. As far as developments in tech in general, I have some daily email newsletters that I read, but I've asked my teammates the same question. We have some special interest groups within Walmart Labs that I've joined, and we'll discuss updates to frameworks or languages we use in weekly meetings. It's interesting to see what comes up and talk about potential use cases or impacts.

You don't necessarily need a computer science background or degree to succeed as a software engineer.

Don't let the "transition" part of "career transition" discourage you. I've talked to a few folks with a lot of experience in another field who want to transition to tech and are concerned that their former profession will be a detriment. I disagree. If you were successful in another field, some of your skills and strengths will be transferable. You can figure out what they are and reframe them in tech terms.