How to make a good impression as a new grad engineer

A friend of mine asked me this in our quarantine Discord the other day:

Any advice on how to make a good first impression to my manager and my team? I start Monday 😀

Why this needs to be specific

Advice for new grads should be more specific than the usual advice for standing out as a software engineer.

• You'll be perceived as young.
• You most likely lack the experience to be "generally effective", even if you've had a few internships.

I'm excited to share what I've learned in the past 2 years.

It's easier to lose a good impression than gain a better impression

It's tricky to manage a good impression IRL, especially remotely, but easy to tear down a good prior impression.

The trap I notice some smart new grads or interns fall into is trying to act like they know everything. Be humble and pleasant to work with. If you really want to, signal confidence in other contexts, maybe when talking about the things you're sure you're good at (like maybe you understand CSS specificity or obscure football trivia really well).

The majority of junior developers will maintain code the majority of the time. If you're maintaining code that's frustrating to read, don't let frustration lead you to think, "oh, this code is so stupid, what dumbass would write it like this?!" and maybe even embark on a risky path down a rewrite no one asked for.

Maybe you're partially right, but there's also a good chance you're wrong.

• If you're maintaining the code to support a new usecase, it's likely that the engineer didn't care or know about that potential usecase at the time. Perhaps they weren't dumb to not make the code modular or clear enough for it to be iterated on in the future, but rather they just realized "You ain't gonna need it", or YAGNI, at the time.
• Be wary of making large, sweeping changes or casting skepticism about the way things are in a codebase, without knowing the full reasoning behind it (or even simply assessing the author's code in good faith). The principle here is Chesterton's fence — from Wikipedia, "the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood" — If you don't understand why something is, there might be a good reason it is the way it is.

There are obviously counterexamples to the above, but those are just things to keep in mind. You always reserve the right to be frustrated, I mean hopefully they're paying you a lot for your patience.

I forgot where I heard this from, but there's a saying that "the young make up for the old in speed and the old make up for the young in experience." This holds some truth on a software development team: the young are spry, ready to move fast and break things, whereas the more experienced are calm and calculated, making long-term decisions that don't bite the team back in the future (in the form of technical debt). This could be a powerful dynamic, respect it.

How I stood out

Here's what worked for me:

• I was eager (but not to the level of brown-nosing/politicking).
  • I picked up stuff no one wanted to do.
• I demonstrated coachability and ability to grasp more senior engineers' opinions and implement them into my own work quickly.
• Very few times ever did a senior engineer have to explain something to me twice. It looks better to ask for clarification as they're describing something complex, and repeat their explanation back to them (in simpler terms) in the moment—rather than to feign understanding and ask them to repeat themselves a week later.
  • Or at least, say something like, "I don't get this yet, but I think I will once I dive into the code. I'll let you know if I get blocked."
  • (Because in their shoes, I would imagine, "Wow, so they didn't understand what I meant for the whole week? Wish they'd been more up front about that.")
• I demonstrated ownership. One of the coolest ideals for a senior engineer, which I learned from one of my best mentors, is that of an engineer who does not need a manager. I won't go into the details of what a manager should be doing (my opinion isn't actually well-formed on this), but essentially, the best engineer, in theory, would not need a manager.
  • She would pick up tasks independently and be able to coordinate with product and design on their own. She would be able to plan and de-risk failures (both of the system and of the team's ability to deliver a project on schedule) with little guidance.
  • In this world, the main purpose of the manager would be to keep their engineers happy, to prevent them from leaving the company. To tell you the truth, this is an ideal I'm working towards, but this level of ownership is something you can start working towards once you've developed situational awareness of your organization's processes and mature out of new grad naiveté.

Don't be a[n inefficient] sucker. Leverage is the name of the game

This held true for working life in the office and at home as well, but it doesn't impress me much when someone sends me a Slack notification or stays in the office until 3am (unless 3am is when they think they're productive).

Humans are probably capable of 6-8 hours of productive and creative flow time per day (writing code and prose, not shuffling emails). My idea of a "good engineer" is one who balances their time efficiently, understands the most important, high leverage things to work on, and spends their time on that.

The value of engineering as a discipline is literally leverage, that is reducing the time for people to do dumb tasks, including the way you engineer. Let me get into that when I talk about going faster. For now, understand leverage as: impact produced / time invested.

What are examples of "high leverage" things? It's hard to think about especially if you're not being assigned interesting work. But tons of "uninteresting" work can be high leverage (and actually fun once you get into it):

• Writing engineer onboarding docs: This is particularly high leverage if the team is growing quickly. I have a friend at Airbnb who was one of the first engineers on their team (as a new grad) that team has grown to 20. I was tasked to write engineer onboarding docs at my last company as we were expanding our engineering team rapidly.
• I recommend The Effective Engineer by Edmond Lau. The first chapter of the book presents more details about the best mindsets to adopt to make a meaningful impact, including focusing on high-leverage activities.

One of the highest leverage things you could do when you're not being assigned interesting work is to prove you're worth assigning interesting work to (assuming your team has reasonable people assigning work).

To prove you're worth assigning work to, live out the four characteristics I described above, but also help yourself go faster. What a perfect segue...

Go faster

To go faster, invest in tools that improve your workflow. Demonstrate curiosity about more senior engineers' dev workflow. Some examples:

• All the shortcuts in your IDE that keep both of your hands on the keyboard and off the mouse/trackpad.
• My tech lead has a "paste buffer" on Alfred. She can store a "stack" of things on her clipboard, and a plethora of shortcuts for code snippets she commonly types.
• Multiple people on my team use tools for working with git effectively. Some of the most time consuming but brainless things people do at a large company is cherry-picking diffs on older release branches (especially true if you're fixing bugs). There are tons of tools that make cherry-picking with git (and even automatically composing a boilerplate commit message and PR title) a lot faster.
• I have a blog post I wrote during my second SWE internship in college that might still be applicable.
• And see relevant xkcd below. Even if effort towards your automation doesn't pay off soon, it's good to exercise the habit of caring and getting better at the act of improving your tooling.

Filter through the noise

Think about the resources you encounter when you research towards solving a problem:

• Documentation written by others
  • in your team
  • in your org
  • at your company
  • who've left your company
  • for an open-source tool or language you use
• Tutorials that tangentially help you with your problem
• Conversations on a GitHub issue or PR
• StackOverflow answers

It's useful to be reflective about the relevance of the documents you're parsing and decide if they're worth understanding the details of now or later. This can save you time from going down a rabbithole. Though I will say, old design docs and product briefs can be super interesting to read!

A related skill is knowing how to Google effectively.

Timebox your confusion

I walked into my first job (a startup) with this mindset (no one there asked me to think this way):

Rainier, you're the first new grad engineer hire at this startup. Right now and for the next few weeks, you're costing the company more than anyone else (think about the resources that went into hiring you and the time you'll take from senior engineers pairing). Your top priority is to be productive and impactful as quickly as possible.

Obviously, you don't have to approach it this direly at like, Microsoft. And no matter where you are, don't feel "selfish" with other people's time—if an senior engineer helps you with a task that you would've been stuck on otherwise for 5 hours, that's 5 hours of the team's time.

A more specific analysis of the time tradeoff would go like this: Well, if I ping an engineer in flow, it'll probably take them 30 minutes to switch context back to whatever they were doing, plus the time they'll have spent helping me, plus the time I'd been stuck on it prior to messaging them. If you're working in an office (unlikely as of the time of this writing, so you're already doing this unless you're calling them on the phone), you should instead message them asynchronously (e.g., on Slack) if they seem busy.

On the flip side, you will learn by struggling a ton and you shouldn't ask your hand to be held for every complex task. As a happy median, timebox your confusion. If you're stuck on something for longer than say, 30 minutes, then ask. Also, I like to round robin my teammates if the thing I'm stuck on is something anyone on my team can help with.

Write down your wins

I had trouble keeping up with this, but I've recognized that as we're working remotely now more than ever, a frequent writing habit for your reflections and wins can come in handy when you're thinking of things to talk about with your manager—and justifying a promotion or comp adjustment during performance review season. What are things I write about?

• What I learned this week, and how it ties into my medium- and long-term career progression (usually a twice-a-week reflection).
  • Related to this, as a general tip, is to show curiosity by asking questions about engineering practice (project coordination, team dynamics, hiring, inclusion, conflict resolution, risk management, security, site reliability, oh yeah and the code itself, etc.) and writing down the "case studies" or opinions you encounter so that you can develop your own opinions and models to apply to uncertainty or new problems in the future.
• Compliments and kudos from other teammates (these usually come in during our sprint retros or in code review feedback—could screenshot them in a digital scrapbook if you wish).
• Meaty features and bugs with a huge customer impact (can backtrack these from my commit history as well, but it's nice to synthesize these).
• Small, even one-pager design docs for large tasks that haven't been completely thought through yet.

I like these because they're a paper trail, these writings are artifacts of your personal growth and accomplishments outside of your GitHub commits.

If you made it to the end, you likely care enough that you'll be at least ok. You can do this! Good luck.

Did I miss anything? Feel free to reach out to me @rainieratx or via my contact form.