Forem: Arlan

Behavioral Interview Guide for Software Engineers

Arlan — Sat, 04 Jan 2025 04:52:44 +0000

So, you’re looking to improve your chances at getting that offer? The fact that you’re searching, already makes you well on your way! You’ve came to the right place. I’ll share everything I know about behavioral interviews here.

A bit of personal background - I’ve worked in FAANG, startups, mid-sized companies, been in engineering for 7+ years, and done my fair share of interviews. I share everything I know here that I wish someone told me earlier in my career in this blog. (which you can subscribe to btw)

Disclaimer: the information here is my experience and personal opinions.

So What’s the Point Of These Interviews Anyway?

The behavioral interview for software engineers, is just another way for the interviewers to get signal on whether you’ll be a fit for the role. Their aim is to access your career background.

Also, you can’t really memorize your way into it, similar to grinding LeetCode. Of course, that’s not to say you don’t improve your chances if you prepare.

At a high level, these interviews let the interviewer access your abilities holistically. They will be looking for signals that you are talking about topics and situations that a person with a similar role would have been through. They are looking to pick up on the nuances of the experiences that you said you have.

The other agenda of these interviews is to access how you are as a person. Like, will you be pleasant to work with? Do you handle conflict with your potential team mates well? Are you responsible? Do you take initiative? They’re trying to gauge your emotional intelligence.

You’ve Already Been Preparing for This Your Entire Time

Behavioral interviews focus around your career background. So your talking points should be taken from your experience. Since you’ve lived through them, you already have all of the ingredients. Recall all the major projects, initiatives, wins, struggles, and losses that you had. Next, the way you come prepared is to convert them into a STAR (Situation, Task, Action, Result) format. This will help you be light on your feet and, at the right moments, answer from your basket of STARS.

The STAR System

STAR - situation, task, action result. Is a standardized way that a lot of tech companies expect candidates to answer behavioral interview questions with. The aim of this system is make the answers specific to real life events. It puts the focus on facts vs opinions, and removes any generalization.

Situation - What was the problem at hand or a situation at work that you were part of.
Task - What were the next steps to address the situation.
Action - What did you actually do to move the task forward.
Result - What was the end result.

Example:

Situation
- Our VP called out that there was an issue with the app. Too many teams are building features on top of it, and the app is getting slow. It’s hard to build new things. Users are overwhelmed and losing track of new features coming in.
Task
- I realized that the problem looks like a natural scope expansion for my team, and took the initiative at addressing the problem. The solution came in the form of a platform where features can be turned on/off per each user. This meets each unique need of the user. It keeps the app lightweight, features are developed in a standardized way by integrating with a framework, and our dedicated surfaces can render updates about new features to the user.
Action
- I led and took ownership over this initiative.
- Handled engineering design, investigation, estimations, roadmapping, and resource allocation.
- Supported colleague engineers and kept track of the work-stream against milestones.
- Drove product decision alignment discussions.
Result
- Successful Alpha, Beta, General Access roll out.
- Positive metric impact on app time spent and app time to load (ttl).
- This is an example of how the format looks, but the contents themselves vary widely especially based on the role and the expected tenure, so don’t read too much into it.

This is an example of how the format looks, but the contents themselves vary widely especially based on the role and the expected tenure, so don’t read too much into it.

Interviewers are People Too

This is a bit of personal take. It helps to keep in mind that on the other side is a person like you. When doing intros, and answering questions, it helps to have a little humor or share some things that you’re into outside of work. For them, these chats are often like a conveyer. So being personable helps them to remember you as a person.

If You’re Just Starting Out - Internships

Are you trying to score that software engineer internship and get your foot in the door? Since there’s not a lot of prior experience to pull answers from, think about what things you participated in that demonstrate taking initiative. What will show your natural interest in engineering? This includes competitions, side projects, any research, hackathons, etc. The interviewer’s goal is to see that you’re independently making progress towards engineering excellence, and mostly they’re just gauging whether you’ll make a good team mate.

If You’re Already Cooking

You already have a couple years of experience. You’re doing awesome work and delivering value. Part of the behavioral interview is to validate whether you’re pleasant to work with, professional, and responsible. At this point you also have a good amount of experience to form your project based answers. It will help formatting these using the STAR system ahead of interviews. The expectation here is for the interviewer to pick up on your ability to execute on tasks end-to-end, communicate issues and blockers, communicate proactively with steak holders, on-time execution, taking initiative, engineering excellence.

If You’ve Been Around the Block

You’ve been in the industry for a while. Your day to day is more towards dealing with your team’s problems and synthesizing the actual projects that end up on the roadmap, tracking its pace, then keeping everyone aligned though out the process. You’re probably reading this to refresh your memory. Perhaps, reading interview prep materials is a weird hobby of yours? 👀 (no judgement).

The behavioral interview, in my opinion, swings the most weight for senior positions compared to other interviews. A number of nuances can come up in the discussion because, as a senior software engineer, you’ve been through a number of teams, projects, and situations.

Things that interviewers look for

Ability to clearly explain complicated technical problems and topics in a non technical way.
Self agency in your organization to identify gaps and spin up solutions.
Ownership moves more towards the problem or team need, which is often directional and vague, over being project based.
Examples of driving decision alignment among steak holders.
Personal conviction and willingness to pushback.

Software Engineer Behavioral Interview Questions

A good way to prepare is to also review common behavioral questions and form your stories to those. Often, a lot of questions are re-hashes of the same popular ones. Here are the ones I’ve encountered along the way. These should be a good start to get the brain juices flowing!
‍

Think about your career transitions. What motivated them, what went well, and what could have gone better.
‍
Why do you want to work at X company?
‍
Tell me about your largest, most successful, most difficult, least successful projects.
‍
Tell me about of how you’ve taken the initiative on teams you’ve been part of. Where have you gone beyond expectations.
‍
Consider the most difficult work relationships you’ve encountered. How did it go?
‍
Tell me about a disagreement with your manager.
‍
Tell me about a disagreement with your team member.
‍
Tell me about a time when you were not meeting deadlines or expectations from partners. How did you deal with that?
‍
Write about what roles you’ve played on recent teams. How did you end up playing those roles? What has worked out well and what hasn’t been the best fit?
‍
Tell me about a project that you initiated, how did you come up with the project, how did you present it to the team, and how did you convince it was worth it.
‍
Tell me about a time your project got scrapped, how did it happen, how did you react?
‍
What are your expectations from a PM? What’s your ideal relationship with them like?
‍
Tell me about a time your broke something?
‍
What is your weakness.
‍
What is your strength.
‍
Tell me about yourself.
‍
Tell me about a time you received difficult feedback.
‍
Tell me about an ambiguous task you received.

Did This Help?

I hope you found this information helpful. If you want to stay tuned to more engineering content like this, subscribe. It also helps me get the signal that I should write more on the broader topic.

Cheers! ☕

How to Become a Software Engineer: No Experience? No Problem

Arlan — Mon, 23 Dec 2024 02:59:32 +0000

A core profession in the tech industry is software engineering. They are responsible for building the product that gets used by the end customer, moving the business forward.

We live in the 21st century and “software is eating the world.” Due to relevance of software in all industries and people’s everyday lives, being a software engineer is economically rewarding in these times.

And that’s not even mentioning the business leverage that comes from the fact that replicating and distributing software has zero marginal cost.

All this results in 6 figure - 7 figure yearly compensation.

Meanwhile, the culture of tech is really all about “execution.” Generally, no one cares about your school, certifications, diplomas, etc. What companies look for is a track record of getting work done - tracking, managing a work stream to completion, shipping a new product, fixing a major bottleneck in a company system. So as long as you obtain the necessary skills and experience in any way, you can be part of the club.

What Do Software Engineers Do?

Software engineers are technical individual contributors in a company. They execute on technical work streams by building new systems or expanding existing ones that the company owns with the goal to drive positive business outcomes - revenue, engagement, daily actives, etc.

Main responsibilities:

Finishing projects end-to-end.
Getting code published, reviewed, and shipped to production.
High standard of code excellence.
Handling launch + rollouts.
Project impact.
Debugging and fixing bugs.
Effective collaboration and communication.

This is the bread and butter of software engineering responsibilities, however, your day to day expectations evolve and expand through out your software career path. Want to learn all the software engineering roles you’ll be in and their requirements? I wrote a dedicated post just for that. Click Here.

Is Computer Science Degree Required? How to Become a Software Engineer Without a Degree

Job descriptions for software engineers write “bachelors or relevant experience.” So, no it’s not a hard rule. However, you have to have something else to show for it. Something that will give the company a strong signal that you can excel in the job and deliver impact.

In fact, degree requirements serve as a way for the employer to gauge personal qualities - willingness to take responsibility, commitment, and that you will show up everyday. And you can show this in other ways too - with your past working experience.

While I always saw and heard that a degree is not required from job descriptions and my chats with others in the industry, I never truly believed it. Until it actually happened for me.

That being said, the bar is high though. Higher than I anticipated. “Relevant experience” should be actual experience in a software engineering role, doing what software engineers do. Also, it’s important for this experience to come from a real business with a trustworthy brand. The more that’s the case, the better for you.

Real talk, by jumping into software engineering straight, foregoing the popular path, you’re on your own. Getting in that first experience is a slog, it will take time and hustle to get those first opportunities. Even then, you have to be flexible on things like title, or compensation.

All of this, I’m speaking from my experience. I ended up becoming an engineer without a degree right after high school due to the fact that no college accepted me. Read my story here.

How to Break Into the Industry (Entry-level)

Interested in entry level software engineer jobs with no experience? There isn’t a single one way to do this. But, generally, in the beginning the most important thing is to get your foot in the door. So that you can start to build experience and let that snowball into more exciting opportunities. That’s how it turned out for me.

As for getting that first role, it’s really about the hustle - working your network as much as possible, attending meetups and bootcamps, contributing to open source projects. In my opinion, the best way to land a job is through another engineer’s referral who’s already there. Build your network. And don’t be picky about what you get either. Your aim is to get started, you can always move on, down the line.

I got my start when a person gave me a chance at an informal internship with some pay, even though I was ready to do everything for free. But that starting role made all the difference in the end.

Skills Needed for Software Engineer

I list the most foundational skills a software engineer needs to have.

1. Master a Programming Language

We all know that to do software engineering work, you need to know programming languages. Its an engineer’s main tool. You need to pick a language and go deep. Learning all the ins and outs, from syntactic sugars to accompanying standard libraries.

This foundational experience with a single programming language, will end up helping you read and understand code in many other languages as well, because things tend to follow the same pattern.

2. Domain Expert - Front end or Back end?

Engineering and software is a vast field. And a lot of different components go into making software work. Several technologies often have to be combined end-to-end, like front end, server, data storage.

Initially, you start by developing an in-depth expertise in a single domain like front end or back end. You should know all the appropriate programming languages, frameworks, the process of how code gets shipped, how builds/compilations work, and anything else required to make that area of the product work in production.

3. Debugging Skills

A lot of times when you’re building software systems, things fall through the cracks. So you end up dealing with bugs, servers going down, crashes, running out of memory, regressions, etc. Aside from writing code, a big part of the job is reading code, digging into the behavior and understanding what exactly went wrong. It’s a combination of interpreting code behavior. Using internal tools, profilers, and loggers. And poking at individual system components, until the issue is found.

4. Work Stream Execution

This is all about your mindset to deliver on the work steam you own and signed up for. So that in the end everything works end-to-end as designed. It’s a mindset of taking full responsibility and feeling accountable towards your commitments to your team and steak holders.

Issues always pop up from the unknown. It’s important to embrace flexibility and take ownership of figuring out how to work around obstacles. Whether it be bringing in additional resources, or doing a PM’s work.

‍
There are far more skills you need to learn and master during your career than this. If you’re interested, all of them are listed in this post. Read here.

Software Engineer Program No Experience

Interested in getting exact steps to become a full fledged software engineer? What’s great is that this skill can be self taught and you can make amazing progress learning online. Here’s what I would do if I started all over again:

When I was in school, I was really active in competitive programming competitions. It was a ton of fun! I didn’t know that it would help me later on in interviewing and do work as an engineer. So for anyone starting out fresh, here’s how I would recommend getting into software engineering, in my biased opinion.

Pick a popular language like Python, Javascript, Java, Ruby, C++, C#, etc.
Learn the basics of the language - there’s a ton of programming language tutorials online.
Start solving programming problems on leetcode, codeforces, spoj, hackerrank, etc. From easy to hard. Try for a ratio of 10 easy / 3 medium / 1 hard. In the beginning only easy and medium.
- You will develop your CS, coding, and algorithms fundamentals.
- Get comfortable with your programming language of choice.
- Automatic interview preparation.
After you solve 100+ problems at least, start picking up some side projects. Try to build a desktop app, or mobile app, or a website, or a distributed server system. You can start from picking popular projects, that already have guides online, so the learning curve isn’t too steep. Most importantly, you should learn by overcoming blockers that you encounter in your projects.
Continue to build, learn, and get in a role at a startup/company, where you can bring value with your engineering skills.
Get ready for behavioral interviews. I have a guide on that here.

Be Part of the Community

Support from others in the industry is critical. Great roles are usually taken by those that are brought in via referral. In addition to having the skills to walk the walk, knowing people is equally important. So take the time to meet and get to know those in your tech circle.

Furthermore, I remember how just being around folks in the industry, I learned a lot about how the hiring process works. This includes hidden away info that gets transferred only through osmosis most of the time. Some of those things I publish here @ lodely.

Cheers! ☕

All 22 Software Engineer Skills to Master

Arlan — Mon, 23 Dec 2024 02:54:07 +0000

Navigating the path to becoming a top-tier Software Engineer demands a diverse basket of skills and knowledge, which you usually accumulate through experience. However, if I had this software engineer skills list earlier when I was starting out - I would’ve focused on the right things from the beginning. And, as a result, would’ve saved enormous time for myself.

Some concepts here are very straightforward that everyone would expect a software engineer to know, both technical (hard) and more inter-personal (soft). And some, for the longest time I wasn’t even aware of until I found myself needing them, in a pinch, during project work. Nevertheless, I believe all of the items you find here are critical enough to be aware of, regardless of the type of work you do as a software engineer.

Also, including couple of these in the resume wouldn’t hurt! My thoughts on swe resumes.

Top Skills Needed For Software Engineer

This section contains key skills for software developers. These are skills that are acquired right from the start and engineers are expected to have in all work situations.

1. Programming Language Jedi

We all know that to do software engineering work, you need to know programming languages. A programming language to an engineer, is what a brush is to a painter. It all starts from that single language you spend most of your time working in. And that’s the language you would learn all the ins and outs of, from syntactic sugars to accompanying standard libraries. This foundational experience with a single programming language, ends up helping you read and understand code in many other languages as well, as things tend to follow the same pattern.

2. Domain Expert - Front End or Back End?

The more time you spend building software, the more there is to know. There’s a lot of work that goes into making the apps we use every day. And several technologies have to be combined end-to-end - front end, server, data storage.

Initially, you start by developing an in-depth expertise in a single domain like front end or back end first. You would need to know all the appropriate programming languages, frameworks, the process of how code changes get shipped, how builds/compilations work, and anything else required to make that area of the product work in production.

3. Debugging Skills

A lot of times when you’re building software systems, especially complicated ones, things fall through the cracks. So you end up dealing with bugs, servers going down, crashes, running out of memory, regressions, etc. Aside from writing code, a big part of the job is reading code, digging into the behavior and understanding what exactly caused the issues. Its a combination of interpreting code behavior. Using internal tools, profilers, and loggers. And poking at individual system components, until the smallest unit at fault is identified.

4. Work Stream Execution

This is all about your execution to deliver on the work steam you own and signed up for. So that in the end everything works end-to-end as designed. It’s a mindset of taking full responsibility and feeling accountable towards your commitments to your team and steak holders. Issues always pop up from the unknown, it’s important to embrace flexibility and take ownership of figuring out how to work around obstacles. Whether it be bringing in additional resources, or doing a PM’s work.

Technical Skills For Software Engineer

This section contains hard skills that a lot of software engineers become familiar with first hand.

5. Write Your Tests

We all know the classic test driven development! It’s important, especially on complex products, to write and have a suite of tests comprehensively cover the code base. As a result, engineers feel more confident making changes, code is designed in a more modular way, bugs and regressions are caught early.

6. Code Review and Code Standards

Reviewing code helps your whole team to unblock and move faster with quality. Here’s why it’s important: You provide feedback that the author can use to improve their code. You can catch potential disasters early. And additionally, code reviews enforce coding standards for the team, so that comprehensiveness, cleanliness, performance, and modularity is maintained.

This also leaves behind a paper trail of context that engineers in the future can find.

7. Migrations

Many software developers at some point have to handle migrations. In a general sense, it’s taking a system in its current state and moving it into a new one. This could be in the context of data storage, or tech stack, or server infrastructure. Quick tip, there’s a ton of knowledge online on how to approach migrations with different perspectives. Doing a little bit of research goes far, no need to reinvent the wheel.

8. Refactoring

Developing software is an iterative process. Nothing gets built in its final form right from the beginning. Same thing applies to code. Sometimes it’s rushed, or it’s an early new feature experiment that’s not yet state of the art. Afterwards, it’s on us to think through how to redesign our code to meet the needs of the future situation, as well as keeping everything extendable.

Something that would’ve helped me do better early on, is to have confidence in my own intuition. If a piece of code is hard to read or an architecture is complicated. Don’t stop there. The problem is not you, it’s the solution. Take it further, and think about how it would look like if this was easy to understand and was intuitive. You’ll get ideas of gold.

9. Feature Flags and Gating

When you are building new features or products, you have to isolate it from the entire system as you’re making progress on it. Feature flags are your tool for the job. What’s more, they will come super handy for setting up the rules of who gets exposure to your new changes during launch.

10. Distributed Systems

To build scalable systems, it’s important to know how to design distributed systems. I think that even for specific types of engineers that, for example, spend most of their time on the client, would serve greatly to know the fundamental concepts. Because they do come up in interviews, or in situations requiring to talk to the server infrastructure, or thinking through the product behavior. An awesome book, Designing Data-Intensive Applications, comes to mind.

11. Data Bases and Pipelines

Similar to distributed systems, data bases will appear everywhere. It’s one of the core things. It houses all the data and is the source of truth for any system. And where there is data, there’s the need to move them around - the art of writing pipelines.

There’s a ton of information online on types of data bases from sql to no-sql. On frameworks that leverage distributed systems to make pipelines work at scale. On data model design best practices. Research goes a long way.

12. APIs

servers-to-servers, components-to-components, servers-to-clients, talk with each other via a standardized protocol - apis - that you play a role in defining for your specific system. The concept of logic or business logic also go into this. It’s the series of steps the computer follows after getting that first communication established via api. All software engineers go through the experience of writing countless of apis and business logic code.

Advanced Skills For Software Engineer

This section of developer skills are more subtle. They’re things you start to think about further on in your engineering career. Especially, when the question of why build the thing, rather than how, starts to take prevalence.

13. Data Analysis and Metric Reading

Correctness is nice and all. But knowing if the system you built, brings you closer to the goal is crucial. After all, all products and features we ship are at the root - guesses. So it’s important to check, afterwards, whether the guess was right or wrong. This is done by establishing metrics with the idea that it’ll show whether you’re closer or further from the goal.

To feel the pulse of the product, as a doctor would a patient, it’s required to set up logging for data collection, aggregating this data, and finally interpreting from a single place what the data means.

14. Experimentation Setup and A/B Tests

On the topic of metrics and data, experimentations/ab tests fall into the same camp of arming you with evidence of whether your product is bringing you and your team closer to the goal or not.

Simply speaking, experimentation is the process of identifying an audience, providing the default (control) experience to one half, and the experience containing your changes (test) to the other half. Then, we log what people do in both groups and compare how the behavior differs.

This is one of the more exact-science based tools that brings to light the impact of your product’s changes compared to other approaches. So it’s important to really become familiar with how to setup experiments and interpret them.

Since this falls into Statistics territory. There’s a substantial amount of theory that you need to cover, all available online of course. Some things to look out for: statistical significance, p values, power analysis, sample sizes, dilution, over/under/imbalanced exposures, exposure logging, holdouts, backtests, etc.

15. Architecture Design

This is pretty straightforward and a core practice for many software engineers. In-between jumping into coding and aligning on the problem that needs to be addressed. We start off by kicking off an investigation to understand more in-depth the scope of changes required to build the system. All the while, taking notes and jotting down potential hurdles in an eng document. Finally, compiling everything into an outline of the high level approach, how data will flow, what apis there will be, the data model, etc. All-in-all the architecture of the system.

16. Product Led Growth

This falls mostly in the PM camp, but many engineers build products for a living, me included. For us, I think it’s a priority to work on our product sense. While a lot comes just from experience, my personal view on this has been making sure I’m making the time to feel the pulse of the product. i.e. Look at behavior logs and aggregated metrics, read experimentation results and user research reports. I think these are “ammo” for building the next iteration of the product in a data driven way, such that at the end of the work stream, the chance to hit a home run, which metrics should reflect, is maximized.

Overall, I really believe in the product led growth strategy and constantly look to nudge the flywheel. Where making data driven improvements to the product drives user delight, which drives more user advocacy, which drives more new users, and on and on.

17. Managing Technical Risks

During project development, there’s always options for different approaches, there’s always hidden issues that pop up, scope creep, delays. Yet, often we end up having strict timelines with downstream dependencies depending on the launch date.

There’s an art to risk managing a project. It involves consistently going through the exercise of de-risking it from possible derailments. And the approaches vary widely case by case. But some classic ones are - throwing more people at the problem, maximally parallelizing each work item, bring down the scope, setting up contingency plans.

‍

Software Engineer Soft Skills / Leadership

We should all be on the same page that communication trumps all. And effective communication is a powerful tool for getting work done. Here are a list of some soft skills that I consistently observe highly impactful engineers to have.

18. Driving Alignment

As an engineer, you keep in mind a bunch of different factors that affect the project. Because often times, you are the one who exists on the interdisciplinary plane and have to consider both the technical and non-technical details. And understand whether they are fitting together nicely. As a result, you often find yourself in situations where there’s multiple point of views that make a lot of sense in the context of their own product area, but it requires skill to understand each view point and put together a holistic path forward that everyone can agree on.

19. Personal Conviction

Everyone expects the person in the driver’s seat of a project to have a personal perspective on multiple aspects of the project. Having an opinion and sharing it provides value to the team and the project. While there’s a balance to be had, especially with making sure that listening is also being taken into account. Over time, it is more and more important to be willing to share your point of view.

20. Project Tracking

Driving a project with any level of complexity requires tracking. So as a result, gaps are not missed, and major details don’t fall through. Even with extensive tracking, surprises happen. Without it, it’d be a mess. Also, having a way to track a project, acts as a medium letting you align with everyone on the project on what their part of the responsibility is. As a result, keeping everyone on the same page throughout the entire development process.

21. Working with Steak Holders

Software engineers work in teams. Which means also working with non software engineering partners - Design, Data, PM, etc. The success of the product does not only depend on getting the thing built. So it’s important to involve other functional partners closely, especially in product decisions. I’ve observed effective engineers be able to communicate clearly technical challenges in a non technical way, bringing every function to alignment. Resulting in an end-to-end solution spanning engineering, design, and product.

22. Defining and Setting Up Product Launches

Part of project development is to align with your team on what the launch looks like. There’s a number of factors to consider. Who’s going to get this update? How extensive the rollout will be, does it have to work correctly with every other system out the door? Is this alpha, beta, or general launch? How will external communication look like? Will the launch plan result in getting the data needed to make a call on whether there was success vs not? As the one driving the product, it’s on you to cover this and keep everyone on the same page.

‍

Did I Miss Anything? Comment!

Cheers! ☕

How to Get Highest Paying Engineering Jobs in 2024

Arlan — Mon, 23 Dec 2024 02:12:38 +0000

I’m getting close to a decade of work in tech. Living in my tech bubble and talking with friends in the industry, you pick up on hidden playbooks of how engineers get best paying engineering jobs.

And compensation for engineers is a wide spread. Ranging anywhere from low 6 figures to well into 7 figures, in some cases even more. This is because there are multiple levels to compensation within the industry. Plus, there are roles with a lot of asymmetric upside.

In this blog, I talk about different types of compensation ranges that exist and how to achieve them. As well as how to spot roles with asymmetric upside.

Why Do Software Engineers Make So Much?

Relevance and Leverage.

Software is a giant market and it has a significant place in many people’s every day life from work to play to connection. There’s a saying that “software is eating the world,” and at this point, it’s fair to say, “it already ate it.” So the demand is higher than ever.

In terms of leverage, software has zero marginal cost of replication. Which means that its fast and cheap to distribute it across the market. One person can deliver the same positive incremental impact to millions with a single action.

So, the way you set yourself up for maximum wealth generation is to make your financial gains corollate to your company’s leveraged impact. More on that further.

What Type of Engineer is Highest Paid?

Your pay, as an engineer, is determined by 4 factors - level, demand to fill your type of role, location, and the company you choose. Maximizing them will get you maximum pay.

The most obvious and linear increase in compensation is across the seniority levels. You start from entry-level role and through accumulating experience, shipping products, grow to senior and above. I have a dedicated post describing all the different levels, their obvious/non-obvious responsibilities, and compensation - here.
Demand to fill your type of role is pure job market dynamics - supply and demand. Engineering is a broad field and there are more niche job families within: Machine Learning, Embedded, etc. The best way to keep tabs on up to date job market compensation, is looking at other people’s offer packages. You could also speculate and anticipate demand for particular roles, like ML engineering for AI hype. Check out my post on different engineering roles here.
Different locations pay differently. This applies to all jobs. It’s tightly correlated to the region’s cost of living and other broader economic factors. Silicon Valley pays engineers the most, the coasts in the US pay more than the mid west, US pays more than other countries, ad so on.
The company you choose. This is the biggest factor to compensation with the biggest variety of options. There are enterprise, mid-market, and startups companies with each segment having unique compensation packages. In addition, no two companies within the same segment are alike. It’s really a case by case thing. This is where you have to put on your investor hat.

How to Maximize Your Compensation

I’ll tell you the secret to the Silicon Valley Wealth Machine…

But first, I’d like to emphasize that there’s a consistent way to hop between pockets of the job market to guarantee higher compensation. Like moving into the US to places like Silicon Valley or New York. Or going from mid market companies to big tech FAANG.

This way you can go from less than $100k to north of that. And by getting into a particular segment of companies, you can go from low 6 figures to mid-high 6 figures. i.e. $300k, $400k, $500k, $600k, etc.

HOWEVER, the true upside is in EQUITY. Using your investor hat and doing your due diligence can lead you to get rewarded multiple times over. Knowing where the ball is going next in tech is the key. And it doesn’t even have to be all or nothing like that. If there’s truly a good case for growth and impact in that company, then that’s enough.

I’ve had many friends and colleagues that joined high potential companies at a good time and rode the equity appreciation wave going into millions and even occasionally tens of millions.

And all of this - risk free. If you lose, you only incur a marginal opportunity cost.

What is the Most in Demand Engineering Job?

That depends. Demand is dynamic and volatile. It’s all based on tech trends. Right now, I’d probably say AI and ML engineering jobs are most in demand and as a result, they have a lot of leverage in negotiations and compensation discussions. The way to know the most in demand roles at any given time is to do some online research, through tools like levels.fyi and glassdoor.com. See what positions are being paid especially well. Also, just by being in the industry, you’ll start to feel what’s in demand intuitively.

Keep in mind that this does not mean other engineering jobs don’t have high demand. All of tech is incredibly in demand. You just have to bring in relevant experience and expertise.

Highest Paid Entry Level Tech Jobs?

As an entry level software engineer. You don’t have a lot of wiggle room in terms of seniority level. But you can set yourself up for success with location and the company you choose. As a someone new to the industry, you should position yourself to be at the bleeding edge - SF bay area. So that you can maximally expose yourself to all the skills and experience you’ll need throughout your career.

In terms of companies, big techs pay the most in liquid compensation. So if you’re interested in highest paying entry level faang jobs, specifically, checkout the latest info at levels.fyi. But even at entry-level you shouldn’t skimp on high potential companies. Because you do have a shot at crazy asymmetric upside with equity too.

Software Engineer Salary Across the US

Software engineering salaries vary from location to location based on cost of living, talent density, and other broader economic factors.

Software Engineer Salary New York

In New York, software engineers typically earn between $100,000 to $160,000 per year. Salaries can be higher for senior or specialized roles, with cost of living being one of the highest in the country.

Software Engineer Salary California

In California, salaries range from $110,000 to $170,000, depending on the region. Silicon Valley, specifically, sees some of the highest compensation packages, often exceeding $200,000 for senior roles, but the high cost of living, especially in the Bay Area, can offset some of that advantage.

Software Engineer Salary Seattle

Seattle offers competitive salaries for software engineers, typically ranging from $105,000 to $150,000. While the cost of living is high, it is more affordable than California's major tech cities, making it an attractive option for tech talent.

Hope this helps you hit a home run with your next engineering role! Cheers!