Tag Archives: engineering

3 Types of Technical Interviews

This is the third post in the recruiting series that I’m currently writing! I’ve written two other posts, about my recruiting goals, and sourcing companies. In this one, I’ll be laying out the structure of the 3 different types of technical interviews I encountered, what studying techniques worked best for me to prepare for each type, and what my candidate experience was like for each of them.

I’d like to start by sharing that I’m not naturally gifted at technical interviews; they’re a far cry from what day to day work looked like for me. Last time I recruited, I underestimated how nerve-wracking and unfamiliar live coding would feel, and blew interviews with companies I was really interested in because of it. Even this time, I was rusty and stumbled over random things I’d forgotten about in my first few interviews, but over time, my pass rate increased, and my interviewing anxiety decreased. The best way I got better at interviewing, was by doing more interviews.

The goal of technical interviewing is to detect signals that the candidate would be a good fit for the role. I like to think that interviewers really want candidates to pass their interviews so they can spend less time interviewing and bring on more people to share their workload. But this needs to square with the risk that interviewers have of bringing on a teammate that ends up creating more hurdles than they help the team clear. As a candidate, everything I did in technical interviews was with the goal of giving my interviewer confidence that I’d be an asset to the team, and I kept in mind the general rubric that I used when I was an interviewer:

  1. Did the candidate solve the problem?
  2. Was their solution efficient and clean? Did they consider edge cases?
  3. How well did the candidate communicate their thought process?
  4. Were there any red flags during the interview?

The 3 types of technical interviews I encountered were: general data structure and algorithms (roughly 60% of my technical screens), building something practical (roughly 30%), and take home projects (roughly 10%). The structure of each is fairly different, so my prep varied accordingly. Before interviews, I asked recruiters the following questions to gain a better understanding of expectations before each technical screen, and what type of interview I’d be doing:

  • What interviewing tools will we be using? CodeSignal, CoderPad, and CodePen are examples of shared coding environments I’ve used. It was helpful to play around with new tools to familiarize myself with how to navigate them and how packages like React or lodash were compiled.
  • Should I have my own dev environment set up with some boilerplate? If yes, is it okay to install and make use packages such as lodash or jest?
  • What am I being assessed on? Most recruiters would tell me what I needed to emphasize.

Data Structures & Algorithms

Prepping for data structure and algorithms was pretty straightforward – I use two resources: Interviewing Cake (paid subscription was 100% worth the value) and Leetcode. I did about ~50 Leetcode questions, and focused mainly on classic data structures and common strategies: strings, arrays, hashmaps, trees, recursion, sliding window algorithms, matrices, dynamic programming, and graphs. I didn’t bother studying more esoteric stuff because I wanted to be efficient with my time, and, well, I told myself I probably wouldn’t want to work at a place that was going to haze me through interviewing.

My strategy for practicing Leetcode:

  • Pick a topic and do problems on that topic until I feel comfortable doing a random medium level question. The more I did, the more I noticed patterns in the solutions.
  • Give myself an hour to attempt the problem as if I am in a real interview (e.g. talking out loud and verbalizing my thought process) before looking at the solution.
  • Make sure I really understand the mechanics of the solution, rather than simply memorizing it. This helps me recognize how to adapt an approach for a slightly different problem.
  • Schedule mock interviews with friends or via tools such as Pramp to mimic live coding pressure.

My strategy for actually doing the technical interview is pretty much ripped off of Amy Nguyen’s technical interviewing blog post, so I won’t repeat it here. I think the most important thing I had to remember in interviews was to avoid diving into coding before I had a full and complete plan of what I was going to do.

Building Functionality

Building interviews were definitely my favorite kind because they most closely resembled the type of work that I expected on the job, and was already doing at my day job. The exercise was usually something along the lines of building a small feature (for example, the UI for a basic calendar app, or APIs to support a chatroom app). The problem is usually presented vaguely (let’s build a calendar) to get a sense of how engineers take a vague requirement and turn it into real functionality. While there wasn’t as much new material to refresh myself on, I took a very structured approach when I did these types of interviews that mimics how I build bite-sized functionality in real life:

  1. Clarify the domain: What functionality do we want to support? How does the typical user interact with what I build? Since I tend to be forgetful in high-stress settings, so I wrote down all requirements down to make sure I covered them.
  2. Identify edge case: What error states could the user hit? How would we handle those in our application?
  3. Communicate my plan: I talked about my approach and how I planned to organize my logic (this usually involved writing more than one component for UI work or multiple endpoints for server side work) and validated that my interviewer thought my plan was okay. I talked about technical tradeoffs if I could think of more than one approach, and interviewers would usually guide me towards the preferable ones. This is also usually where interviewers would drop hints about other things they wanted to see, or stuff I didn’t need to cover.
  4. Code: I compiled my code and validated my logic through user interactions often. As someone who has also been on the interviewer side of this process, it’s very hard to help candidates debug errors if they’re not validating it often. As a bonus, it gave me confidence that I was making forward progress in the exercise, and I could catch errors early by testing my own code regularly.
    • As I code, I called out what I would do differently in a real life scenario: placing a component in a different file, creating a new child component, writing tests for my code, etc. and would sometimes ask my interviewer if they’d like to see these things. The answer was always no, but I think this signaled that I do think about things like code organization.

It was helpful for me to watch other implementation interviews on YouTube so I could mimic some of the approaches around communication or explaining technical decisions. Ben Awad has a good one that was fairly representative of most of my frontend implementation interviews, and after I watched it, I had a better sense of what I could expect.

Take Home Interviews

Take home interviews usually involved building something over a longer period of time. Companies liked to say that they should only take 2-3 hours, but I spent at least 6 hours on them each time I received one of these. There are always ways to make code better, and when I’m not time-boxed, work expands to fill the available time I have.

As an interviewer, I thought these were a great idea: there’s no live coding pressure, I can use whatever resources I want, and there’s no time limit. I think take homes are designed with the intention of improving the candidate experience, but they miss the mark when it comes to providing a good candidate experience:

  • Feedback was never provided on the submission, so it also didn’t help me improve at all as an engineer. At least in live coding scenarios, there’s some collaboration and back and forth with the interviewer and you can identify areas that you’d improve upon.
  • There was no way to gauge collaboration with other engineers. In real life, engineers typically ask clarifying questions and think of different ways to approach a problem, along with accompanying tradeoffs. Removing collaboration or visibility into the candidate’s thought process means you miss out on the why of particular approaches, and the candidate has no way of explaining.
  • There was a huge opportunity cost for me to be working on a project for 6 hours because I could have used this time to study for my other interviews!

I guess this is a copout section because I don’t have good prep advice here – even though I passed most of these interviews, I never got feedback on why I passed or failed, and it was really hard for me to know what I was doing well or could improve on. I’m probably going to continue my experience of dropping out of interviews that want me to spend my weekends on their projects.

General Thoughts on Technical Interviewing

  • If I had a nagging sense that there was something I could have done way better in my interview, I would work on the problem after the interview, and email an updated solution to my interviewer or recruiter, explaining that I fully understood my updated code might not be factored into the debrief. This is one of those things that doesn’t always work, but as a candidate, I felt like I didn’t have a lot to lose with this approach. The worst that could happen is that it wasn’t taken into consideration, and the best is that it changes the outcome of a decision because the company has a better sense of what I’m actually capable of.
  • Communication is really, really key in technical interviewing. I’ve passed interviews where I didn’t complete every part of the problem (and some interviews are intentionally designed as such) but was given feedback that my communication provided a strong enough signal to move ahead. Interviewers don’t know what candidates are thinking if they don’t explicitly communicate it, and I do think that interviewers tend to drop more hints to candidates who communicate that they could use them.
  • I focused on making forward progress rather than worrying about a complete solve because it was a way for me to remain calm and focus on the piece in front of me that I had to solve. When I encountered something I don’t know, I methodically tried different ideas that hopefully bring me closer to a solution, such as mocking data, googling a method (if allowed), brute forcing, or even writing the logic in pseudocode.
  • When I received decisions about my interview, I always responded and asked for feedback. Surprisingly, what seems different from interviewing a few years ago is that I felt like many companies were willing to give me feedback if I asked for it. There wasn’t a single company I asked who said they couldn’t or wouldn’t. I took notes on my interview performance and tried incorporating feedback to help with future interviews, and it was really helpful to hear what I did well and could improve on to compare against my own perception of how I did in the interview.

If you read this post, I’d love to know what you thought! Drop me a comment here or on Twitter @chrystalzou.

Detecting Signal Among the Noise

When I tell my friends that I talked to over 50 companies, most of them are understandably shocked. Seeing this number at the end of my process, I’m a little daunted myself, even though I didn’t kick off interview processes with all of them. There are countless companies that are solving meaningful problems, so I needed to figure out which ones I wanted to learn more about. How would I validate that these companies aligned with what I was looking for? In case context is helpful, I wrote about why I started recruiting again in the first place here, which elaborates on my goals.

Building the List

When I started interviewing, I already had a list of companies that I was interested in. “Interested” here means anything from “I ended up on their website and thought it looked cool” to “I knew a friend who worked on a team with open headcount who seemed really happy.” I keep a running Notion page of the companies I think are cool, so when I started recruiting, I already had a pool of close to ~40 places to start with. Not many of them were in the three areas I wanted to work in (climate tech, health tech, and fintech), so I had to do some extra research to put companies specifically aligned with my interests on the list as well. There are a few things I did to source interesting companies:

  1. I turned on the option to signal interest and expose my profile to recruiters and hiring managers on LinkedIn. Prior, I’d been getting a few outreach emails a week about joining a company. Once I did this, the amount of inbound increased to a few emails a day.
  2. I reactivated my profile on Work at a Startup. I was surprised that most people I spoke to didn’t know about this job portal for all YC companies, but it was an underrated resource in my search (full disclosure: I know the person who is building it, and have a lot of respect for him). While YC isn’t the only place to look for promising startups, it’s still where many successful ones have gotten their start. The profile I filled out was a lot more intentional than LinkedIn and prompted some healthy reflection on my part, and it was clear that most people took the time to read through what I was looking for. I had a lot of strong leads from the product and recommend it to a ton of my friends who are looking for new opportunities.
  3. I reached out to a few friends in the investing and startup space to ask if they knew of anything interesting. Any of my friends having confidence in a company is a really strong sign to me.
  4. I looked at companies with founders and investors who’d had a good track record of success. YC, Sequoia, a16z, Greylock, and First Round are a few portfolios I perused to see if anything aligned with my interests, and I looked at individual investors I respected to see what they’d invested in. I was also actively looking for female CTOs and leadership.

Detecting Signals Among Noise

I think what I really want to communicate is that a compelling narrative and a good reputation made a big impact at the beginning of my job search. At this stage, it was the difference between me pursuing or not pursuing a role because I didn’t have firsthand interactions to draw from, and limited time to interview. So while these signals are imperfect, publicly available information was all I had to work with at this point. Tangentially, a recurring theme of interview processes that I noticed was there was no single factor in my job search that could commit me to a job; it had to be a combination of the right things coming together. However, there were some things that could cause me to quickly lose interest, and I imagine some of these are true for when companies do due diligence on candidates too:

  1. Words of warning from anyone I trusted
  2. Employee reviews on Glassdoor and Blind. Blind gets a bad rep (some of which is deserved), but I found it useful to see unfiltered discussion from employees about their own companies and how they felt about the future outlook. It also gave me insight into the types of people who worked at various places (as in, were they assholes in anonymous forums?).
  3. Companies who seemed to be endlessly embroiled in Twitter drama.

On the flip side, here are a few unique things companies did that really piqued my interest in talking to them:

  1. Documented engineering values: As someone who believes in the power of documentation and writing, I really appreciated when an engineering team published their values! I usually ask about these in the interview anyways, so it was great to have a lot of my questions answered up-front.
  2. Public roadmaps: Similar to documented engineering values, some companies published their roadmaps for everyone to see, which I thought was awesome. It gave me a clear sense of how prioritization worked, and how the company viewed transparency.
  3. Transparency around the interview process: Many companies (yes, even tiny startups) have internal documents that detail their interview format, timeline, expectations, and example problems, which is then sent to candidates at the beginning of the process. This is a signal of effective organization and candidate empathy to me, and I wish more companies would share these publicly so others could see good examples of well-run processes.
  4. Examples of team socialization: I really liked seeing pictures and videos of team members and hearing them describe their workplace. It was a nice personal touch to put faces to names in remote times, and to see a slice of different personalities that I might get to work with.

I now had a list of about ~60 or so companies, and ordered them by how much I thought I wanted to work at that place. The guiding question I used to rank companies against each other was “Based on what I know right now, would I be more excited if I woke up tomorrow and worked at company A or company B?” which is a very personal thing! There were a handful of companies where the answer to this question ended up being “Eh, I think I’d want take a few more hours of sleep instead”, and I cut them from the list. At this point, I was back to ~40 companies, but over the course of my recruiting process, I added a few more that reached out and seemed interesting.

Leveraging Warm Intros

I perused LinkedIn to see who I knew at these companies, or if I’d had contact with them in the past. If I didn’t know someone at the company, I found people who knew people who knew someone, and asked them for intros so I could make a direct connection with the company. I also reconnected with recruiters from these places who had emailed me in the past, as a way to get my foot in the door. This brings me to the next point I want to emphasize: there were only 4 companies I cold-applied to, and I didn’t end up interviewing with any of them. All of them responded several weeks later, when I was well into my onsites. Warm intros have always been the most effective way for me to recruit, especially because I neither studied CS, nor went to an Ivy.

What I’d Do Differently Next Time

No process is perfect. Throughout mine, and since it’s concluded, I’ve been reflecting on what I’d do differently in the sourcing stage next time around:

  1. I think I’d be more strict about adhering to my non-negotiables. When I started sourcing, I had written down my non-negotiables, but I was also spoke to companies that didn’t sit exactly at the confluence of these three things (they were usually lacking in one), so I accumulated an unmanageable volume of interviews. I ended up with offers from a few of these places, and realized that the hesitations I’d had from the start never resolved themselves throughout the process because my non-negotiables were simply that: crucial pieces I needed to feel really excited. Someone once told me that I should feel more and more excited as I go through the interview process and gather more signals, and that definitely resonated with me.
  2. I would quit my job and recruit full-time. I didn’t do that this time around because I was scared that I wouldn’t be able to land any offers (hello, imposter syndrome) I felt really excited about, and that I’d be left stressed and jobless, in a poor position to negotiate or push for what I wanted. In addition, I think the context-switching between work and recruiting multiple times a day contributed to the feeling of total burnout by the time I’d finished. On top of that, I didn’t like having to keep my process secret for 3 months so my team wouldn’t find out. Stealth recruiting limited my ability to freely talk about my process and interesting opportunities on public channels like Twitter and LinkedIn.
  3. Next time, I actually don’t plan to cold apply to any companies; it’s never been a tactic that has worked out for me. I think this is one of the core issues that makes designing an effective recruiting process challenging: how can candidates and companies who would be a good fit for each other connect with each other? Unfortunately, I don’t have a great proposal; some of the ones that come to mind all have their own tradeoffs that I think companies need to test out and wrestle with depending on what type of skill they’re looking for.

If you read this post, let me know what you thought on Twitter @chrystalzou, or leave me a note in the comments, especially if you have thoughts about how to improve the discovery process among candidates and companies!

Special thanks to Rochit Gupta and Sharon Xie, who gave me a lot of support in my previous role, and provided feedback on this post 🌱

How I Started Recruiting Again

I’ve been thinking about how I want to go about sharing my most recent recruiting experience, which I’m documenting for two reasons: 1) posterity – it’ll be interesting to look back on this the next time I do recruiting to see how things have changed, and 2) recruiting is this whole mysterious black box, and I think that interviewers and candidates would both benefit from a more transparent process. We can’t really do that unless we’re willing to talk in detail about what happens, so here’s me trying to shed some light onto it. My hope is that someone reading this might learn something that they can apply to their recruiting process, regardless of which side they stand on.

In total, I talked to 52 companies, did 30 technical phone screens, 10 onsites, and received 6 offers. The full process from starting to study to signing an offer was about 3 months. My pass rate was ~98% for recruiter screens, ~70% for phone screens, and ~60% for onsites. It’s worth noting if you’re doing the math yourself, these numbers won’t add up; I dropped out of some processes at each stage for various reasons (more on why and how this in a specific post coming later).

This is also probably a good place to include a disclaimer that I’m not making blanket recommendations to anyone to copy paste my process expecting the same result (I ended with 6 offers, but the process was very taxing to get there). The role that career plays is different for everyone; I’m sharing my personal goals and experience, and there may or may not be stuff that folks find interesting enough to do due diligence and exploration on!

This will be written as a series of blog posts over a few weeks; I tried condensing everything I learned into a Twitter thread, or a single blog post, but found that it was too difficult to condense without omitting things I found important. This post will focus on the first part: namely, how did I know I was ready for something new, and what did I want in my next role?

Assessing my readiness

There are a lot of frameworks I’ve encountered that are supposed to help pinpoint the inflection point at which I feel like I want a change, but the one that has held most effective for me over time is how I viscerally and emotionally feel when I think about the work that I do. In particular, there are three guiding questions I’ve always found to give me clarity as to how ready I feel for a change that I’ve used for most of my career:

  • How do I feel about Mondays? When I find myself looking forward to Mondays, I know that I’m not ready for a change. It means I’m excited about the work that I’m doing and that I’m in a good rhythm of learning and feeling like my contributions matter, and I want to continue to ride out this wave! Of course, a bad week doesn’t mean I kick off a job search. I give the “I wish the weekend was longer” feeling about 2-3 months before I start thinking about something else.
  • How excited am I to refer people to my current company? I care about getting good people into good places, and I actively promote companies and hiring managers who I think would be fantastic to work with. Hopefully, this includes my own workplace! If I find myself in a place where I can’t confidently and excitedly shill for my employer, I interpret that to indicate waning excitement about where I’m at. Similarly, I’m curious about talking to employers who people I trust are excited about! This is less important than how I feel about Mondays because what may be a good fit for me, may not be a good fit for others.
  • How do I feel about the opportunities I have at work now? Put another way, if future prospects don’t work out in a specific way, will I wish I had left sooner? A lot of people stay at companies in hopes of something happening in the future – they may think that they’re close to a promotion, will get an equity refresh with another round raised, their boss will finally see they are a programming god, whatever. My personal philosophy on this is that the future is never guaranteed, so I usually don’t factor in future prospects in this decision unless there’s documented acknowledgement of the promise. In most cases, there are simply too many factors outside of my control to account for. The most common narrative I’ve heard is “I’m going to look for a new opportunity once I’m promoted,” but after the individual’s promotion is thwarted by a reorg, an overhaul of the promotion process, or a change in expectations, the individual is now understandably upset and feels like they were strung along for several months.

Distinguishing the non-negotiables from the nice-to-haves

When it came time to think about what I wanted in my next role, some of this reflection was done from the perspective of “What don’t I think I can get at my current company, even if I were to change teams or projects?” and some of this reflection was done from the perspective “What do I already have that I would never want to let go of?”. When I thought about the times I felt the most energized and empowered in my career, it boiled down to three non-negotiables:

  1. A mission or product that I could feel personally invested in: The world has countless problems to solve, and I still feel optimistic that a lot of these can be helped by software. When I thought back to places where I’d felt the most motivated, places that came to mind were those where I loved the product and felt connected to the mission (this cliche happens to ring true for me). Climate change, the healthcare system, and the financial system were top of mind for me because I see these as the three areas underpinning quality of life outcomes for everyone. I especially wanted to focus on companies who were building for underserved communities traditionally neglected by tech. Broadly speaking, the common theme across my interests has always been wanting to create positive impact for someone else’s life.
  2. Learning and impact opportunities: I wanted to give my intellectual curiosity room to flourish. As someone who has always biased towards action when I see a problem, I was looking for more flexibility and room to take ownership of opportunities to create impact, and to feel that others were energized about making things happen in the same way–even if that meant experimenting outside of our defined responsibilities. I was searching for that energy where people broke down silos and stepped over org lines to move promising ideas forward, or encouraged questioning of existing assumptions in pursuit of better outcomes. Naturally, I gravitated towards a lot of earlier-stage startups as a result of wanting less bureaucracy, although there were some more mature companies that embodied this type of attitude as well.
  3. D&I as an existing and internalized part of the culture, rather than a vanity metric to optimize for at the company level. I was the only non-male engineer on my former team of 12, and our eng org was <10% women. I’m lucky to have worked with really nice people, but I was absolutely yearning for a place where I felt more represented, especially in positions of power. I actively searched for startups with female founders, CTOs, and lots of diverse engineers, and discussed D&I in every interview to gauge how it was embodied by my potential coworkers.

Things that were important to me, but not dealbreakers:

  1. I didn’t want to take more than a 10% pay cut in terms of total comp (salary + equity, even if it was paper money). One of the benefits of working at a startup is that early equity can generate outsized returns if the company ends up being successful, and I was more than willing to trade cash and RSUs for that, but not to an extent where I’d need to drastically compromise my existing financial obligations or quality of life.
  2. Work-life balance: I believe that I operate at my best when I have adequate space away from work, but the balance of time across rest and work is different depending on the type of work I’m doing, and the particular goals at hand. I love losing myself in hard problems, but am easily discouraged when I feel like it doesn’t make an impact, so I was looking for a place that had product-market fit (less thrash), prioritized effectively, and where overwork was an exception rather than the expectation.
  3. Interesting engineering problems: I wanted exposure to fun and complex technical problems that would afford me a big learning curve, but I’m the type of engineer who will gravitate towards work that has the most impact, rather than work that is interesting for the sake of interesting work. Documentation, testing, and direct customer engagement are examples of things I enjoy that don’t fall under the umbrella of ‘gnarly technical problem’ if I know that they can have an outsized impact. I know many other engineers who would qualify this as non-negotiable! We would bring different strengths to the table.
  4. A hub in SF, but with the optionality of working remotely. I miss physical offices for their collaboration and organic socialization, but I will admit that my output is higher when I’m working in isolation at home because I’m free of distractions. More importantly, I’ve always believed that companies should support flexible working arrangements because employees know how they work best (and because this disproportionately benefits URGs and parents).
  5. A business model aligned with the mission: I ideally didn’t want to work at a place that sold user data and ads as the main revenue model, though if I could easily see how much benefit the product created, it could be something that I’d overlook. This is perhaps naive, but I ideally wanted to work someplace where buying and using the product made the world better off.
  6. Coworkers I could see myself becoming friends with: A good portion of my friends are former coworkers, and if I’m going to be spending the majority of my waking hours with people, I want to feel excited about that. Though I wasn’t looking for a family cult feel, I did feel drawn to camaraderie and forming social bonds with colleagues outside of code review.
  7. A well-run interviewing process: The rest of the posts are about this, because I learned two very important things in my interviewing process, especially since I’ve been both an interviewer and a candidate now (I was in the midst of designing a summer intern interview process when I was recruiting, and everything I experienced as a candidate funneled into making it approachable and empathetic for candidates). 1) It takes a lot of thoughtful, thorough, and empathetic work to design a good interview process, and even then, it won’t be perfect. 2) From the candidate side, the process (and in particular, the onsite) is where the best signals reveal themselves for what it would be like to work with this company, and what they care about.

It was a helpful exercise for me to identify what my dealbreakers and nice-to-haves were because they formed some consistent principles for my decision making and allowed me to better compare opportunities against each other. Career decisions are important, and now that I’m almost 30 years old, I don’t want to blindly hop from one place to another without defining my goals up front. In contrast to the last time I recruited for jobs (straight out of a coding bootcamp and haphazardly praying that a few places would see enough in my shitty code to take a risk and pay me to get better), I ideally wanted to choose a place where I could see myself staying for at least full 3-4 years (which feels like a decade in software!), so I promised myself I’d make my search intentional and thorough. Spoiler alert: some of my priorities shifted slightly (nothing drastic) over the course of my interviewing; put another way, values I didn’t know how to weigh came into clearer view.

What to expect in coming posts

Here’s what you can expect in upcoming posts if you’re interested in reading about my interviewing experience! I’ll be including resources that I found helpful, as well some thoughts on what I’d do differently for each of these. It was particularly interesting being on the candidate side because I got to see a lot of wonderful, unique ways some companies ran their processes, and I also felt some unexpected pain points. I plan to take both of those in stride to immediately improve the process at my next company (although, perhaps unsurprisingly, one of the reasons I chose them was because they ran one of the most stellar processes)

I’m going to try to hold myself accountable for writing at least one post a week, and I’d love to know what you found interesting or bland! If you catch me slacking or simply want to let me know what you thought, you can find me on Twitter @chrystalzou.

Thank you to Rochit Gupta, Cissy Hu, Katy Culver, and Girish Gupta for your feedback on the first draft of this post (in addition to your endless support through my process) 🙂

Overcoming Imposter Syndrome: Symptoms and Cures From a 0.1x Engineer

It’s been just a little over two years since I decided to make a serious commitment to the journey of programming. I wanted to document as much as I remember of the first hard parts of that journey because I don’t want to forget how unfeasible the idea of becoming an engineer was at that point. Now that I am one, it feels like it takes more effort to remember the challenges of setting up my environment, learning git, and understanding why time-space complexity mattered, because these are things that I now work with day to day. I’m sure that, as I gain more programming experience, the idea of not understanding fundamental programming will become more and more foreign to me.

Why is it important for me to recall what that frustration felt like in the early days of my programming journey? For as long as I’ve started programming, I’ve always felt a sense of imposter syndrome. That’s not new, and as I began interacting with more people and reading more developer blogs, I came to realize that everyone experiences imposter syndrome to some extent, from CS PhD students, to distinguished architects who have spent decades in the software industry. For me, imposter syndrome felt like it prevented me from learning what I wanted to learn, and building what I wanted to build. It made me fearful of asking questions, because asking questions meant I didn’t know the answer, and had failed in my attempts at trying to find it. Sometimes, my imposter syndrome would consume an entire day of development. Instead of asking my question, I’d peruse forums and documentation, faulting myself for not knowing how to solve a seemingly trivial problem. I was constantly comparing myself to other engineers, impressed with just about everything they did, while minimizing my own accomplishments, and did not sleep through several nights, anxious of being found out that I, in fact, could not build anything worthy of shipping. In fact, when I won a hackathon for the “Most Shippable” feature category, I chalked it up to being on a team with 3 other incredible engineers, and still mostly believe that they contributed more than I did to that project. When my manager gave me my annual performance review, I was mentally prepared for a demotion, or to be let go; when I was given a raise in salary and equity, I felt stressed instead of excited, because I felt like I’d have to bullshit twice as hard to keep up a convincing image of myself as competent. Imposter syndrome is not a self-pitying experience. I deeply believed I was incompetent at programming because I was not intelligent enough. Such are the effects of an inaccurate and unfounded assumption that engineering is a discipline that operates as a pure meritocracy.

I’m not immune to imposter syndrome today, but compared to how much imposter syndrome used to affect me, it’s much more manageable. Documenting overwhelming experiences brings me back to a place where I can better empathize with people who do feel that way. Now that I know the answer to many of the issues I encountered at the start of my journey, I also catch myself slipping into a mindset of thinking certain tasks are simple, forgetting my own struggle to understand the fundamentals as recently as a few years ago. The most important thing I learned brought about significant shifts in the way I dealt with my own imposter syndrome:

Learning How to Ask Thoughtful Questions

This is the single most impactful thing I learned to do, that helped me feel more at ease with imposter syndrome and its effects on me. I was lucky to have a mentor who gave me a good set of guidelines to asking thoughtful questions to other engineers, that I still use to this day when I’ve failed to find an answer on my own:

  1. Peruse related documentation and parts of the codebase. This one seems obvious, but it’s embedded in the assumption that agreements and truths are also well-documented somewhere others can reference, and in language they can understand. A friend of mine once told me he believed that it’s the authoring engineer’s responsibility to make sure their code and docs are understandable. If they aren’t, you should feel totally okay seeking clarification about anything unclear or ambiguous. I give myself a 30-minute time limit to hunt through docs, code, and Google before asking any questions, just to make sure the obvious places have been searched.
  2. If the answer hasn’t been found, or is unclear, it’s time to ask clarifying questions. I ask my questions to a team Slack or specific channel for that tool / technology, because if I’m wondering about this, it’s likely others have, or will in the future. Asking questions in public forums, daunting as it may seem, benefits many people besides yourself. I almost always ask my questions in the form of: “I’m trying to accomplish x. I’ve looked at the README, the docs, and wiki page y. I expect output z, but I’m getting this error when run this series of commands instead”, followed by any relevant code snippets and error logging. The more detailed you can be, the better. As someone who has been the asker and answerer of questions now, I can confidently say that an answer is found much more quickly if more details are provided.

About 90% of the time, someone will respond with some thoughtful clarifying questions (e.g. what version of Postgres are you running?) and we figure out the issue. Sometimes, we identify it’s a bug, or that something was missing from the documentation. Either way, this approach demonstrates 3 things:

  1. You made an effort to solve the problem on your own first.
  2. You communicate about problems and the attempted solutions clearly.
  3. You share your findings about solutions with others who may be impacted.

Edit 5/14/20:

It’d be misleading and inaccurate to say that I made progress on coping with imposter syndrome by myself, but I wanted to emphasize learning how to ask thoughtful questions because it’s the one that most people can do without relying on factors outside of their control, which makes it the most empowering and beneficial. Here are two other factors that had major impact on my ability to overcome imposter syndrome:

A Psychologically Safe Culture

I hesitated about including this, because the word “psychological safety” has been thrown around so often in the tech industry that I feel like it’s turned into more of a buzzword than something people can actually understand, so I’ll do my best to start with my own definition of it. To me, psychological safety means feeling like I will not be rebuked in any way for being honest. In the context of asking questions, rebukes can take many implicit forms; anything from thinking of the asker as less competent, to outright patronization of their abilities in front of others. The reason psychological safety is important when it comes to imposter syndrome, is because the very definition of imposter syndrome includes psychological danger: a fear of being seen or treated as incompetent.

I got extremely lucky at work, and with my teammates. People say I totally drink the kool-aid for my team at work, but I’ve held enough jobs, in enough roles, to realize that the team I got to work on was anomalous in its emphasis on balance, culture, and openness. At the time, I was the only junior engineer on a team of senior and principal engineers, and each one of them demonstrated infinite encouragement and patience towards me when I couldn’t figure something out. Small reassurances like “Don’t worry, this is hard stuff!”, “I don’t know”, or “It happens,” when a particularly silly mistake was discovered (like the time I wondered why a commented-out variable was returning undefined, oops) added up over time and reminded me that no single engineer will have the answers to everything. So often, I tend to place those I admire on pedestals, and internalizing the fact that brilliant engineers are fallible humans also helped me trust in my own capabilities a little more.

It’s really unfortunate that this type of culture seems to be a rarity amongst engineering teams, and I have a lot to say about how lack of it also disproportionately affects underrepresented groups, who already struggle more with combating imposter syndrome’s effects. But the good thing is that, if you’re an engineer who is more senior, little gestures like the examples I mentioned above are simple ways to reinforce psychological safety within your team.

Mentors at Work

The last thing I’ll mention that was hugely beneficial for my programming confidence are my mentors. For as long as I can remember, major changes in my career have always been driven by the confidence a trusted mentor has given me, including deciding to become an engineer. I have 2 mentors at work, and if nothing else, my mentors provide me with a psychologically safe outlet to express concerns, run ideas by them, or ask for feedback in a focused way. Even though my manager and I have a great relationship at work, talking to someone who doesn’t influence my salary and career development can take away the pressure I feel with admitting shortcomings or fear. I run things I feel unsure about by my mentors, such as “What do you think of the way I worded this concern?”, to “Do you think my understanding of this problem is correct?”, to “Can you review this MR or this design document?”

Everyone’s relationship with their mentor is different, but I personally rely on mine to be my sounding boards and advisors when it comes to career development or learning a new skill. I don’t have recurring meetings with my mentors; the relationship is casual, and I message or meet with them when I have a specific topic in mind. It’s also important to remember that they, like everyone else, don’t have the answers to everything. One of my mentors shared with me that he experiences imposter syndrome at least 3 times a week! The dynamic I have with them is slightly more involved than I have with peers, in the sense that they embody skills or abilities I’d like to have in a few years. Getting their perspective on what they would do in a particular situation I’m facing helps provide me with a starting point.

Imposter syndrome is something I know I’ll never fully conquer, and if I’m totally honest, I’m not sure I want to. While it can feel discouraging at times, recognizing that I have room to grow holds myself accountable for making those improvements, and aspiring to higher standards for myself is the kind of mindset I want to embody now, and in the future. Realizing that I was fortunate to have resources at my disposal was great, but realizing that I can accomplish most of the work to turn it into a positive behavior reinforcement was even better.