If you're in tech, and especially if you're an engineer, you've probably heard of the term Imposter Syndrome. I've experienced it in large doses, and still do sometimes.
I was a nondescript CS major in university. I wasn't failing classes, but I wasn't doing particularly well either. Mostly a mix of Bs and Cs. I made an effort to understand course material, but I didn't attempt to go beyond what was required. My professors probably had no idea who I was. There were certain special classes that I attempted to get into - I would describe them as 'elite' software engineering classes. I failed multiple times to. From my understanding, it was a mixture of a lack of good grades and a lack of a sufficiently impressive portfolio. This was even after I did a web development internship.
On the career side, I was pretty average as well. I did 2 internships at small startups. Meanwhile, the high-achieving students had multiple internships at Bay Area tech companies. I did apply for jobs in the Bay Area, but was unable to pass the screening tests. My LeetCode game was, again, average; I could usually solve Medium questions after a fair amount of time, but not Hard. During my internships, I tried working on problems after work, but found myself burning out after a while. So I suppose you could say I didn't want the Bay Area job badly enough to put in hundreds of applications or spend months working on LeetCode problems.
I eventually got a job at a local startup in 2017, earning somewhat below-average pay. I saw my friends working at big tech companies both locally and abroad. I was happy for their successes and never held it against them; after all, they had worked hard in school and outside, and they were being rewarded. However, I did feel a certain wistfulness when I saw what my life could have been, if only I had been smarter, more hardworking, or both.I would describe my CS and software engineering knowledge as 'adequate'. I know things like how to use version control, or what kind of data structure you should use in a given situation. I know how to keep my code neat. But my knowledge is mainly centered around what I would use on a day-to-day basis. I don't know the details of language implementations, for example, because I'd rather just use the language features without worrying about what goes on under the hood. I'm not the kind of person who gets excited by a new, shiny technology, unless I can see how it can be used.
Fast-forward to today, and it turns out that I'm now working at a big tech company myself. I work on projects that have a large impact, and I've always gotten positive comments about my output. It's a far cry from my university days when I thought I would spend my days working on small applications that people might not even use.
At my first job, I was at a small startup, which the usual chaos and lack of manpower that entails. There were 3 on-site developers: 1 senior developer who doubled as CTO, 1 mobile developer, and me. The rest of the work was outsourced. In my first month, I was told I would be working on rewriting the frontend of one of our applications in a framework I'd never used before (Angular 2), and I would be the one doing most of the work. That's way more responsibility than a new grad would typically be given. But it was a fantastic learning opportunity for that reason. I did everything from writing a picture slider to database design. Eventually when both the senior developer and mobile developer left, I took on tasks like handling deployments, debugging build processes, and code reviews. All in the span of 1 year. It was stressful at times for sure, but it gave me cross-domain knowledge that I would likely wouldn't have if I had joined a big, stable company right away. And the benefit came when I interviewed with Mercari and was able to demonstrate my experience. I started off not knowing how to do any of those things, but hours of Stack Overflow and debugging eventually paid off. I remember being overwhelmed by XCode when I first opened it (and I still hate it) to do iOS builds and deployments. Everything was non-intuitive, and trying to do the simplest thing required a ton of Googling. But eventually I learned and it became easier. That's how it goes for everything. Continuing to attack a problem when it seems too difficult to solve is important, because everyone encounters that, no matter how knowledgeable they are.
I also want to share something that an engineering manager at Mercari told me, as much as it might sound like a cliche. I was having a 1 on 1 with him, telling him about the things I wrote above: that I wasn't as skilled of an engineer as my peers who got impressive internships. He asked me what I thought the most important quality of an engineer was. I listed things like being able to break a problem down into small components, or using good software engineering practices. His answer was empathy. Understanding the needs of your users. Because there's no point in building something technically impressive if nobody wants to use it (looking at you, Google). And he told me he wanted me to constantly keep in mind why I was doing something, so that it would inform my decisions.
If you're a fellow "average" engineer or university student and you've been reading until this point, I want you to know that you are certainly not alone. There are dozens of us - dozens! And that while technical skill is certainly important for, well, doing your job, it is certainly not the be-all and end-all for an engineer. Because as engineers, at the end of the day, we make things for people, so we need to understand people. And we work with people, so being able to collaborate and communicate with your fellow engineers, your stakeholders and your executives is, I would argue, even more important than technical skill. Ask an engineer, and they'd probably say that they prefer to work with someone of average skill and who is easy to talk to, than a genius who is aloof and condescending. The latter hurts team productivity; there's a great article on this topic. That's why companies do culture fit tests. Though they sometimes have unintended consequences, but that's a topic for another time.
Thank you for reading, and I hope you found this useful in some way.