Eddie: 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.
Curtis: Hey, how's it going?
It's a pleasure to be on the podcast, Eddie.
Thanks a lot for having me.
Eddie: 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
Curtis: 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.
Eddie: 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
Curtis: 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
Eddie: that different people have different ways of learning, so having
different modes of communicating those same truths is, is really exciting.
Curtis: Yes, absolutely.
Yep.
How
Eddie: 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
Curtis: 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.
Eddie: 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,
Curtis: 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
Eddie: 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.
Curtis: 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,
Eddie: 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?
Curtis: 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.
Eddie: 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
Curtis: 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,
Eddie: 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
Curtis: 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,
Eddie: 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?
Curtis: 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.
Eddie: 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
Curtis: 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,
Eddie: 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.
Curtis: 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.
Eddie: 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
Curtis: 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.
Eddie: 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.