Lessons a coding boot camp can (and can’t) teach you

Learnings from our new class of Carrot U boot camp grads

We created Carrot U, Instacart’s very own coding boot camp, to offer high-performing employees in non-technical roles the chance to learn the engineering basics. At the end of the program, Carrot U graduates get the chance to interview for open engineering roles.

In prep for our 2019/2020 Carrot U cycle, we sat down with Sveta and Michael — two of last year’s Carrot U grads who made the jump over to our software engineering team — to talk about the lessons you learn in a coding boot camp, and discuss the lessons that only on-the-job experience can give you.

What was your first role at Instacart, and how did you get interested in Engineering?

Sveta: When I first joined Instacart, I was on the team that helps onboard new retailers onto our platform. I liaised between our engineering team and our retailers, explaining technical concepts to our retailers and taking their needs back to our engineers.

Michael: I’ve had a long journey here at Instacart. I started out as a full-service shopper in 2014. Later, I applied for a role on the customer service team, handling calls and support requests from customers. On the customer support team I found myself doing a bit of QA work, and eventually hopped over to the Logistics Operations team, which handled things like storm management (i.e; if a Hurricane about to hit Florida, what delivery zip codes are going to be impacted? What retailers would be affected?)

When I joined Logistics Ops I didn’t even know how to do basic equations in Excel. I had to teach myself Excel and started to learn SQL queries — a team member on set up some basic “learn SQL” lessons for a group of us.

Sveta: Yeah, I had dabbled with SQL in my role, too. Looking back, writing simple SQL queries is a really easy way to kickstart technical training. It made becoming an engineer a bit closer in my mind than I initially thought.

What prompted you to sign up for Carrot U?

Sveta: I was always interested in engineering but I felt like I never had the means or the time to go out and do a boot camp. While I learned how to make SQL queries, I never thought I would actually make that jump to engineering.

It was actually one of my coworkers here, Muffy, who encouraged me to apply to Carrot U. I met Muffy within my first month here — she’s a big proponent of women in STEM. A few months later, when the applications opened up, I signed up.

Michael: I wasn’t even really all that interested in applying at the start — I liked my position! I got interested when a couple of my coworkers pointed out — “Hey, you’re the go-to person on Logistics Ops for SQL. You’ve taught yourself this within the last eight months, you’d be a perfect fit. Are you going to apply for this?”. That’s when I applied.

Sveta: To be honest, when I first started it was terrifying. I thought to myself, “I don’t know how I’m going to learn any of this so quickly.” But throughout the program, I learned to rely on mentors for support. A former Carrot U grad, Jeremy, served as my formal mentor through the program. I always went to office hours with other program mentors, Dan and Viktor. Muffy was always there for me, too, serving as an informal mentor on the side. I could always come to any of them with questions.

What was your final Carrot U project?

Michael: The final projects were fun. Once we had learned the basic languages and gone over some of the basic comp sci theory, we had to build an application with a team. My group spent a month essentially building a phone book application for Instacart where you can look up employees on different teams and you can find their bio and award virtual badges to them.

Sveta: Mentorship was so important for me and other folks throughout the program, so I worked on a group project with two other people where we built an app that matches up mentors and mentees internally. If you were interested in strengthening a specific skill set (like Ruby or Python) you could go on to the app, sign up, and list skills you were interested in learning. Experts at the company in certain languages or skills can sign up on the other side to be a mentor.

What was the biggest surprise for you once you became a full-time Software Engineer?

Sveta: Learning to work with the legacy code was a huge one.

Michael: Yeah, anybody can figure out the languages with a little work. Anybody can figure out how to write a complex Ruby method or write some fancy logic (seriously). But being able to actually work with legacy code…that’s where it gets difficult. Working with a shared codebase in Github was definitely challenging at first, but now it’s second nature.

Sveta: When you’re working on your final group project, you’re basically building everything from scratch. I found that building from the ground-up to be a little easier — you’re building from what you know and debugging. With legacy code, you really have to take the time to understand what every little change is doing — where it might radiate out and affect other things.

I now understand why so many engineers sometimes just need to be “heads down” and why there have these buffer periods during sprints — it’s because if you run into those blockers and it’s going to take time to understand that legacy code and fix any of those issues within it. There’s a lot of ambiguity that you have to account for.

Michael: Another big surprise for me was how much of engineering is debugging. The majority of my time is spent debugging and figuring out how to make my local environment behave as it should. You don’t spend as much time as you’d expect actually building something — maybe about 30 to 45 minutes. After that, you spend the rest of your day testing it and debugging the things that aren’t working the way you want them to.

Were you expecting your role to have so much ambiguity?

Michael: After graduating Carrot U and jumping into my new role, I was really surprised by how ambiguous the problems you solve as an engineer can be. I might have three tasks for the week…and I sit down on Monday morning and I look at those three tasks and say: “You’re kidding me. It should take me five hours to do these three things.” The first task takes me 30 minutes, the second task takes me 15, and then get to the third and I dive into the code base and it may take me three months to complete.

Sveta: Yeah I learned really quickly how to work when there isn’t a clear answer or even a clear path to an answer. It was really hard at first — I was a bit terrified, but I got used to it pretty quickly. Getting comfortable with ambiguity helps you think in a different way. As you learn to deal with that ambiguity, you’re just building up your engineering skillset.

Want to join Sveta and Michael on our Engineering team? Check out our current openings.