Imposter Syndrome Series Part 2: I don't know enough

I have friends who are great software engineers. Eager to learn with amazing social skills and business acumen. There are definitely plenty of companies out there who would be LUCKY to have them on one of their tech teams.

But they don’t want to apply because they don’t feel like they know enough. They feel like they need to learn React BEFORE they apply. They feel like they need to be able to reverse a Linked List BEFORE they apply.

On the one hand, I think they should just go for it and find a team that values the skills they do have and grow on the job.

On the other hand, I feel their pain—and this coming from someone who has applied and faced a lot of rejection.

I’m about to get pretty vulnerable here.

The past 2 years, I’ve had been through about 50 interview processes for software engineering jobs. I’ve been rejected for many reasons:

“You don’t have strong enough opinions about E2E vs Integration Testing?”

“You don’t have experience with animation in CSS?”

“You don’t have experience with system design?”

“Why did your last company use GraphQL and not REST APIs? You don’t know?”

“You don’t know Java?”

“You have 4.5 years of experience and not 5?”

“What’s the difference between props and state? You can’t clearly explain this?”

“You don’t know how to use recursion to flatten an array?”

“You haven’t owned a product from end to end, specifically at Teachers Pay Teachers?”

“You weren’t able to fetch data from our API and make a beautiful UI in 4 hours?”

“So this time you were able to fetch data from our API but you weren’t able to make a beautiful UI in 4 hours?”

“You’ve used TypeScript? What’s the difference between an interface and a type? Oh..you don’t know?”

When I got these rejections, it felt so devastating. Like…I’m not good enough.

I think…”If only I knew system design.” “If only I had practiced recursion a little more.”

But some things have happened recently that have made me change my mind about how these rejections make me feel.

🧘🏾‍♀️ One: I did a stretch on the Peloton app that reminded me—my worth isn’t tied to some company’s yes or no.
💬 Two: I had conversations with engineers who changed my entire outlook.

Keep reading to see what I learned.

Not every engineer knows all you need to know. Not even seniors.

So…like I said before, sometimes not knowing enough makes me feel like I’m not good enough. So I assume that the software engineers who are “good enough” (i.e. have the jobs I want or at least think I want) do have this knowledge that I have been rejected for not having.

I’m learning this isn’t always the case.

I’ve had some coffee chats with senior engineers recently. I sometimes share my struggles with the job search. Remember how I said, “If only I could do more Leetcode problems”?

Well some of these engineers, who are seniors and have managed to keep their jobs in the midst of the recession (or whatever we’re going through is called), have said:

• “I don’t know how to do Leetcode problems. I avoid companies who make this part of their selection process.”

• “I don’t apply to companies that give Leetcode problems or even make you do 4-hour take-homes.”

• “I prefer to ONLY do system design interviews” (which intimidates me even more than Leetcode if I’m honest)

• “If a company is making you do system design for a senior role makes it sound like they want a staff engineer for a senior engineer price.”

And some of these humans are FAANG engineers!

I have also been listening to a podcast about system design. The host has been a programmer for 10 years and a senior software engineer for 5 of those years. He said that system design has always been a challenge for him. In the past 10 years, he hasn’t had to design any new systems because the systems he worked on were already designed and built, so all he had to do was build new features.

WOW!! So it turns out, I’m not bad for only building features and not building a product from end to end at Teachers Pay Teachers? (Although I am doing that right now)

I had an interview for a Senior UI engineering role where I had to live code building a React application. The prompt asked me to fetch data from an API and build features in React. I was able to do this (yay!) but didn’t make it to the next round. I shared this in a coffee chat and an engineer said “I’m surprised they didn’t ask you to BUILD an API.”

What?? I asked “Isn’t that more of a backend thing?”

And he said “But the frontend communicates with the backend.”

I said “That’s what was happened in this live interview.”

He said “But a senior engineer should be able to do system design.”

I told him “Not every company is Amazon.”

He said “Well…with startups you should be able to do system design even more.”

Yeah…but this company isn’t a startup. They’ve been around for 20 years. (Why do people think the only tech teams you can work with are startups or FAANG?)

My point is that every engineering team has different needs. And as a software engineer, the skills you have right now might be enough for at least one.

You might not know some of these things now, but you might in the future, and that future might not be that far away

So as I said in #1, I have been listening to a podcast on System Design. System Design was something I have tried to learn about several times through Grokking the System Design interview on Educative or freeCodeCamp’s Youtube video on System Design or the System Design Primer with Donne Martin.

With these, the concepts didn’t really stick or sometimes I just felt overwhelmed with how much information there was to learn.

After one episode (and review) of Learn System Design with Ben Kitchell, concepts that previously intimidated me or that didn’t stick before are suddenly sticking.

I now understand vertical and horizontal scaling, the trade-offs of both, and why a tech team might choose one over the other. I also understand CAP theorem! I plan to write a blog post on these topics in pretty soon!

And I still have 14 more episodes to go and I’m confident I will learn even more!

My point is really that knowledge isn’t static. Just because you don’t know something that a tech team needs and get rejected because of that lack of knowledge, doesn’t mean that you will be in the dark forever! Especially if you seek that information out. And in the Information Age (are we still in the information age) that knowledge is more accessible than ever.

Think about the stuff you didn’t know at one time but now do.

If you are reading this blog post:

• You learned English! There was a time you didn’t know English.

• You learned to read! There was a time you didn’t know how to read.

• You learned to use a computer!

If you are reading this blog post now, I’m confident you would be able to learn any skill or knowledge set that you feel is holding you back or giving you imposter syndrome. (That is unless you can’t form new memories which in that case, you won’t remember that I said this).

Everything that allowed you to read this post was not an innate trait. You had to learn that at one point.

I didn’t know a lot of things I needed to know to get a job offer or get to the next stage in an interview. But guess what? I became obsessed with them and figured them out.

Out of the 12 knowledge gaps I’ve mentioned above, I’ve been able to fill at least 4. That’s ⅓ and the number is growing!

I’ve written blog posts on 2. I plan to write blog posts on at least 2 others and I’ve even streamed myself flattening an array on Twitch 2-3 times.

For more tips on learning, check out Barbara Oakley’s class on Coursera, “Learn How to Learn.”

No software engineer knows all there is to know about software engineering

I have a freelance client who is a nurse practitioner. I talked to her about impostor syndrome. She said “I’ve heard of it, but I don’t really get it.” She understands it intellectually. However, apparently, she doesn’t have impostor syndrome at all and has full confidence in her abilities as a medical provider.

I found that so fascinating. We’re both in industries that require a huge knowledge base, but in my field, pretty much every software engineer I meet has impostor syndrome. I don’t think I’ve met one who doesn’t.

My theory on the difference is that with medicine, while there is a lot to learn, once you learn a certain body of knowledge, there’s only so much that could change in the next year or two. Medical providers need continuing education. They do need to take exams. But I want to say it’s more standardized. Software engineers have to take it upon ourselves to stay updated on the latest and greatest or learn by trial and error.

With the web, technology changes fast, and so do the learning demands.

React has had 18 versions since its inception in 2013. Many frontend libraries are constantly changing in the same way. And don’t get me started on Frameworks. (At one point I didn’t even know there was a difference between frameworks and libraries but look at me now!)

As a software engineer, there will never be a point where you say “I’ve learned all I need to know and don’t need to learn anything else for another 5 years.”

Well. You could say that. But imagine if someone learned Fortran 50 years ago and had the same attitude (and also lived and worked eternally). They wouldn’t be up-to-date on the latest tech. In fact they would have been way behind 30-40 years ago.

So we chase knowledge endlessly—often measuring our worth by what we don’t know yet.

But here’s the truth:

No software engineer knows everything.
You don’t need to know everything.
You just need to keep learning.

And if you’re already doing that (which you probably are, just by reading this), you’re already on your way.

---

Join our learning community at #100Devs, or reach out if you need accountability.

Let’s unlearn the tech hierarchy brainwashing together.