Welcome to day two of season one finale week. It's episode 41 of the web joy podcast. I'm your host Eddie. And in this podcast, we interview guests about their origin story. And what makes them excited and joyful to be part of the tech community. I hope you enjoy today's episode an unpopular view on imposter syndrome with Curtis items. Welcome to another episode of Web Joy. I'm excited to have Curtis today here with us. Curtis, say hi to everyone listening.
Hey, how's it going? It's a pleasure to be on the podcast, Eddie. Thanks a lot for having me.
My pleasure. So everyone can kind of get to know you. Let's start off and just say, Hey, who are you? What do you do? Where do you work? Just kind of a, a brief intro of who you
are. Sure. Yeah. So I'm Curtis. I'm a software engineer. Near Washington DC in the United States, and I am a freelancer. Prior to freelancing, I started at Amazon Web Services, so I worked on a variety of services and products at a w s, both internal as well as external. And recently left my full-time commitment there, uh, to do freelancing. And this gave me a little bit more control over my time. As well as my project choices. So I've been working with Gum Road a little bit asynchronously.
I hope we're good to talk about that later. And I also launched my first video course earlier this year, which I'm pretty excited about. Um, it's called Master the Code Review. And you know, in this, in this spirit of like building in public and transparency, I like to share some numbers around it.
Over like 900 students have decided to take the course, and like 30 organizations have purchased the team license, and a few companies have actually added it to their new hire, like internal training, which I'm pretty pleased about. Um, it, it went better than I could have imagined. I'm currently writing a book on the same subject of code reviews as well.
It's cool to be able to sell something to individuals, but when you were able to sell something to a team, right, to a company like that really must feel, feel good. You know what I mean? Like you kind of just nailed
it. Yeah, absolutely. Yeah. When I was building, cause I was talking about it a lot on my social medias when I was building it and I had some people reach out to me and say, Hey, I might wanna purchase this for my organization or for my team. So I decided to make a, a team package option as well. Yeah, it's been good and I'm, that's why I'm excited to really get into this book and start writing it as, I love
that different people have different ways of learning, so having different modes of communicating those same truths is, is really exciting.
Yes, absolutely. Yep. How
did you kind of get into this, right? Like what. Kind of prompted you to say, Hey, I want to get into tech, I want a program start at Amazon. So like how did, yeah. That all kind of get started
for you. So as far as my journey into Tech Goes journey into software engineering, it's pretty, it was kind of straightforward. Wasn't really a career changer or anything like that. I studied computer engineering back in high school. I actually took some coding courses. We had some courses in. Had a really good teacher that taught it really well in high school. And when I got to university, I studied computer engineering.
And so computer engineering is a little bit different from computer science in the sense that it focuses on the integration of hardware and software rather than strictly large scale software development or computer science. So I worked a lot with, um, hardware description languages, like fair log, uh, some embedded systems work as well. So writing code that would. Used on physical devices in the physical world, and it taught me a lot.
But in the end, I ended up getting an internship with Amazon as a software engineer. And then after the internship I was hired full-time at Amazon as a software development engineer. So I stopped doing the hardware stuff and just completely shifted O over to the software side. Yeah, so that's my story.
Nice. Well, I've been following you on Twitter for a little while now, and I, I read an blog post that you talked about how like started at Amazon, but you really should have never gotten that job, and that's so intriguing to me. So I thought, you know, let's unpack that a little bit. How did that go about? How did you get that job? Why did you feel like you shouldn't have gotten that job? What did that all kind of look. Yeah,
so you're referring to an article I wrote on My Medium, which was about two years ago, and it was recently discovered probably a month ago. It was discovered by a business insider, and so I worked with Business Insider to get that republished on their platform to reach a wider variety of readers. And yeah, the title is, it was a very eye-catching, it was my first ever article actually, so like nice, very.
Click baby, like over the top like headline because I didn't, I had no idea if anybody was gonna read this article, so it was like Amazon shouldn't have hired. Like, and I had like in my medium article I had in the quiet place, there's like a, an infamous scene where he's like, puts his finger over his mouth like, shh, like it's a secret or something, because I had no idea if anybody was gonna read this.
And ended up like, I think over a hundred thousand people have like read it at the time, which was way more than I ever imagined. So I learned a little bit about marketing that day. , but . But yeah, so that art, in that article, I kind of describe how. My perspective around that, like why I shouldn't have gotten the job at Amazon. So any software engineer who's prepared for a FANG interview, including Amazon, knows that you have to study lead code questions, right?
You have to go out, basically go on lead code, and for months and months you have to practice those coding challenges, those coding problems. And you need to study like da, the, the complex data structures, the heaps and the tries and the, and the graphs. And you have to be able to know and analyze some algorithms in time and space complexity. Now, a lot of these core concepts of data structures and algorithms, they're taught in computer science curriculums.
And as I explained before, my background was in computer engineering. It was a very good curriculum and it taught me to think like an engineer. It taught me to solve ambiguous problems, but it didn't have those core classes just because it wasn't part of the computer engineering curriculum. So I kind of went into the interview for the internship. Um, this was back in 2014, went into the interview and they were doing on-campus interviews.
I'm not sure if they do that now, but I. I got a couple of technical questions, which weren't typical of what you would see nowadays on an S D E intern or s d one interview, and I got one on like bit manipulation. I told them my background, so they gave me some bit manipulation question. They asked me a couple of questions on hash maps. And then the rest of it was like leadership skills, leadership, leadership, leadership.
And I did have some of those solid leadership skills and the technical questions I was able to answer as well. So I landed the internship and then over the course of the internship I was developing a Rub on Rails project. And then I did well on the project and I was able to earn an s d e one full-time offer. Now, I did earn the offer through the internship. I did do well. I mean, once you have the job, once you're in the door, it's.
More so within your control in terms of, okay, I can put in more hours, or I can take the extra time to learn something. I basically worked my ass off during that internship and got the full-time offer.
The reason why I say Amazon shouldn't have hired me is because objectively, if I were to take the SD one interview, like while I was trying out for that internship, or even after the internship, even after I graduated, if I had taken the SD one, I. There's no chance I would've passed that thing objectively. There's no, there's no way. And this is confirmed by my experience as an interviewer. I spent six years at Amazon.
I interviewed many candidates, um, just having a deep understanding of the interview process as well. I definitely would not have passed that interview and gotten into Amazon, so that's why it says Amazon shouldn't have hired me at the beginning. I love that
because I think there's something to be learned there, right? Which is oftentimes it's easier to move upward in an organization than to go out and get an organization to hire you from scratch, right? Because you had gotten in the door as an intern that allowed you to show. What you were doing as proof that you could be a software engineer at Amazon.
Whereas if you hadn't done that internship and you just finished school and then been like, all right, I'm gonna get my first job, time to go for Amazon, you would've had harder questions cuz they would've expected you as an external hire to be at a higher level. Like they, so I think that's an awesome thing for people to keep in mind when they're thinking about how they want to go about their career and knowing like, hey, if you can get in the door some.
Through an easier doorway and then show proof, like on the job you can move up where you might not have gotten in the door just trying to go for that higher level position.
Yes, I think there's something to be said there. Definitely. I would like to emphasize, you know, that internship was definitely not like an easy thing. I would say it's different kind of skillset. Some people are really good at lead code questions, but, but you know, they're not very good at some of the soft skills and leadership skills that it takes to succeed on the job. It's kind of a trade off, right?
So in my case, wasn't very good at lead code, but was very good on on other, on-the-job skills and other people's case. Maybe they're good at lead code, but they're not good at those on-the-job skills. So that internship was actually very challenging and over the years I've mentored several. Engineering interns as well, so I know how about the structure and how challenging it can be, and so not everybody makes it out of that internship with a full-time offer, as you can imagine.
I'm not sure what the percentage is. I, I'm not gonna throw out a number because it's probably changing all the time. I was talking about the differences between interviewing in tech as well as on the job skills, and I think my case brings up a broader discussion about interviewing. The tech industry as a whole has this whole lead code process, and they measure these specific skills in a live coding interview kind of way. Like many companies do this.
It's not just Amazon, you know, it's Google, it's meta, it's all kinds of different companies. Right? And I think it brings up a broader discussion of, is that the right way to be interviewing people? I have some personal opinions about like what we could do, but everybody does. I think everybody at some level has an opinion on how we should be measuring candidates for these roles. There's been some changes, like I think there have been.
Different companies that are starting a trend of like avoiding those kinds of interviews. Maybe going away from the whiteboard interviews, maybe going into like poll request type of interviewing, behavioral type of interviewing, those kinds of things. It's a good,
a good point, right? And it kind of creates two call outs. Like one, if you're out there and you're interviewing and you feel like you're not passing interviews like that doesn't. You would be bad at the job. That just means you're having challenges with the interview process. So like don't be discouraged by that.
You may just need to hone up some of the interviewing skills or look for companies that have different interview processes that are more of what you would do in your day job as companies. I totally agree with you. I think we need to do better. There's different levels of like leak code where it's like a lot of what you do doesn't actually happen in your day.
and then you've got, I would put like Glassdoor in this category, which is like, okay, you still do live coding, but it's more what you would do in the day job. And so like for example, as a front end engineer, you're gonna mess with like grabbing data from APIs and displaying it on screen during a 45 minute session. And it's like, well, you still have to code in front of someone, but you're doing stuff that you would normally do in the day job.
It's, it's not something you have to specially study for. And then, yeah, I think different types of things. Pull requests and like how do people work in teams? Like finding ways to dig into that stuff. So vital to how we work. I I love that. Yes, absolutely. Well, cool. Um, you know, you were at Amazon and I know we deal with imposter syndrome a lot in kind of the tech industry, right? Did you encounter that there? , how did that feel working kind of among Amazon?
Yeah, definitely. I think, um, in my case, and I kind of talk about this a little bit into piece as well, in my case, I have kind of an unpopular opinion when it comes to like imposter syndrome, So I, I typically like to drop the, the syndrome part of it, right? I like to look at it as, okay, maybe like I'm an actual imposter and in, like in my case, I was objectively coming into Amazon without some skills. Every SD one gets hired having, right.
So I'm like, oh, I'm the only one that doesn't have these skills. So when I, Dr. And for me, when I was able to drop the syndrome part out of it, to say, okay, maybe I really don't have these skills, like I have to kind of objectively look at myself and reflect and say, okay, I am where I am. I have the skills that I have, I have the background that I have. Maybe I'm at some kind of.
Disadvantages relative to my other peers, but I can take where I am and then recognize what I have to do to acquire those skills. And really, I think that's what it's all about. Just having the self-awareness to say, Hey, I don't know this right now, but I'm gonna go out and learn that. Or, I am performing this way right now, but I'm gonna take the feedback from my peers and my managers and, and that sort of thing.
And, um, take that feedback in stride and improve any way that I can because I wanna stay. Right. And I wanna ex and I want to excel here. Um, so that's kind of the attitude I took in that situation.
So you worked at Amazon for six years, then you moved on to freelancing. Obviously you're enjoying being a software engineer. Kind of what is it that keeps you excited and interested working in
this field? Yeah, it's a good question. Software engineering, back when I was in high school and going up through college, I really liked the problem solving aspect of it and the creative problem solving aspect of it. So no one developer or no two developers come to the same solution, right? Everyone has their own unique way to solve a problem and just.
Looking at the creative process, the logically creative process that each developer goes through, and solving these different problems is very interesting to me. And the problems get even more and more interesting as you get better, right? You have, at first, you're thinking about edge cases and corner cases and those kinds of things. And then as you level up in tech, you start thinking about more of the business side of things, right? Um, you.
Noticing gaps in like a business, instant business requirements or maybe something that they say they want, like maybe the customer says they want one thing, and then you have to kind of fill in the gap for them saying, Hey, but what about this situation? And those problems become much more collaborative, collaborative between all kinds of different people, like engineers, product managers, UX designers, and it becomes, you know, the, the problems get even more and more interesting.
And I like collaborating with humans as well. Like, uh, I think in the early stages of software engineering, you're pretty much always coding, but in the latest stages, you're al you're always collaborating with other people and it's more about precise communication, whether that's verbal, uh, non-verbal or written. No,
that's, that's fun. Like you said, as as the journey goes on, you get to do different things and you get these different experiences and it is great working, working with people as well as code. One of the things that we like to talk about in this podcast is things that bring us joy and. I just wanna say, hey, what's something that brings you joy? Maybe something you've been doing or a way you've been working
for you? So when I became a freelancer, one of my main clients has been Gum Road. Um, and so Gum Road is put simply, it's a website, gum road.com, where you as a creator can. Log on and upload files and sell them as a product. And that's kind of a simplistic definition. You can sell digital files like eBooks or videos, or you can sell physical items as well if you have, have your own way to ship customers items. But very simple website. I say that in a good way.
I think simplicity is beautiful, especially when it comes to products and engineering. But what's interesting about Gum Road and working with them is it's completely asynchronous. So, I think in the past year that I've been working with them, I've only had four meetings the whole time, which is pretty unheard of. Yeah. . Yeah. So it's, it very much resembles working on an open, kind of like an open source project. We have like three modes of communication.
There's like notion, GitHub, and um, slack, and that's pretty much it. Um, if you're a designer, you have Figma as. So it's the, the whole thing is completely asynchronous. You know, you dive into the notion and you figure out, okay, what's the highest priority task or project that needs to be worked on? And you kind of like, as an engineer, I have to be able to like scope it out, break down the tasks of what we need to do, and then. Involve whoever I need to evolve.
Maybe I have to reach out to a product manager to clarify something, or maybe I have to reach out to a designer to get something designed, and then I'm diving into the code and pretty much shipping, authoring, and reviewing GitHub poll request to, to ship to this, this product. So it's, it's very interesting. Very interesting work life, uh, situation I have. Nice,
I think. What do you find challenging about that? Right. Obviously there's a lot of upsides for asynchronous, right? You get to work on your own schedule and you know, get to zoom in, but yeah. What kind of challenges have you run into?
A lot of times verbally, conversations can be hashed out a lot quickly. More quickly, and it's tougher to ha to like write things down sometimes, like if you have a. And sometimes the pro, the problems that you're solving can get very complex, especially in software engineering, and the communication has to be very precise.
So sometimes writing out maybe on a poll request, giving enough context or maybe you're having a slack discussion about some something that needs to be debugged and you have to have very precise. Communication around everything, and that's difficult. I got into writing, especially writing on the internet probably a couple years ago, and that kind of opened my eyes to just how difficult writing can be.
Most of the time when you write something, the first pass through, it's not going to be correct or precise or you're gonna have to make edits. And so if you're, if all of your communication is writing, you have to write and then you have to go back and revise and revise and revise and then finally send. So I'd say that's been challenging, but it's. Influenced a little bit of my growth as well. I think I've become a better writer because of this, this process.
Yeah, that's awesome because like you said, while it is challenging, I think it also helps shed light when you're having to analyze it, right? And yes, oftentimes when we're in a meeting, we can kind of spit things out that we only half know or half understand. And it's like when you're writing and you're making sure it's right and clear, it makes you question your own assumptions. So that definitely seems like something that.
Really help you understand things and, and if someone is like, wait, what did we say? Like, it's not lost in a meeting somewhere. Like it's actually written down and they can
go back and read it. Yes, absolutely. I, and this also reminds me when I was at Amazon, Amazon has a very strong writing culture. So they have like a no PowerPoint rule. Like if you have an idea or something that you're proposing to a group of people, you're not allowed to use PowerPoint. You have to write a document. It has to be a one pager or a six page. Because writing forces cla that clarity of thought.
You know, you cannot BS your way through a written documents, but you can BS your way through a PowerPoint presentation or something like that. . Yeah,
absolutely. Great. As we, you know, wrap up here, one of the things we always like to do is just as a community, we love to support each other and just wanted to know, is there anything that you're involved in or anything you've worked on that you'd like? Share with the community that they, they might find helpful and want to check out.
I mentioned earlier this year, I launched my first video course. It's called Master the Code Review. I think code review is a critical, important subject for software engineers, software developers. Almost every software developer does this on a daily basis that very few people are talking about it. And so that's what motivated me to make this course. Um, that, and, you know, my particular struggles with code reviews early on in my career.
, you know, I'd, I'd open up a poll request and I'd get like 50 comments on it or like, you know, I would, I'd submit another revision of that poll request, get another 30 comments on it, and then when I would look at code that people sent me to review, I didn't know what to look for or how to give good feedback. And over the years, especially at Amazon, I learned a lot about the ins and outs of code review.
Whether that is the process that the code reviewed process, that the team is following the code that an engineer is reviewing, or the code that an engineer is writing and how to address such, um, code review comments and feedback and those kinds of things. So I cover all this. It's like, it's a video course, it's about four hours worth of video content and it's on Gum road of course. So very easy to, to find that and check that out. Awesome.
Well, we'll include a link in the show. I know there isn't much content. I mean, there's blog posts here and there, right about pull requests and code reviews and things like that. But yeah, I don't feel like I've seen much actual, like really in-depth content like this. So I think that's, that's great. And anyone, if you feel like you need to step up your code review game, if you feel unsure or just like.
Maybe you've only done open source projects and like you've never been in a company that's done those, you've always worked on your own or something. Like, there's a great chance to to learn how to collaborate with others. So definitely, uh, encourage everyone to check that out and, uh, yeah. Curtis, thank you so much for joining us today. It's been a pleasure. Just chatting, getting to know you, your journey, uh, hearing about working asynchronously. I think that is such a huge thing.
In remote work, this ability for companies to start shifting, to work in that way. And it's great to actually hear someone who is actually doing that and it's working well for
Thanks a lot Eddie. I really appreciate you having me on the podcast. I think we covered a lot of ground today and I really hope to, to listen to this Will Joy.
Thank you for joining us for episode 41. An unpopular view on imposter syndrome with Curtis You can find links to everything we talked about in this episode, as well as a link to Curtis's website and social media accounts in the show notes. If you enjoyed this episode, help others discover it as well. Why don't you give us a shout out on your favorite social media platform and tag a friend or coworker that you think would enjoy this episode?
Don't forget to follow us wherever you hang out online, or you can subscribe to our newsletter to stay up to date. Thank you for joining us for season one. If you have three minutes, please take our short listener survey. You can find the link in the show notes and it will be invaluable while we plan out season two. Thank you for listening. And have a great day.