Why do you want to become a software engineer

• Tweet

  Índice Show

  • Why did I want to become a software engineer?
  • Why do you want to become a software engineer essay?
  • Why do you want to become a software developer * Your answer?

• Post

• Share

• Save

• Print

Where your work meets your life. See more from Ascend here.

I am fascinated by coding. It’s everywhere! Every single one of the digital experiences we enjoy is the result of code.

But honestly, I know almost nothing about how it works or how the people behind the code — software engineers — do what they do. To find out, I spoke with Lindsey Redd. Lindsey has coded for some of the coolest tech companies in the world: Slack, Lyft, and now Stripe. She shared with me the details about her journey — from wanting to be a doctor, to studying computer science at Stanford, to thriving in the top echelons of software engineering. We also talked about some common misconceptions about software engineers, what it’s like to work in a predominately white and male industry, and how to nail an interview for a job like hers.

Can you tell me a little bit about what your job entails? What does the day-to-day look like?

It can be different depending on the day. But usually, it starts with looking through what I have to do for the day. I know a lot of software teams use task management tools. My team specifically uses Jira as a ticketing system, and we have sprints.

A sprint will be a week or two. In that amount of time, you’re supposed to get “x, y, and z” done. I’ll look through those to-dos and make sure I’m on track — look at the tasks I need to do for the day, and do them.

Then coding, of course. But there’s a lot more to software engineering than coding. You code. You test. You deploy your code. You monitor your code, and make sure things are working properly. But then, there can also be a lot of meetings around product development or new features that need to be built on the team, and how we’re going to build those features. I meet with engineers a lot on the plan for implementation. There’s also a lot of pair programming, or working together with another coder to solve problems.

Did you always know that you wanted to be a software engineer?

No, not at all. I didn’t even know what it was until I was in college. I wanted to be a doctor in high school or a biomechanical engineer. My dad’s a doctor. My mom’s a chemical engineer. So something with STEM, I knew, was going to be my path. But I didn’t feel super inspired by the pre-med track or a lot of my engineering classes — I couldn’t really see how any of those skills or any of the things I was learning would be applied. I was looking for something else in the STEM field that would be a bit more interesting and motivating to me.

I went to Stanford. And Stanford’s a huge computer science school. A lot of my friends were taking intro computer science courses. I had never coded. I just really didn’t know what it was. But everyone was having a great time and seemed to find it really interesting. So around my sophomore year, I decided to take a class in computer science. My mentality was, if I like this class, I’ll take the next class. And then after that, if I like that class, then I’ll major in it. And that’s basically what happened. It was at that point I realized this is what I wanted to do.

What were those classes like? When you first started doing it, was it something that you were scared of or intimidated by? Or was it more accessible?

If I hadn’t seen other kids taking the classes, other people who didn’t know how to code, I would have been a lot more intimidated. But the introductory computer science courses at Stanford are super accessible. I even think they’re available publicly. They really start from the basics. You don’t have to know how to code at all to take the class. The professors were really great and they really walk you through, from the very, very basics, of what you need to know in order to code.

I enjoyed the classes because a lot of it is coding. And that is what I currently do right now on the job. I like that direct application of skills. I am learning things that I will eventually use in my career.

At first it’s a lot of puzzles. You code a little robot that navigates a maze. It’s simple stuff. I think my final project in my first class was building an extremely basic “Facebook.” They start you off simple and gradually ramp up the intensity.

When you were in college, you interned at both Lyft and Slack. Can you talk a little bit about how you landed those internships and what the experience was like for you?

I had a very interesting path to my first internship. Stanford does a lot of job fairs specifically for computer science students where tech companies in Silicon Valley show up and recruit. I had no idea how to navigate those spaces. I had zero clue how to land a computer science internship.

I got one interview for front-end web development, which I had never done. A lot of Stanford’s introductory courses focus on back-end work, like algorithms and data structures. So they were asking me questions about web development I just couldn’t answer. It was terrible. I was really lost. I had no idea how I was going to get a job for the summer.

Then, I remembered some of my friends were applying to an organization called Code2040. Code2040 is an organization that helps Black and Latinx students who study computer science enter the software engineering tech field. They have partnerships with companies that take on Code2040 interns. And it’s a pretty intense process. You have to do a technical interview to even get into the Code2040 program. You have to do a writing interview and a video interview, as well.

Once you make it into Code2040, at that point you can start interviewing with their partner companies. At the time, Lyft was a partner company with Code2040. I interviewed and the interview process was really hard. But Code2040 definitely helps you navigate that process, as well. So it was a good program for me, as someone who had no clue how to get into tech at all.

I interviewed with Lyft and then eventually got a job offer. Code2040 is a summer-long program. You go to workshops, you network with a lot of other people who are in the program, you work with other companies who are also partner companies. Slack is a partner company who I networked with during my first summer interning and then was able to use that connection when it came to getting an internship the next summer.

Tell me more about the interview process. What was difficult about it? What was that process like?

Now, having worked at Lyft full time, I know that their interview process is very different. But at the time, it was very similar to a lot of other tech companies, where they ask you random coding questions that don’t really simulate what it’s like to be a software engineer on the job. Like, I can’t tell you the last time, on the job, I used a “breadth-first search algorithm.” But I’m pretty sure that was one of my interview questions for Lyft. And you have to code on a whiteboard, which I never really did — usually all of your coding happens on a computer.

The interview test was just not very indicative of what I would be doing on the job. And I really had to study for it. I think studying for software engineering interviews is a whole ordeal in and of itself. And at the time, I didn’t really understand that, so I didn’t study well. Luckily, I had some skills under my belt that served me in my interview. But it made it difficult because I was very confused about how this was going to translate into my job.

You have to study for software engineer interviews? What does that look like?

The best advice I was given was to buy this book called “Cracking the Coding Interview,” which basically goes through all of the different kinds of questions that a lot of the big tech companies use — like Google, Facebook, and Microsoft. A lot of mid-size and smaller companies base their interview models off of those large tech companies.

There’s a lot of new innovation that’s happening in that space, which will make the process less of a test that you have to study for. But you usually do. And there are a lot of resources online, like Meetcode. Basically you have to do practice problems, like practice math problems as if you’re studying for a test, except it’s practice coding questions that test you on your knowledge about data structures and different kinds of algorithms — all kinds of things that you have to brush up on in order to do the interviews.

I know a lot of people who give themselves several months to study for interviews before even starting the process with any company. In college, I was definitely studying for at least two months before I would interview. When it came to interviewing for full time, I also started studying a few months before I started interviewing.

So you have to basically start studying before you even know if you have an interview lined up?

Yeah, and a lot of companies understand that that is part of the process. Recruiters are very, in my experience, flexible in giving you as much time as you want to study. For my current job, I remember asking my recruiter if I could have four or five weeks to study before I actually did the interview. And they were like, “Oh, yeah, I totally get it.” But a lot of people, once they decide that they’re going to switch jobs, they know that means it’s time to start studying.

When you’re answering these questions, are you coding live in front of the interviewer?

Yes, in most cases. Lyft does an interview where you get an hour to code a small project on your own. The interviewer doesn’t have to be there, so you can focus. But I think in all other interviews that I’ve been in, you’re coding in front of someone or pair programming with someone during the interview. It’s a lot of pressure.

You do pair program on the job. So interviews that involve pair programming I think are really great. But coding with someone watching and judging your performance is not typical on the job. A lot of it you’re just doing on your own. It’s definitely something to get used to because it’s not something that you do normally while you’re studying computer science or working as a software engineer.

Tell me more about pair programming. Is it just programming with another person on your team?

Pair programming is when you work with someone on your team or another team on a problem that either you need help on or that you two are solving together. There’s usually someone who’s the “driver” and then someone who is in the “passenger seat.”

The driver is the one who’s actually typing. But you’re problem solving together. It’s a very collaborative experience, which I like. I think I’ve learned a lot doing that process, even in interviews. You tend to solve problems a bit better and faster when you’re working with someone in that way.

So you interned at Lyft and then were able to get a full-time gig there. How were you able to turn that internship into a full-time position?

Generally, if you do well during your internship, the company will give you a full-time offer. So the big question is, how do you do well during the internship?

There are a lot of pieces to that. My misconception going in was that I needed to get my project done perfectly and completely, which I didn’t do when I was interning at Lyft. I think what people are really looking for when you’re an intern on a team is your ability to communicate, both verbal and written communication, and your ability to problem solve and work your way about an abstract problem. So even if you’re not able to finish the project, demonstrating those communication, organization, and project management skills, and figuring out how to implement them — that’s a lot of what people are looking for when you’re an intern.

What kind of questions do you ask? Do you make sure you ask questions to solve your problems? How fast are you able to ramp up and learn new technologies, skills, and languages quickly? What kind of energy do you bring to the team? What is it like working with you?

Now, being on the other side and having been an intern mentor, it definitely helps when your intern is super excited and super curious. That’s what’s so fun about having interns. Not only are you helping to bring more people into the company, but you want to make sure that those people are positive and fun to work with.

Exuding that during your internship, that curiosity, that spice and passion for what you’re doing, it definitely helps leave a positive, lasting impression on your team. If you have that, plus you’re able to problem solve and get stuff done, you’re pretty set up to get a full-time offer at the end of it.

I know very little about coding languages. How many coding languages have you learned over the years? And how long does it take to learn a new coding language?

In college, we were learning C and Assembly, which are extremely low-level computer systems languages that you don’t usually need to know. I also learned Java and C++. But I don’t use those very actively anymore.

In my professional career, I have learned Python, Golang, PHP, React, and Ruby. But every company uses something a little bit different. Or they introduce new languages that do different things. And so that’s why I mentioned during your internship it’s a good thing if you’re able to exhibit that you can learn quickly.

When I started my internship at Lyft, I didn’t know Python. I had no idea what it was. Luckily Python is a pretty approachable language. I think I’m forever learning these languages. It’s like learning an actual spoken language in that way, where there’s things that are changing all the time. There’s just a huge mix of things that these languages can do, and so you’re constantly learning what those new things are.

For me, to actively code in a language and feel comfortable in it probably takes four weeks. But even at that point, you’re still Googling a lot of stuff. I feel like I Google how to do “for loops” in certain languages, which is a very basic thing. But each language has different syntax for even simple things. So luckily Google or any search engine is a great resource for learning how to do whatever you need to do in whatever language.

I Google the simplest things all the time. I remember there was some Twitter thread recently where a lot of senior engineers were tweeting the things that they still have to look up. And it just helped a lot with my own imposter syndrome, knowing that these people who I admire a lot because they’re really great engineers are also looking up very simple things.

How did you get your current job at Stripe?

LinkedIn, honestly. I know LinkedIn is not for everybody. But I definitely use it as a tool for my career. I keep my LinkedIn up to date. I have my email on there. People can reach out.

My current manager at Stripe reached out to me on LinkedIn. She just sent me a message and was like, “Hey, I’m hiring. Do you have any interest?” And Stripe had always kind of been on my radar. I wasn’t really planning on leaving Lyft when I did. But I feel strongly that if there is an opportunity that seems interesting to you, you should at least have the conversation. So I did, and it went really well.

From there, I was like, I’m going to just interview and see where it goes. Maybe it won’t work out, and that’s fine. So then, I started to study. I did the interview. You do a phone screen interview, which is usually just one or two questions with one person. And then you do an on-site, which now is just all virtual. But the on-site interview involves about five interviews. After that, you find out if you got the job or not, and then you go into negotiations.

I think the hardest part a lot of the time is just getting your foot in the door, getting your resume recognized. I definitely use LinkedIn to help me make those connections.

Do you tend to get reached out to a lot by recruiters?

There are definitely more open software engineering roles than there are software engineers. That gap will continue to grow unless we do a lot more to get more people educated in computer science. A lot of people will reach out to me about their open roles. When I was job hunting, I was very proactive in reaching out to companies that I thought were interesting, even if they hadn’t reached out to me. So it’s not all inbound.

But, I’m very privileged in the sense that I have my Stanford degree. I have Lyft, Slack, and now Stripe all on my resume. And these are really well-respected organizations and institutions. I think I get a lot of inbound traffic because of these names that are on my LinkedIn, and on my resume. I know that that’s not necessarily the case for a lot of other engineers — great engineers; better engineers than I am — just because they don’t have these brand names on their resume. So while there are a lot of open roles, I think that there’s also a lot of elitism in the industry.

I know of companies that are like, “Oh, we only hire from the top five computer science schools,” which is ridiculous. I think there’s still that weird tension in that there are actually a lot of people who can do this work. There are a lot of open roles. But then people have unreal expectations of what a resume is supposed to look like.

And of course the interviews are intense, as I was describing. Not everyone has the resources to prepare for three months for an interview. So there needs to be some bridging of those gaps there, in my opinion.

When you do have a ton of opportunities like that coming your way, how do you decide which ones are worth your time?

I think it depends a lot on what you want to do. There are a lot of different kinds of software engineering. So when my manager at Stripe reached out to me, it was for a full-stack, more product-engineering role. I was doing a lot of infrastructure engineering at Lyft and was interested in what it would be like to work on a product team.

Stripe is also just super well-known and has a reputation for being a good place for engineers and developers. That was a particular combination that was interesting to me. But someone who wants to work on a lot of AI and machine-learning stuff might not be super interested in a product role at Stripe. So when I get inbound requests for the hot new AI startup, it’s not going to peak my interest as much because that’s not necessarily where my interests lie.

There are all other kinds of factors, like what size company do you want to work at? Are you interested in a Google-size or a five-person startup?

The company choices I’ve made so far are all pretty on par with each other. Slack, Lyft, and Stripe are all similarly sized, and have similarly sized engineering organizations. Valuations are in a similar realm. They were all pre-IPO when I started working at these companies, which is something that I was particularly looking for.

In the future, that might change. I might look for something completely different. And I think that I probably should at some point just to widen my range of experiences.

But that’s how I narrow it down. I have a pretty clear idea of what I am looking for when I start a job hunt. And so I’ll filter out based off of those requirements I have.

You’ve mentioned a few types of software engineering? Can you tell me a little more about all the different types?

There are a lot of different types of software engineering. I probably don’t even know all of them. I’m forever learning about new areas where people are innovating.

The basics are front-end, which is more like web development or what you see on your computer screen. Back-end is more like servers and algorithms and things that you don’t see as a user but that help power the front-end. And then there are people who are full-stack, who do both of those things.

There’s infrastructure engineering, which is building out services, like microservices, servers, monolithic servers, or observability pipelines — things that need to sit underneath the back-end layer in order for it to work. A lot of developer tooling is considered infrastructure, things that keep the upper layers working. That’s a lot of what I did at Lyft.

There’s machine learning and artificial intelligence engineers. There’s data engineering. There’s SRE, which is site reliability engineers — they keep the lights on and make sure everything’s working properly. There are QA engineers, who test the quality of the things that other engineers are building. And they build automated systems in order to test the quality of products. And there’s mobile engineering — people who build iOS apps, Android apps, which is a whole different kind of skill set.

Anywhere your interests lie, there’s probably a kind of software engineering that fits that.

Is it challenging to switch between those different types?

I think the most difficult part is just learning the new technology. Hiring managers are pretty open — like if you’ve only worked in infrastructure, they are pretty willing to hire you on to a product team or vice versa. That can be good because they have a different perspective than people who’ve only worked in infrastructure.

The biggest thing you have to do is learn the new language and learn the new technologies. And there are a lot of resources in order to learn. There are Udemy courses, books, and online projects or tutorials you can follow to understand how to do something.

I think the parts that are a bit more difficult to learn are maybe AI and machine learning because they require a very specific, more math-based education. Otherwise it’s pretty straightforward to lean into a different area of computer science or software engineering.

If I wanted to become a software engineer, what are the most important skills that I should be developing right now?

Definitely building, testing, and maintaining software is the core skill set. Getting your foot in the door and getting a job is a lot about developing those interview skills, which there are a lot of resources for developing those skills, as well. I’d say a lot of the skills that people don’t really talk about that you need to be a good software engineer are more of the soft skills, like verbal and written communication, organization, and project management skills.

Can you talk a little bit about some of the misconceptions of this career path?

A big misconception is that software engineers just code, which is not true. A lot of my job is writing documentation to explain things to people or communicate or pitch ideas. A lot of it is meetings where we figure out the direction of a particular piece of software or a product. And those all involve a lot of other skills that are not coding.

I think people have this vision of software engineers that we’re in a dark room coding by ourselves all the time, which is the vibe sometimes. I’m not going to lie. Sometimes there’s a problem you need to hammer out with code. But a lot of the job is very collaborative and not solo work at all — a lot of planning, being a team player, communicating what you’re doing, and asking questions you might have so that people can help you.

Another piece that’s huge that people don’t really consider is how important mentoring people is in software engineering. That can mean mentoring people who are younger than you or just people who are new to your team. Software engineering is such a team sport, and I think a big skill is making sure that new people who are introduced to whatever it is that you’re working on can work on it, be productive, and be an active member of the team. That involves getting people ramped up, helping them, answering a lot of questions, and being able to communicate your ideas.

Software engineering and the tech industry in general, it’s predominantly white. It’s predominantly male. Would you mind talking a little bit about what it’s like to navigate an industry like that?

It’s hard. It’s definitely a struggle. I have a lot of privilege in that I am able to navigate the field with the school I went to and the jobs I’ve had previously. And even with that, you definitely get people who doubt your skills, doubt your skill set, and undermine your work, which sucks. It’s hard and not fair and definitely needs to change.

A lot of navigating it, for me, has been my own internal work of staying confident, sure of myself, sure of my skills, my education, and everything that I bring to the table, even if not everyone sees that. It’s definitely clear that a lot of people, companies, and teams do see the skills that everyone can bring to the table despite their background or the school they went to or company they previously worked at. But depending on the culture of the company, the specific makeup of the company, and your manager, it’s definitely a daily grind to do it. I think it’s more work than the white dude software engineer has to go through to find a team and find a company that will work for you.

One of the things I ask when I’m vetting companies and teams is, what does diversity look like at the company? How does your company think about or treat diversity and inclusion? Are there other people at the company who look like me who are doing well and feel good? That’s definitely a piece of my research. And it’s hard work in and of itself to vet those things and figure those things out. But it’s necessary in order for me to be the best employee or engineer that I can be.

What are some of the other obstacles and challenges of this career path?

It can be different depending on who you are and what you struggle with in particular. For me, I struggle with imposter syndrome. So one of my struggles on a daily basis is just feeling like I’m doing a good job. It really helps me when people give me feedback at all just so I know how I’m doing. And also it helps when I get some positive reinforcement.

Because engineering is a space that’s so male dominated and white male dominated, it often can feel like I’m not measuring up because I think a lot of people sometimes don’t recognize the skills that I have because of my different identity. So staying confident and staying sure of myself has been a particular challenge for me in software engineering.

There’s also this notion of the 10x engineer — the engineer who just gets the work done of 10 other engineers and is super productive. That is an ideal that people expect out of engineers. But it’s just not true and not actually attainable, and it can affect work-life balance. Maintaining those boundaries, understanding what you’re able to get done in a day, and knowing that that’s OK is also something that feeds into imposter syndrome. It’s something that I have struggled with and that I’ve had to deal with.

What really helps is having a community of people who are doing what you’re doing, either at your company or outside of it, or ideally both, who you can talk to about whatever struggles you have. Because 10 times out of 10, when I’ve asked someone else in my community or in my support group of other software engineers, “Have you struggled with this?” the answer is yes.

And whether they figured out the solution or not, it does feel better to know that other people are dealing with the same things that you are. I would suggest that for any career path, whether it be software engineering or not.  Having your people, having your community, helps with any kind of struggle you may face.

Let’s talk money. What should I expect to get paid in a software engineering role?

It depends on a lot of different factors. Your location — if you’re a software engineer in Alabama, your salary will look different than a software engineer in San Francisco because of the different costs of living. Company size also matters, and what stage of growth they’re at. The Googles and the Facebooks will have the higher offers. Companies that are maybe pre-IPO and going through a lot of growth, they’ll also have high offers. Companies that are maybe pre-seed startups or seed-stage/Series A startups will have lower salaries. But there are a lot of upsides when you think about equity and stock.

If you’re in one of the coastal locations — San Francisco, New York, LA — some of these larger, more established tech hubs, if you are not making $100,000 out of college, you’re probably being underpaid or could at least find a company that would pay you more. I’m not sure what that looks like if you’re finding a job in Atlanta, for example. It might look very different.

There are resources online to help you figure out, if you just got an offer, if it’s fair, depending on your location, your level, and the size of the company. I would recommend looking at websites like Levels.fyi and Glassdoor to figure out salary information.

I would also say talk to your friends. People don’t talk about how much they make enough, which I think leads to a lot of pay inequity in the industry. I would straight up ask people, “How much do you make?” When I have seen people realize that they are not being paid fairly, it is because people around them have been honest about what they make and they realize something’s not adding up. So I would talk to people and encourage them to be transparent because it’s what needs to happen in order to hold these companies, that a lot of times don’t want to pay you fairly, accountable.

What do you love about software engineering?

It’s the mix of teamwork, collaboration, pair programming, and problem solving with the ability to do a lot of solo work and figure problems out on your own. I enjoy the process of coding and not knowing what’s really going on, but testing and working through an issue, Googling whatever I need to, and then getting to a solution. That feeling, that gratification of figuring out how to do something or solving a bug, is unmatched.

I enjoy my teams. I enjoy working with people, and I enjoy doing my own thing a little bit. Software engineering definitely allows you to do both and, depending on what kind of company you work at, allows you to do more of one or the other based on what you want. There’s a lot of flexibility in that way, too.

Is there anything that you wish you’d known about this career path before you started?

When I started and majored in computer science, I did not know the intensity of interviews and how much you had to study for them. Even if you’re 10 years into your career, if you want to switch jobs, you have to study. I did not know that.

I also wish I would have known all the different kinds of engineering that you can do. When I started my full-time job at Lyft, I didn’t really care which part of the stack I was working on. In my head it was kind of all the same. My first two internships were different in what I was working on. But that wasn’t what I was really paying attention to at the time. I was just trying to do a good job but not really thinking about, what is it that I want to work on? What are the kinds of problems that I think are interesting and want to solve? Is it infrastructure problems? Is it product problems? Is it front-end? Is it back-end?

For example, I really wish I had invested more time in learning mobile engineering. I could switch into doing that and probably will at some point because I find it interesting. But I just didn’t even think about any of those things. It can really change your day-to-day. It can really change the kind of work you do, depending on what kind of team you’re on, what their stack looks like, and what kind of product that they produce. I wish I had known those differences and how those kinds of teams differ in how they operate.

Okay, last question: Who is your career crush?

I really look up to Erica Joy Baker. She is a software engineer. She worked at Slack at the time that I was interning there, and I had known of her before that. She was at Google for a really long time. And now she has transitioned into management and is the Chief Technology Officer for the Democratic Congressional Campaign Committee. I just really like the way that she shows up. I had the opportunity to speak with her a few years ago about her work and about how she approaches her work. She also writes a lot online to give you more insight into how she’s thinking.

She is someone who brings her whole self to work and uses her unique qualities to lead. I really admire that and would love to exude more of that at work. She seems to be super confident in herself and her skills. And people are super confident in her because of that. And I also admire that.

Also, transitioning into management and moving up that career ladder into a director of engineering is also something that’s super interesting to me and I think something that I will eventually pursue. I think they’re solving a higher level of engineering questions about organization and how people work together, which is super interesting to me.

Why did I want to become a software engineer?

Why do you want to become a software engineer essay?

Why do you want to become a software developer * Your answer?