As a junior engineer:

60% of the time I did coding.

20% of the time was spent on learning: This involved getting onboarded and understanding Citi's software ecosystem. I had to learn the Angular codebase used to create Citi's website. I also had to read Citi's documentation on developing websites and how to deploy the websites to the World Wide Web. I also needed to learn Angular in general, so I could keep up with developing features. I asked my mentor any questions that I had.

10% of the time was attending meetings

10% of the time was playing ping pong: I played ping pong for an hour after lunch. Citi's office had ping pong tables, and it is a popular place to take a break and relax.

– Former senior software engineer @ Citibank

10-20% of my time is replying to Slack messages from my teammates and other teams. The more projects I'm on, the more time I'll spend on Slack.

I'm an entry-level engineer, so this is actually on the low end. The higher up you go, the more time you spend communicating with other teams.

Even if we're all in the office, we'll still use Slack to chat with each other. Often, we need to share files or code so this makes sense than walking over to someone's desk.

60% is coding.

I'm a junior engineer, so a senior engineer will give me some tasks like "Optimize this part of the code." So my first step is figuring out what the code does. If I can't figure it out, ChatGPT usually knows!

I rarely need to write totally new code since I can rely on existing code in our company's code base. For context, the code base is like a library, and writing new code is like adding a new book to the library. But we rarely need to write new books from scratch. We can find an existing book and make slight changes.

10% is documentation.

When I make a new feature (say a TikTok filter or effect), I need to write down why I added it, who can use it, and how to use it.

I'll also document new learnings. If I learn something new, like a new way to use ChatGPT, I'll put it in the system so my teammates can learn them as well. (This is good for the performance review since it counts as a team contribution.)

10% of my time is chilling. Think: Waiting for coffee, getting snacks, staring into space, meditating – your eyes get dry so you have to rest them!

– Junior software engineer @ TikTok

Here's what our DevOps engineer did when he was a junior in the field.

As a DevOps engineer at a manufacturing company, my role supported a diverse range of products - from military helicopters and airplanes to golf carts and snowmobiles.

About 30-50% of my time involved meetings with developers across the organization. These developers wrote applications for various purposes - from websites to the software inside helicopters and airplanes. They'd come to our team saying, "We have an application we'd like to deploy. What server architecture should we use?" This is where my role in managing the infrastructure came into play.

The bulk of my day (40-50%) was spent on deployment and automation. Typically, to set up a server to host an application, you might go into a website portal and click through different options one by one ("I want this specific type of server," "I want it in this specific region," "I want it to have this amount of capacity."). Instead of clicking through the portal to set up each individual server, I'd write code that automated this process. This automation was essential, as we managed anywhere from 600-700 servers at a time.

The remaining 10% involved post-deployment management. This meant ensuring everything ran smoothly after a server was set up. For example, I'd lock down security to prevent unauthorized access and set up alerts for issues like servers running out of space.

– Former DevOps engineer @ a manufacturing company

😊 How happy are software engineers with the job?

I think the answer to the question varies for each engineer and also varies with time. I'd say that even software engineers who like what they do go through some period of burnout. In that period, you just don't want to touch a keyboard.

– Former senior software engineer @ Citibank

I've met devops engineers who were satisfied in their role and ones who weren't. This depends on a lot of factors that are outside your control. Factors like:

How complex the application stack is (which in turn defines what automation subprocesses need to built and managed).

The scope of work on the team.

The number of automation tools at your disposal.

– Former DevOps engineer @ a manufacturing company

I'd say how happy a software engineer is can vary widely depending on:

The company. For example, it's generally said that Facebook and Netflix push their engineers harder than Google does.

The vertical. If you're passionate about healthcare, you might be happier in a health-tech company.

Your tech stack. Some people love front-end development and may not enjoy back-end development and vice versa.

(At higher levels) Whether you've found the type of engineering that suits you. Some software roles are people-facing and require you to talk to lots of stakeholders to understand what needs to be built. Some are more theoretical, where you'd figure out how to how to optimize graphs or algorithms. Some people output massive amounts of code.

It could take you multiple years until you find something you like! It's not a bad thing to jump around roles until you find what you like.

– Former software engineer @ Meta

💃 What type of people thrive?

Across the board, our software engineers believe that people with patience and persistence would thrive in their field.

A good software engineer would have a don't-give-up attitude.

– Former senior software engineer @ Citibank

You need to have a lot of patience to be a software engineer. There's always going to be bugs. It drives some people crazy when they can't find a bug. Personally, I just keep trying. I might come up with a dumb solution, but I'm able to fix the bug.

– Junior software engineer @ TikTok

I would NOT recommend people to work in a devops role if they don't have patience when it comes to the role – being a devops person can be very tedious when it comes to building out the automation processes, and it sometimes won't work the first, second, or even tenth time you try and run it, so you have to be resilient in your efforts.

– Former DevOps engineer @ a manufacturing company

You should ideally also have an interest in the field and feel ownership over your work.

The type of people who thrive in Software Engineering are people who are passionate. I would not recommend people to do software engineering for the money. I know the field pays well, but if you do not like being in front of a computer for long periods of time, then it will not be worth it. You want to pursue software engineering because you love to do it.

– Former senior software engineer @ Citibank

Just as civil engineeres are legally responsible for the bridges they build (if they collapse, they go to jail!) – as software engineers, we need to be responsible for what we create as well.

To succeed in this field, you need to put more love into the quality of your work and truly own the problem. If you want to succeed, don't just do what you're told. Think more about what you're trying to achieve. Then take ownership of your work so you can take more initiative and grow.

– Former software engineer @ Meta

For DevOps, you should be process-oriented person and have coding experience.

I would say the people who thrive in a devops role would be people who are very process-driven and can break down each "stage" of an automation process down to its most granular subprocesses and actions. These people tend to be very analytical in nature, and can pick apart a deployment of resources to troubleshoot any issues that come up during deployment and fix those issue.

I would NOT recommend people to work in a devops role if:

They haven't written any code before.

They haven't worked on a software application.

– Former DevOps engineer @ a manufacturing company

👍 Pros

All four software engineers mentioned the large amount of learning as one the main pros of the job.

The pros of my software engineering job are getting to learn new skills and apply them when I code. I feel that the amount I have learned in one year at the job surpasses the four years of Computer Science education I gained during undergrad.

– Former senior software engineer @ Citibank

Pros of the job are:

I can see my impact.

I like the office – it's very big and has a lot of food and drinks.

I like the people I work with. They're very smart and give me ideas that I wouldn't think of myself. For example, they often suggest improvements to my code. As an entry-level engineer, I like learning new things from them.

– Junior software engineer @ TikTok

In civil engineering, you need years to build something – and you may not realize there's a problem until a hundred-year storm hits. In software engineering, you build quickly and release quickly so you constantly get corrections and new learnings. It's also a brutal field because you can't run away from your mistakes but you can learn a lot really fast if you want.

– Former software engineer @ Meta

The pros of being a DevOps engineer are that you get to be a part of someone's application since you have to understand the intricacies of the application to support it.

There is a lot of knowledge and involvement in learning what makes an app work and not work from a hosting perspective, so if you like to learn all the time and constantly improve the automations that you build then it's a great field to work in.

It can be a very lucrative field also and most engineers get paid very well.

– Former DevOps engineer @ a manufacturing company

👎 Cons

For one engineer, monotony was the biggest con.

The main con of my software engineer job was monotony after two years of doing the same type of tasks. The 1.5 years at being at Citi were valuable for me as I was learning the ropes of software development and the software ecosystem at Citi. Afterwards, however, I felt stagnant, and I felt I was doing the same thing for each new project.

I just got bored. Being bored at a job can be dangerous since it can lead to burnout. To avoid burnout, I would say to take breaks and/or switch teams in the company or even look for a new job. Someone once told me that when you start feeling bored at a job, then it indicates that it is time to start a change. I wish I had taken that advice sooner!

– Former senior software engineer @ Citibank

For DevOps, the con was that the job isn't always appreciated.

DevOps can feel like a thankless job as some teams that you may work with only care about their application and do not appreciate the backend work you do to keep systems running smoothly.

– Former DevOps engineer @ a manufacturing company

A DevOps' work is to ensure nothing breaks. So unfortunately people don't really see their value when things are working.

– Former software engineer @ Meta

Our engineers also brought up issues with work-life balance.

🌍 Impact

Our software developers felt they made an impact when they thought about how their products would be used by lots of people.

I felt that I was making an impact at Citibank because each product I helped develop would be used by millions of people in the country. Knowing that the feature I was developing, such as the homepage or the credit card reward pages, was going to be used by actual customers felt rewarding to me.

– Former senior software engineer @ Citibank

I'm happy that I'm making something cool. I've made many effects and filters that you can use on TikTok and I can see data on how many people use the things I make, so I feel good about it. I hope my effects make them smile or have a good day!

– Junior software engineer @ TikTok

Our DevOps engineer also felt that he made an impact on the people who used the applications he supported.

I do feel that I make an impact as a DevOps engineer. There's a great sense of satisfaction in supporting a project from start to finish. You get to see the full picture of how an application or project is hosted and managed throughout its entire lifecycle – from birth to death to everything in between.

You also get to learn about different concepts, frameworks, and technology stacks that help make applications run efficiently. It's our job to push changes to applications without causing any noticeable downtime for customers or users.

It's rewarding to know that our work affects the entire organization in important ways, even if it's not always visible to everyone.

– Former DevOps engineer @ a manufacturing company

Part 2. Would I like the life?

⚖️ Work-life balance

The work-life balance is pretty fair I would say. I usually was at the office for 8 hours a day (9-5), but I did not work all those hours.

I had lunch from 12 to 1 and played ping pong for the hour after lunch. So the amount of time actually spent on development work was about 5 to 6 hours.

The other amount of time was for meetings and breaks. Depending on the company, the typical vacation time is about a month including holidays.

– Former senior software engineer @ Citibank

Here are my general work hours.

9:30-10:30am: Commute

10:30-12:30pm: Replying to Slack messages and emails and taking care of small tasks

12:30-1:30pm: Lunch with the team

1:30-6:00pm: Development

6:00-7:00 or 7:30pm (depending on traffic): Commute

8:00-9:00pm: 1-2 meetings and replying to messages from coworkers in China.

I have a lack of work-life separation but that's because it's TikTok and 50% of my colleagues are in China so I have to reply to their messages and even have meetings at 8-9pm. Since they work during our night time, I have to answer their questions or else I block their progress. If I didn't have coworkers in China, I'd work 10-6 and be able to be offline after hours.

– Junior software engineer @ TikTok

The inability to be fully separated from your work is one of the biggest cons. This job pays well, because it's buying your time and freedom outside your work hours.

Most engineering jobs have shifts where you're on-call or "on pager duty." We have all these "pagers" that'll ring with automated alerts and alarms if the system detects something went wrong. So even if I'm in bed, I'll have to respond to the page within a few minutes. I'll then have to triage and judge how urgent something is and fix it.

Even when you're not on call but you're the tech lead (or the most knowledgeable person about something) and it breaks, they're going to try to reach you. So it's hard to have work-life separation as an engineer.

– Former software engineer @ Meta

The cons of being a DevOps engineer are that sometimes you can work very long hours and have to support applications/projects that may span over the weekends or holidays.

The work-life balance can be good or bad depending on the company/team/scope at which you are doing devops. Some companies and teams ask you to be on call supporting an application over the weekends/holidays and some companies don't have that and it's just a regular 8-5 job.

– Former DevOps engineer @ a manufacturing company

🤸‍♂️ Flexibility

Our software engineers mentioned enjoying a high degree of flexibility as long as they got their work done.

I worked primarily remotely, but in my first six months of working on-site, I felt that my working hours were very flexible.

If I had an appointment I would message my team ahead of time, and they usually approved it. As long as you completed the tasks that were assigned to you, you would be fine.

– Former senior software engineer @ Citibank

I have to go to the office every day. In Silicon Valley, it's just our company that makes employees do this – most companies just require three days in the office.

That said, it is flexible. We don't have a set hours that you need to be in the office. You can go in in the afternoon. Or you can tap your badge in in the morning, grab some food, and go back home to work. They don't really care as long as you deliver what you need to deliver. Personally, I feel more energetic in the office, so I work in the office.

– Junior software engineer @ TikTok

When I was a cloud engineer, the flexibility was really good. I had a hybrid schedule so I spent 2 days of the week at home and 3 days in the office.

I would have to be on call during at least one weekend out of every month and sometimes holidays – and I did have to travel to our small data center sometimes and troubleshoot things at odd hours.

But my boss was really understanding when it came to things like that and if I had to stay late at the data center for some reason overnight or if I was up late on a support call then he would generally give me a half day the next or the full day off and it didn't count as a PTO day so it was still paid.

– Former DevOps engineer @ a manufacturing company

👫🏽 Diversity

Overall, there is not a lot of diversity within the field of tech – especially in software engineering roles.

There has been diversity in the field. I noticed that a lot of the developers I worked with are international people (India, Singapore, and Pakistan). However, more people from different backgrounds are joining the software industry.

I do think that there is not a high percentage of women in the industry, but I know companies are pushing for more females to join.

– Former senior software engineer @ Citibank

98% of my coworkers are Chinese or Chinese-speaking. But that's more because our company is Chinese. That said, the software field in general tends to have a lot of people with Chinese or Indian backgrounds.

The male-female ratio is also pretty bad. None of my 30 or so teammates are female. There are some in marketing or data analytics but maybe less than 10% of software engineers here are female.

– Junior software engineer @ TikTok

However, the level of diversity can also depend on the company and industry you work in.

I think a company's business can really shape its workforce diversity. A company that sells snowmobiles, for instance, might attract very different employees than one that manages satellites.

My first company made things like military equipment, golf carts, planes, and outdoor vehicles. The people who typically buy and use these products tend to be from a specific demographic, and this was reflected in who the company hired. I would say around 50-60% of all of my colleagues in the office were white males. Out of several hundred employees, only about 20 or 30 were women.

My current company supports satellites in orbit around Earth, which almost everyone relies on to use their cell phones. It's much more diverse – everyone I work with comes from a different background, culture, and geographical location.

– Former DevOps engineer

Part 3. What's in it for me?

🌱 Learning & development

I think my biggest takeaway so far has been coming to terms with what it means to work in a big company – which is basically a large, complex organization.

Mainly, I've learned how to be a cog in the wheel and to recognize that while my work is important, it's a tiny part of a massive pipeline.

For example, deadlines aren't just deadlines. If I don't complete my work by a deadline, I'm a blocker for the rest of the pipeline. This is where most of the pressure comes from.

Being a part of a pipeline also requires me to draw clear boundaries between me and other teams or coworkers ("You do that and I do this"). This is another thing I've gotten better at.

I've also realized how important it is to be familiar with the rest of the organization. For example, I may only know that other teams exist (like there's "team A" or "team B") but I won't know who can work with us to create a new feature. My tech lead will know exactly who on team A can give us the help and support we need. In a big organization, this is an important skill to have if you want to get things done.

– Junior software engineer @ TikTok

The biggest thing I've learned is the importance of managing up. The easiest and most common failure is expectation setting. A lot of people just don't set expectations clearly so they don't know if they're doing well or underachieving and they're surprised by their performance review.

Sometimes people who are overachievers overpromise and underdeliver. So my advice is to set lower expectations and deliver more. Always communicate what you are doing and how you want to improve.

Be very clear with your goals. What do you want to achieve and how your managers can support that?

– Former software engineer @ Meta

These are my biggest sources of learning on the job:

Self-learning on the job through various methods such as the internet, reading lots of documentation, watching Youtube videos and tutorials on how to build certain automation pipelines, and others. Since I'm a visual learner, I felt this helped me learn and grow the most.

Asking questions to other members of my team and various colleagues around the company. This gave me a ton of insight as to what problems are occurring and seeing it from the perspective of someone who's faced it before and can provide insight into a solution.

Certifications: Since I was working in the cloud industry, I obtained a cloud certification that was supported and paid for by my employer. This was nice but I'd say I learned less from certifications than from self-learning and asking questions, because certifications mainly teach you how to memorize concepts and questions on paper and take an exam.

– Former DevOps engineer @ a manufacturing company

🌟 Job outlook & stability

According to the U.S. Bureau of Labor Statistics, "Overall employment of software developers, quality assurance analysts, and testers is projected to grow 25 percent from 2022 to 2032, much faster than the average for all occupations."

Here's what our software engineers describe on the ground.

Job stability is very iffy right now. The tech job market has changed a lot since the pandemic and for the worse. There has been a lot of hiring freezes and layoffs these past two years, and everywhere I am hearing that different companies are letting go of their employees. I see different posts on LinkedIn about someone being let go of the job. It is pretty rough right now if I have to be honest.

– Former senior software engineer @ Citibank

DevOps and other engineers are always needed and they will always be in demand as long as the world is building software.

– Former DevOps engineer @ a manufacturing company

In particular, working in DevOps or Site Reliability may be more stable than working as a software engineer who creates new things.

If Google wanted to, they could lay off 90% of their engineers and just maintain the system – in which case they'd just have DevOps and Site Reliability Engineers. It's harder to scale down these teams, as they keep the system running.

– Former software engineer @ Meta

💵 Pay

Our engineers recommend checking out the website Levels.fyi to find salaries across the industry.

For juniors, the whole package is 170k-200k including stock options. My favorite benefit is that my company covers up to $100 of your cellphone bills so I just choose the most expensive plan.

– Junior software engineer @ TikTok

As a DevOps engineer, my starting salary was $66k. That grew to around $82k three years later. This was at the manufacturing company.

At my current job, I started out making $105k, and I've been in the position a year and a half and my current salary is $115k.

Some of the benefits we got were free lunches from the cafeteria as it was subsidized by the company for the employees to use. Others were a hybrid work schedule and 3 weeks of PTO from day 1 of employment.

– Former DevOps engineer @ a manufacturing company

📈 Career progression

Generally, you'll get promoted in 1-2 years.

Entry-level to mid-level: 1-2 years.

Mid-level to Senior engineer: 2-5 years. If you have really good coding skills or managerial skills, you'll get promoted fast.

Then there's Senior 2, Staff, and Principal Engineer. When you reach Staff, you can decide if you want to continue being an engineer or if you want to become a people manager instead.

– Junior software engineer @ TikTok

This varies depending on the company and team, but I'd say:

Junior to mid-level DevOps: 1.5-2.5 years

Mid-level DevOps to senior DevOps: another 2.5-4.5 years

– Former DevOps engineer @ a manufacturing company

And if you stick it out, here's how your career might look!

Here's a common leveling system (the system that defines what engineers do at each level):

L3s/E3s (entry-level): This is where you'd come in as a new grad. Your managers will mentor you and your tech leads will ask you to create specific things. For example: "We're missing a green button in this position. When this button is clicked, an e-mail pop-up should appear so they can send an e-mail." Things are scoped down to a concrete task and it's all about delivering good code.

E4/L4 (mid-level): At this level, you move from a task to a feature and you start to solve problems that are a little more ambiguous. For example: "Customers were saying they want to contact us on that page. We decided they could do this over e-mail. Could you figure out the user flow?" This would be a communication feature and you'd work with designers and product managers to decide where the buttons should be and what the user flow should look like.

E5/L5 (senior): Here, you'd work at the project level. For example: "On the website there are numerous communication touchpoints with our customers. Where should these touchpoints be? How would we know if they're functioning? How should we measure communication quality?" You might define the metrics (e.g. reply time, e-mail throughput, e-mail length, etc). Seniors are expected to understand and quantify the problem, propose the solution, and guide people to build the solution.

E6/L6 (staff): You're now tasked with a problem. For instance, at Facebook, a staff engineer might be asked, "How do we make sure our Android apps are always very fast and not bloated? What does fast even mean? How do we measure that? How do we divide the work among multiple teams?" (since some teams will own the measurement platform, others will own the compression of apps, etc). Seniors work within a team and staff tackle ambiguous problems that span multiple teams.

As you progress, you may write less and less code – and talk to humans more than you talk to computers!

But that also depends on the engineering archetype you choose to become. For example:

Coding machines can write large amounts of complicated code quickly.

Fixers are good at jumping into a new code base, finding problems, and fixing them. They're a fire extinguisher kind of engineer.

Product engineers learn a lot more about market dynamics, consumer behaviors, and design patterns – and you'll even get to guide how the product is developed. You'll work with PMs, using your expertise in implementation to inform PMs how long different parts of a project will take – or if they're even feasible to build. Since you understand implementation, you'll also have insights into how to make the product even better.

Architects are the most common staff-level archetypes people know. They're really good at designing larger-scale systems with many moving parts. For example if the product is Google Drive, they'll answer questions like "Where are all the Google docs going to be stored?" "How will spell checking be done?" "Should we host on Amazon or Google?" and think about how all these different moving parts interact with each other.

At Facebook, I was more of a product engineer and am now more of an architect. As an engineer at a start-up though, I had to cover all the roles.

– Former software engineer @ Meta

Part 4. Where can I find internships?

You can find plenty of internships on Prosple. We have a vast selection of internships curated for students like you. Just filter 'til you find the right fit!

For more deep dives into the field of software engineering, check out: