3 tips for beating the junior jitters when starting in tech

After graduation, I was hired as Pitch’s first junior engineer. I couldn’t wait to kick off my career in tech. But as my first day at work approached, I found myself feeling anxious about living up to the challenge ahead of me. Luckily, with the help of my team, I overcame my junior jitters and gained confidence in my new role. Here’s my advice for folks starting their careers in tech.

Transitioning from college to a work environment was a big adjustment. With my computer science degree in hand, I knew I wanted to become a software engineer, but when I got the job at Pitch, self-doubt hit me:

Was I really ready? 

What’s expected of me as a junior team member? 

What if I break stuff? 

What if I don’t succeed? 

How do you really use git, anyway? 

I had a serious case of imposter syndrome. I was looking forward to getting started, but the thought of joining a team of highly experienced software engineers — who were working on a product used by tens of thousands of teams — was daunting. 

When I got started, I decided to be open about how I was feeling. It was tough to admit how little I knew about software development in practice. But my new colleagues were incredibly receptive, and they all pitched in to help ease my transition. 

I realized that it wasn’t my job to know everything, but to learn. In that spirit, here are three things I’ve learned so far about what it takes to hit your stride in your first job in tech.

Ask lots of questions — and ask them publicly

Soon after joining Pitch in August 2020, I realized I had a lot to learn about how software is built collaboratively by teams of engineers. College prepared me for writing code, but not for shipping software in a product team. I didn't know how to create a pull request, or what it meant to review someone else’s code. 

At first, I was worried that others would find out how little I knew. I was afraid of asking questions because I didn’t want to sound incompetent or naive. But after some reflection, I realized that pretending I knew things wouldn’t get me far. 

I stopped trying to figure everything out by myself, and started speaking up when I didn’t know things. 

I stopped pinging people privately, and started asking questions in public Slack channels. 

In short, I stopped hiding my inexperience, and started embracing it.

My new approach helped me find the answers I was seeking. But just as importantly, it brought me a broader range of perspectives — not just from my manager, but from the entire engineering team. I also found that asking a question publicly opened doors to new topics I hadn’t discovered yet. 

A few months in, I felt my growth start to accelerate, and I began getting shout-outs from colleagues: 

Asking questions in public didn’t just teach me the basics of building software as a team at Pitch. It was also the key to learning Clojure — the language most of our codebase is written in.  My change in approach massively helped my progress in just about every way. So I’d encourage any other growth-minded junior engineer to stop hiding, and start asking. 

Learn to manage up

When you’re just starting out in tech, it’s natural to assume that your manager will tell you what to do and how to improve. I assumed that myself, but I’ve since changed my view. 

A good manager does provide guidance and mentorship. But I learned that if you really want to flourish, you need to take ownership of your personal growth by making your development a two-way conversation.

Even in relatively small teams of engineers, a manager has many different responsibilities (and other people to manage), so it's up to you to help them help you grow. Reading First Round Review's A Tactical Guide to Managing Up really shed some light on this for me.

In my first few weekly one-on-one meetings with my manager, Oskar, I expected him to lead the conversation and tell me what to focus on. But after reading about managing up, I changed my approach. 

I created a shared document, and before each one-on-one, I wrote down topics I wanted to discuss. I outlined how I wanted to spend my time in a given week, what was blocking my work, questions I had, and where I wanted to grow. 

We like to adapt this template for 1:1s on my team at Pitch.

These preparations really raised the quality of my relationship with Oskar — they made it much easier for him to give me feedback and help me where I needed help. Our discussions became ten times more productive, and how we worked together improved a lot.

Become an expert in a topic, even if it’s not flashy

At Pitch, we help new joiners get the hang of our codebase and workflows by having them work on smaller tweaks, improvements, and bug fixes before they take ownership of big features. 

My own first tasks were focused on small improvements to the user onboarding flow. It wasn’t the flashiest part of our product, but I was really excited to work on something that’s touched by every single new user. After I’d spent a few weeks making these small improvements and fixes, I was assigned my first big feature: passwordless authentication. 

Passwordless authentication lets you sign up for Pitch with a simple one-time code — no long, complicated passwords necessary. Cool, right?

Tackling this feature just a few months in was challenging for me, but I got an up-close look at our authentication flow and at how users get started with Pitch. By the time the feature finally shipped, I’d gained a deep knowledge of our onboarding flow. This proved invaluable as I moved on to build many other onboarding features. 

It felt great to become an expert on a topic — and to be relied on by my teammates for the expertise I’d developed.

A never-ending learning journey

These days, I’m not so junior anymore. I’m tackling more advanced technical features. I’m also contributing my expertise to a new team that’s helping Pitch grow by making it easy for users to get started, invite teammates, and share their work.

Reflecting on my earliest days at Pitch, I now realize that I put too much pressure on myself. Pitch didn’t hire me because of how much I knew — I was hired because of my capacity to learn and grow. To this day, I still consider this my most important skill set. 

In that sense, starting my first job as a software engineer wasn’t a transition at all. It was a continuation of the learning journey I’d been on since kindergarten. It’s been a rewarding adventure so far. And as long as I stay open to learning and growing, I’m sure the future has plenty more in store for me.