This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Alex Eagleson

The Software Industry

In this section I'll be discussing general topics and frequently asked questions as they relate to the web development career space and software industry in general.

These responses will inevitably be a bit more opinionated than the other sections, but I do my best not to state any advice as the "only way". There are an infinite number of different paths you can take to success in this industry, it's all a matter of varying degrees of speed and effectiveness.

The vast majority of it is simply based on my own personal experiences and years spent in online developer communities and forums reading experiences from other developers at similar stages in their career.

How long until I will be ready to apply for jobs?

Everyone is different of course and there is not going to be a single answer that applies to everyone. Some people will have more time in a day to invest into their learning.

Some people will be learning in the evenings / weekends while supporting themselves with another job, others will have the freedom to make learning itself their full time job.

The important thing to remember is that while the process will be faster for some, everyone has the capability to make it eventually if it's something they are genuinely interested in.

My extremely ballpark'd answer for the majority of people would be about one year. For those who can dedicate to learning full time, it could potentially be more like 6 months. Others who are extremely busy and only able to learn a few hours a week might be looking at closer to 2 years.

How do I know when I am ready to apply to jobs?

This is a very common question, and the honest answer is that there is no specific threshold. Some companies are willing to hire people with very limited skills and experience who are willing to learn on the job, other companies have very high requirements for skill level before they are willing to hire someone.

Often there is really no way of knowing which company is strict about the requirements they ask for, and job descriptions unfortunately are notorious for not actually defining the real requirements for the job.

Many jobs that "require 5 years of experience" or "must know Angular" will end up hiring someone with 2 years experience who has never used Angular at all. The reality is that the market is very competitive and companies are often willing to settle for candidates that only tick some of the boxes who have a good attitude and sound like they will be willing to learn and train in the areas they might be missing.

The only way to know is to apply. I'm not saying to start applying right away before you can even put together a basic project, but if you have been learning for 6 months straight and get to a point where you are comfortable with the basics of HTML, CSS and Javascript then I would encourage you to think about applying for positions, even if you don't meet all the requirements.

The "worst case" is you get to practice interviews and get a better understanding of what companies are really looking for. The "best case" is you get hired! Honestly, both cases are a win for you.

For more information on preparing for your first job check out the What are the most important factors in getting hired? section.

Where do I find jobs?

Your best resource will probably be LinkedIn. Keeping your LinkedIn profile up to date is critical for people looking for work.

Start building your professional network however you can. Look for meetups, conferences, and talks in your area. Find ways to connect and start chatting with other developers. Many people find that some random network connection was the key they needed to get into their first job.

Aside from that you should look up companies that you are interested in and view the "careers" page on their website. Often applying to a company directly is an effective tool. Make sure to include the reason the company interests you in your initial point of contact.

If you are a student, do absolutely anything you get to get into an internship or a co-op program. The reality is that the most effective way to get a job is through existing professional experience, and internships and co-ops provide one of the easiest paths to get that experience. Do not pass up that opportunity under any circumstance.

Lastly, while you're learning, remember to showcase your skills. Two great methods to do that are by blogging or recording videos.

You can start to build a respectable network entirely online without actually meeting other developers in person this way.

Remember you don't need to be an expert to write a blog. Keep your topics small and focused on things you have learned, and let the intention be to share what you have learned with others. You might be surprised at some of the contacts and opportunities you can get if you keep it up.

What programming language should I learn?

Why are there so many different programming languages?

This is a great question, and there is no right answer for everyone. It really depends on what kind of work you want to do. You might wonder "why are there so many programming languages?" and the reason is that each different language is particularly good at something.

Python is known for being a great first language to learn, it's good a relatively simple syntax that is easier for beginners to understand, and it has a lot of different practical use cases including task automation, data science (crunching numbers and statistics) and building web servers.

If you want to get into mobile app development, then you'll want to learn Kotlin (for Android development) or Swift (for iOS development).

If your goal is simply to get employed, then Javascript is definitely your best bet. Although it is region dependent (you'll want to search in your local area for what kind of jobs are available) in most parts of the world Javascript (and web development in general) remains the most in-demand skill, and all signs point to it remaining that way for the forseeable future.

Everything these days is web driven, from apps on your phone to home appliances.

Maybe companies use web frameworks to help speed development, organize their code and build apps more efficiently. Some you may have heard of include React, Angular, Vue and Svelte. It's well worth it to learn at least one of these frameworks, but don't jump into them too quick, as each one is built on top of the fundamentals of HTML, CSS and Javascript and typically require a solid working knowledge base of those three in order to learn effectively.

Which framework you choose is up to you, though if you are targeting employment make sure you search the jobs in your area. In the vast majority of the world, React jobs outnumber all other frameworks by a large margin (though there is a sizeable market for Vue in Asia).

If web development doesn't sound like your thing, maybe systems programming is more up your alley (embedded controllers, hardware devices, internet of things (IoT) and etc).

To become a systems programmer there are many paths to take, but most start through the C programming language and build from there. It will be important to have a stronger grasp of computer science fundamentals in this field than in web development since you will be interacting with low level concepts like the operating system and memory directly.

Check out the section called What are the best free resources for learning computer science? to find some great resources on learning systems programming concepts.

What if I fail?

What if I get overwhelmed?

Learning software development is extremely challenging, for everyone. Any dev you see who makes it look easy almost certainly has years of practice and failure behind them, it's no different than any other skill that takes years to develop.

Along the way you are almost certainly going to find days where nothing goes right, or everything seems way too overwhelming and it's impossible to keep up with.

The only advice I can give here is to say that this is perfectly normal and part of the process. Failing at building a project will teach you a lot more about that project then not starting it at all. Sometimes you'll find that you've bitten off more than you can chew, and that's okay.

There's nothing wrong with taking a step back and slowing down. When you encounter a topic that seems too large to digest, see if you can break it down into small pieces. Take a day to learn more about just one small aspect of it. Then move on to the next thing. And the next thing.

And remember, there's no set amount of time when you will have "learned something." New devs often say things like "I'll give myself six months to learn Javascript". It doesn't really work like that. I've been writing Javascript for years and I'm still learning. Your goals should reflect concrete tangible targets, focus on learning specific aspects of the languages, rather than the whole language itself.

What are the most important factors in getting hired?

How do I get a job when all companies want existing work experience?

This is the real question right here. Honestly when it comes to software development, finding your first job will the most difficult stage of your career by a significant margin.

Work Experience

Those who are still students should do absolutely everything they can to take internships and co-op placements, having those will give you a massive leg-up over other devs in your peer group who don't when it comes to full-time hiring after graduation.

If you're looking at bootcamps then make sure you pick one specifically that offers networking support and helps connect you with employers after graduation.

For the rest of us getting into development later in life, the best thing you can do is allow the reality to sink in that it's going to be very challenging, accept it, and do your best not to allow it to deter you.

The vast majority of your applications will be rejected. And that's perfectly okay, it's almost certainly due to a lack of experience, not a lacking in skill or ability on your part.

It's important to train yourself not to take it personally. Rejection does not mean "I'm not good enough" it simply means that particular companies needs didn't align with your skills at that moment.

That's it and nothing more.

The fact is that most companies are risk averse. They see someone new to the field with no proven track record of working for an organization and they don't have the confidence that you have the skills and abilities required to contribute. The reality is that if you think you do, you probably do -- but unfortunately many companies just aren't willing to take that risk.

So since this seems like a catch-22 scenario where you can't get experience, how exactly do you break into the field?

The best advice for new devs is that you have to look at it like a numbers game. If there are 100 companies out there, and 1 of them is willing to take a chance on new devs, then you need to apply to 100 companies to get your job.

Apply like crazy! Come up with a solid but generic resume, and start sending it out. Target all the web dev jobs in your local region, look for companies online that are hiring remote. Make the expectation that most will reject you and be perfectly okay with that.

Every failed interview is experience at interviewing. The more you do the more comfortable you will get. Get your resume into as many hands as possible and do as many interviews as you can.

Be completely honest about your skills. When asked a question you don't know the best answer is always "I'm not familiar with that, but I would love to learn more about it."

All you need to remember is this: you only need one company to say yes, and you're in. Once you've got that, then you'll have work experience, and everything from that point on just gets easier and easier.

Now that we've talked about work experience, let's look at some of the other critical factors at play when it comes to getting hired.

Networking and Relationships

When I say networking I'm not talking about networking I'm talking about networking.

Which is unfortunate because if you're like a lot of people (myself included) learning the OSI model is a lot easier than building a professional network. Like many other things in life, the earlier you start the better off you'll be in the long run.

One of the most helpful things when I started to internalize this was the realization that your network doesn't necessarily mean "people you've met in person". You can build a network entirely online through contacts you make on social networks, reddit, Github, Stack Overflow, Discord, etc.

Particularly with the rise of remote work, you never know if the person you were talking to or helping out online two weeks ago could be the person who connects you with your next job. It happens all the time.

I should clarify that having a network of developers is absolutely not required for finding a job. The good old fashioned method of sending out 100 copies of your resume to 100 different companies still works great too. In fact if your goal is to get employed realistically you should be pursuing both these methods.

If you fancy yourself a writer or a speaker, don't sleep on blogs and Youtube tutorials. It's a common misconception that you need to be an expert. Certainly do your homework, but after spending some time getting confident enough with a small topic (even something as simple as loops or if statements) try writing a blog about it!

This is something many bootcamps heavily encourage students to do. It can be a great way to build confidence and also expand your personal network.

Lastly, don't sleep on LinkedIn. Yes, everyone is on there to self promote, and yes the news feed can be really difficult to stomach. The good news is you don't need to use it for that. Don't even look at it. All you need is your own profile up to date, and with some experience under your belt, the recruiters will be reaching out to you rather then the other way around.

Technical Knowledge and Interview Performance

What can I expect from an interview?

The standards for developer interviews are all over the map.

One company might simply want to chat and talk about projects you have worked on. Another might want to run you through technical aptitude tests. Another might give you a take-home project to work on in your spare time.

You should be prepared for any of these and more. As a junior developer your expectation should be a strong working knowledge of HTML, CSS and Javascript, Git, and the command line.

You'll want to supplement that with whatever additional technologies and tooling the position is asking for. So if they are hiring for a junior React position, obviously you would want to be familiar with the basics of React as well.

I think it's really important to taper your expectations and be ready to encounter scenarios where companies are hiring for junior positions, but after getting into the interview it becomes clear they are actually looking for a very experienced developer with the hopes of only paying them as a junior.

Unfortunately all you can really do in these scenarios is your best, ask lots of questions, be honest about your skills, and don't let it discourage you.

Companies will often be willing to relax their skill requirements a bit if they find someone with a good attitude who appears they are ready and willing to learn. Allow yourself to be that person.

Don't forget you are interviewing them as well. Ask questions to try and get an idea of their workload, company culture, what an average day looks like etc.

And don't hesitate to answer a question with "I don't know".

It's a much better answer than making something up or guessing wrong. You can follow it up with something like "I don't know, but here's something similar I've encountered before" or "I don't know, but here's how I would start looking for the answer if I encountered this".

Interview Styles

Show the interviewer that you are proactive when it comes to encountering situations where you don't know the answer, because as we've already discussed, these situations will happen almost every day in a developers career. Embrace that fact and leverage it in your interview.

Let's take a look at some of the different styles of interviews you might encounter in your job search: Here's a realistic look at three different hypothetical interview approaches at three different companies:

• Company A: Tell me about some projects you've worked on. Tell me about why you chose the tools you did (discussion style).

• Company B: Open up this online browser tool and use Javascript/Python/whatever to reverse a string (whiteboard style).

• Company C: Here's an assignment to build a landing page for a website with an interactive menu. Take it home and work on it and then send us the results tomorrow (take home style).

Of course there are plenty more scenarios, but this captures sort of the three main "styles".

The first (discussion style) is based on a conversation of you discussion your knowledge and experience.

Personally I find these the best for junior positions. Most people starting out have a very difficult time programming while under pressure (even for simple stuff) and given an opportunity to discuss they knowledge, the interviewer can ask questions and probe to make sure they actually understand the things they're talking about.

The second (whiteboard style) may be done with actual code or may be done on a board where you simply use a marker. The interviewer usually isn't necessarily looking for a correct or complete solution, but an approach that shows an understanding of the problem, even if there are minor errors or edge cases.

Also important with this style of interview is the candidates ability to ask good questions and clarify assumptions. Sometimes there will even be missing information in the question intentionally and the candidate is supposed to get that information by asking questions. Despite being a coding challenge, this style of interview is very much focused on a discussion of the problem. Typically, depending on the complexity, you'll want to discuss it for up to half the allotted time before you even begin to write code.

When you get up in the higher levels and more competitive companies (often referred to as FAANG or MANGA companies), these styles of interviews get more common and much more difficult than reversing strings.

If you're interested in pushing for those top tier jobs, check out the DSA, Leetcode and Systems Design section for more information.

The final interview style (takehome style) typically involves giving the candidate a small challenge to do on their own time. This can have the benefit of allowing you to work at your own pace without the pressure of someone watching, but it also has the downside of being time consuming, and the majority of companies will not be paying for your time.

Early in your career I can understand agreeing to take home interviews when you are simply trying to get any job you can, but as you progress in your career you'll find yourself passing on this style of interview as you simply don't have the time to build multiple small projects for companies in your limited spare time. Fortunately this interview style is the least common of the three, and rarely used by the top tech companies.

Soft Skills

Don't sleep on soft skills when it comes to finding a job in the industry. Technical skills will certainly help get you the job, but good soft skills will often fast track you should levels and promotions faster than technical skills alone.

What do I mean when I say soft skills? I'm talking about things like positive attitude, the ability to communicate clearly (both spoken and written) and _willingness to share knowledge and help others.

Good mentors and teachers are often looked on very highly by companies, because it shows you can contribute to improving the level of knowledge and skill within the company. If this is something you have interest and experience in (even if it's just something like blogging or videos) make sure that it's something you share during the interview.

Many companies have what's called a cultural interview as one fo the steps in your interview process. While some companies might state they have metrics to quantify this value, the reality is that many simply evaluate you on their "feeling" about how well you would fit in with the company based on the attitude and disposition you display during the interview.

Education

Do I need to get a degree?

Do I need to go to college?

One of the great things about a career in software development is that it does not require you to complete a four year degree or college program to get hired. I can't speak for percentages, but many companies are more concerned with a candidates skill level and ability to produce working software than their educational background.

I don't want to discount how much of a benefit a university or college degree can bring however. If you are someone who has the time and resources, then in the long term a computer science degree will almost certainly be worth the investment you make into it, for a couple of reasons: First is that there are still many companies out there that do look for a degree before hiring a candidate, and second that the fundamental knowledge you gain in computer science will be incredibly valuable in teaching you problem solving skills that translate directly to work you do in the field.

If you do go the college route one of the biggest benefits career-wise are the co-op and internship programs, do not pass up those opportunities if they are available to you, they are one of the most effective ways of breaking through that initial barrier of getting your first job, which most new devs describe as the most difficult hurdle of their career. See How do I get a job when all companies want existing work experience?.

Still, for those that do not have the means to complete a full degree, if you are motivated and disciplined enough it is absolutely possible to teach yourself everything you need to know through a combination of free online resources and building your own practice projects with the knowledge you gain from those resources.

Another popular option these days is bootcamps. They can be a great middle ground between self teaching and a college degree. They are good for those people who feel they may not be able to motivate or direct themselves enough and benefit from having a very strict curriculum to follow.

Bootcamps have a reputation of being very challenging and being one of those things that really gives back the effort you put into it, so make sure you are ready to invest the huge amount of time (and often money) it takes to get the full benefits. Also make sure you do your research on the quality of the bootcamps, you'll find the full array of well regarded ones and poor quality bootcamps. If possible try to find one that also includes help with job placement as part of the package.

Luck

Let's be honest, when you ask many people how they got their first job they'll say "well, I was lucky..." and proceed to tell some anecdote about their good fortunate.

As they say, luck is the intersection of preparation and opportunity. Many of these people who describe themselves as lucky had done preparation in advance that allowed them to take these opportunities when they presented themselves.

Allow yourself to accept that there's always going to be some luck involved, but you can dramatically improve your chances of that luck finding you if you're well prepared.

Which factors most influence potential income?

I've grouped these two questions together as they often go hand in hand. How much you as a candidate appeal to a company has a direct impact on your potential value.

As you can imagine, this is a very popular question, and like many other complex questions, the most accurate answer is going to be "it depends"... but let's take some time to break down as best we can into exactly "what" it depends on.

Location

Not necessarily a huge factor when it comes to getting a job -- but quite possibly the most important factor when it comes to income. Without a doubt, both average and top end software development salaries the U.S. dwarf pretty much every other country.

That's not to say they aren't still well above average in pretty much every country, it's simply pointing out just how much "above" that already high baseline they are in the U.S. You can still live extremely comfortably as a software developer in pretty much any country in the world.

Here's an aggregate by country from Codesubmit showing the different average values between countries. The actual values themselves are less important than the variance between countries.

For developers in the U.S., here is the data directly from the U.S. Bureau of Labor Statistics directly. Similar metrics from the Government of Canada here.

If you're outside North America you should be able to find data from your government's statistics reporting with a quick Google search.

Of course there are tons of factors that go into total income. Cities with significantly higher salaries also have higher costs of living, and there are many other quality of life considerations to take into account as well.

Nevertheless, even when you account for regional cost of living, there's still pretty much no question that developers whose only goal is to maximize income should be aiming to relocate to the U.S.

That said, this particular advice really only applies to the small subset of folks who aren't already in the U.S. and are also young enough and motivated enough to uplift their entire lives.

For the rest of us (myself included in Canada) there are plenty of other factors listed ahead to consider to help maximize potential earnings without the need to relocate. The rise of remote work is (slowly) shifting the balance and bringing salaries up in non-U.S. countries, and there are more opportunities than ever to work remotely for a U.S. company while living in another country.

Product

What kind of product does the company you're applying to develop? Oftentimes in the tech world, depending on the company's market, they either view software developers as "revenue generating" or an "operating cost".

Not surprisingly, companies that view developers as a source of increased revenue tend to pay more than companies that look at devs as a cost.

Take tech companies like Facebook for example. The more developers hey hire, potentially the more features they can release and the more revenue they can generate. Hiring good devs gives them a direct line to more money, and as such they tend to pay more.

Alternatively consider a major restaurant chain. They need developers of course to manage their websites, maybe the software in their restaurants, and any number of internal tools they build to help manage their company, but ultimately a business like that is going to treat devs more as a "cost of doing business" rather than a source of revenue.

So when seeking higher paying jobs, make sure you are considering the company's product. Is the main product or service they offer software based? If so chances are they're going to value their developers higher than a brick-and-mortar business, and you're likely to get a better offer from them.

Size and Funding

Smaller companies for reasons that should be obviously simply cannot afford to pay the big software salaries that larger companies can.

Working for a small company can be a great experience though, you'll often be able to have a much bigger impact on the product and be involved in more major decisions, but in doing so there is often a price to pay income as compared to the larger companies out there.

That said, an exception to this rule can be small startups that are well funded. When a software focused startup company receives a large round of VC funding, often the biggest chunk of that funding is intended to go directly into hiring more staff to scale their product to a wider market -- so get in there and get your piece!

Base Salary vs Equity

This topic is way bigger than I can possibly go into (and I'm no expert either) so I'll simply link this great blog post on the topic

Suffice it to say that you short of guaranteed stock for an already publicly traded company, you are often best to consider any private equity or options as zero value when it comes to negotiating your salary.

Because in the case of startups (early stage ones in particular) most often that's exactly what it ends up being worth.

Having some ownership in the product you work on is great, but please don't let a company take advantage of you with promises of great value "someday" when they do public. Too many great devs have been burned by this. Make sure you get the base annual salary that you need first, no matter how small the company, if their product is solid they should be able to pay their talent. Full stop.

Once you've got that nailed down, then you can comfortably discuss options on top of that.

What other factors should I consider when applying to a company?

Remote Friendliness

Is the company you're applying to remote friendly? Do they allow permanent work from home? Hybrid model?

Remote work has become more and more common. Even for juniors starting out it's not unrealistic to aim for a remote job.

If it's something that's important to you, make sure you are upfront about it with the company before the interview process begins.

Company Culture

Before beginning the interview or even applying to a company, try and gather as much information you can about what it's like to work at the company.

Ask on developer communities like Reddit, Discord, etc if anyone has experience or anecdotes about what it's like to work for those companies.

Check sites like Glassdoor, Blind and Layoffs.fyi to get accounts from people who have worked at these companies.

try to filter out the most extreme positives and negatives from these sites if you can. Companies can and will find ways to get paid positive reviews. Focus on the ones that sound the most like a "slice of life" honest account if you can. Obviously the bigger the company there more you'll find the easier it will be to get an impression.

Finally make sure you ask in your interview as well. Don't just say "what is your company culture like?" because you'll just get a canned answer.

Ask specific questions like "what time do most developers start and finish work each day?" to try get an idea how much team pressure there might be to "work extra" even if it's not officially "required".

Another great question is "what is your training/onboarding process like?". A question like that can give a good idea whether they've really got their act together when it comes to training new hires, or whether it sounds like you'll just be thrown into a project with nothing more than a "good luck!".

There's tons more of course. Really the questions you want to ask are the ones that reflect things that are important to you. They may not be the same things that are important to someone else. Here's a blog post with some more examples. Consider picking 2-3 that best reflect the kind of work experience you are looking for.

What if I find a job, but it's not what I was expecting?

This section of the post is primarily aimed at those developers who have been been able to find work, but unfortunately find themselves struggling with unrealistic expectations, or pressure to work unpaid overtime, lack of support, or at worst -- straight up verbal harassment including insults, mocking or derision.

Let me tell you straight up so there can be absolutely no misinterpretation: GOOD JOBS, AND GOOD COMPANIES, DO NOT TREAT PEOPLE THIS WAY. EVER. PERIOD. FULL STOP.

There are no exceptions to that statement.

Is it possible that maybe you aren't keeping up, or you are struggling? Absolutely! Maybe it could be that you weren't quite ready for thr job you were hired for. That's an unfortunate reality, but it's not a death sentence.

There are ways of approaching this situation that good managers and good companies will be have plenty of experience with.

One thing I read recently that I think is really critical for developers to remember is this: nothing said in a performance review should ever come as a surprise.

If you wake up tomorrow and have a performance review (whether it's an official one, or simply your manager talking about your performance 1-on-1) and you're told that you've failed to meet expectations, what it really means is that your manager has failed at properly addressing it earlier on when they should have (unless they follow that statement with a plan to support you).

A good manager will approach the topic in a positive way, willing to work with you to come up with a solution. Do you need more training time? More time to shadow other developers? Are the tickets you are being assigned currently too far above your level and you need to spend more time tackling smaller ones to build experience?

These are the kind of questions good companies will encourage managers to ask in performance reviews. You are part of the team and that's how you should expect to be treated.

Following a discussion like this, after whatever the agreed upon period is (whether weeks or months) if you still are unable to work out an approach that helped you work at the level expected of you -- then maybe the tough discussions might start about your fit for the role.

But the key point being made here is that it should never, ever, come as a surprise.

If what I am describing here sounds totally unrealistic or like some kind of "dream company," and you find yourself in a position where you think that mistreatment and unrealistic expectations are the norm -- then I'm happy to tell you that you simply have Stockholm syndrome (I mean that in the nicest way possible).

There are no shortage of companies out there that don't treat people this way.

There has never been a better time to be a developer. I would encourage you to polish off the resume and start your search for that career you deserve.

There's not too many incredibly strong opinions I hold about the industry, but the belief that no matter your skill level that everybody deserves to be treated and spoken to with respect is one of the few complete dealbreakers for me. I'll put up with a lot of stuff, but that's where I draw the line. I think everybody should.

The more we put our foot down for behaviour like that, the more companies will be forced to address it.

Negotiating an Offer

A lot of people will tell you there is no harm in negotiating an offer. That's not exactly true, but it's still good advice.

There's really two most likely scenarios that will occur when you try to negotiate an offer:

• The company will accept or counter (good)
• The company will stay firm at current offer (fine)

Those are the most likely scenarios and since both are options in your favour, that's the reason most people will encourage you to negotiate.

There is a rare third scenario where the company rescinds the initial offer entirely which can happen -- but the most oft repeated advice to that is that "a company that does that probably isn't a company you want to work for anyway."

Whether you should negotiate or not really is a personal choice. I think there are good reasons and scenarios where you might choose not too (the offer is in the range you were expecting and the company is one you are interested to work for.) I personally would never fault someone for accepting an off as-is in that scenario.

Other factors to consider is the amount and your leverage.

A good rule of thumb is 10%. Most companies won't be too surprised if a candidate counters at 10% above the offer that was made to them. If they company is genuinely interested in you, 10% if probably a small price to pay to close the deal.

More than that and you should probably make sure you are confident in yourself and have leverage.

Leverage is basically evidence to show value. The further you are in your career the more track record of proven value you will have and the more leverage you will have. Negotiating up as a new graduate with no experience is possible, but much riskier.

Another way to get leverage is having multiple offers. If you are fortunate enough to have more than one offer from more than one company, and the one you would prefer to work for has offered less, you can use the other offer as leverage in a (very friendly and professional) communication that you have another offer, but would prefer to work for the other company if they would be able to match $X amount.

The final point to note is that when you negotiate or try and leverage multiple offers against each other you have to be willing to lose the offer. That's part of the risk. If you aren't willing to walk away, don't take the risk.

Pay Bands

Make sure you are as familiar as possible with the pay bands (salary range) of the role you are applying to at the company your are interviewing with.

Remember that it's in your best interest not to provide this range yourself as you are much more likely to undersell yourself. Any respectable company or recruiter should be able to provide you with the potential pay range for the role you are applying for, though it may take some pressure on your end to get it out of them, it's well worth it.

If they will not provide you with a range in advance it may be in your best interest to walk away unless you are desperate for the job. Interview processes can be very lengthy and time consuming and there is nothing worth than getting to the offer stage and finding out you had a completely different expectation than the company did.

Be sure to educate yourself in advance using tools like levels.fyi. Remember that software developer pay range is extremely location dependent so you need to ensure you are filtering not only by the company you are applying to, but also your location.

Although levels is the best indicator, particularly for tech companies, you should also make sure to check Glassdoor and Blind as well just to get the most well rounded number you can.

DSA, Leetcode and Systems Design

If your goal is to maximize your income, then you've arrived at your destination.

I mean, full disclosure -- I don't work for a FAANG company. I haven't done the grind myself and don't intend to. I work for a great company and could hardly ask for a better career, but I am familiar with the requirements and can certainly point folks in the right direction for all the resources they need to study to take that leap.

DSA stands for data structures and algorithms.

If you studied computer science in college/university then this is probably old news to you, but if you're someone who has been just learning web development on their own in their spare time it might seem a bit overwhelming. And that's okay! Let's break it down.

In order to understand why DSAs are important you need to kind of take a step back and look at the big picture of software engineering as a whole rather than web development in particular.

Regardless of whether you've learned Javascript, or Python, or C++, or Java, or Rust, or Ruby, or C# or whatever -- each programming language when you boil them down to their core elements is really just a different flavour of approaching the same topic: representing and manipulating data.

How that data is stored covers the data structures part and how it is manipulated falls into the algorithms.

Big tech companies like the FAANG/MANGA crew and similar monoliths are in a very unique position. The small mom and pop shops in your local area have to do a lot of work to seek out developers that can both do all the odds and ends dev work that needs to be done for average to below average pay -- but the big bois can sit back while every new grad and they dog climb over themselves to try to work for them.

This endless supply of potential dev talent means they have the luxury of being a lot pickier about who they hire than most companies.

But how do they decide how to filter out the best of the best?

Well as it happens, they've all done their research, and it seems like the most consistent way of identifying top talent in the software industry isn't necessarily based on work experience or knowledge of any one particular programming language -- it's a candidate's base understanding of fundamental computer science topics like data structures and algorithms.

The idea behind it is that if you can understand the thought processes behind the underlying concepts, the actual language you write the code in is pretty irrelevant.

It's much easier to teach a strong logical thinker how to write Python than it is to teach a Python developer how to think.

So with that background established we've paved the way for the birth of platforms like Leetcode to exist, which despite the stupid name, is unquestionably the most important resource available to you as a developer if your long term goal is to maximize your income.

All the top paying tech companies right now like Amazon, Apple, Facebook, etc draw most of their engineering interview questions directly from the pool of questions listed on this site. Whether similar and adjusted slightly, or in many occasions almost identically word for word.

There's no tricks or cheating involved in having access to them in advance. The whole idea is that they are challenging enough to require weeks or months of practice to internalize the concepts. If you are able to do so successfully then it demonstrates to these companies that you are capable of a level of logical thinking that they expect, and so having the solutions practices and even memorized is enough to identify you as a valuable candidate.

This is what's called the Leetcode grind, and as painful as it can be, it's widely considered to be the most valuable way you can spend your time if your goal is maximizing your income. Grind out a few problems per day, work your way up into the mediums and hards, and you'll be ready for your FAANG interview in no time.

For a new grad or someone with no experience, this is often enough to get your foot in the door. For those developers targeting the higher level positions at the big tech companies you'll also need to spend time studying system design.

Systems design in a nutshell is simply an outline of all the factors you need to consider when building a large scale software system. Consider a trivial example of a website. I make a website with HTML, CSS and Javascript and host it online with Github pages, or purchase some web hosting with Godaddy and upload my files. People love it! Every day I get more and more visitors.

Tomorrow I log on and my site is down. It got too popular! Turns out I only had 1GB of bandwidth with my hosting provider and I blew through it overnight when my site went viral. Damn. How big were the images I was hosting? What was my caching setup? What were my plans for scalability? I didn't have any?

Well no wonder everything fell apart.

In a systems design interview you'll get an example of some kind of business idea or product that might need to be built. You'll be expected to be able to discuss as many factors or considerations that need to be accounted for in building that system.

You'll need to discuss both functional requirements (what features does this product need to support?) as well as infrastructure (how can we handle potentially large amounts of traffic and data storage requirements?).

What solutions are available? What are the pros and cons of each one?

If you're still not sure exactly what we're talking about, here's a couple classic examples based on real interview questions you might encounter on this subject:

• How would you design a parking lot?
• How would you design a URL shortener service?

These videos will give you a great idea of how you will be expected to answer questions like this in a big tech interview.

Lastly, before moving on I should like you with a couple of the foremost standard resources in this space. The book Cracking the Coding Interview is considered the gold standard. It's not free unlike most other resources I've linked, but since you're presumably only here because you're looking to maximize your earning potential, $40 is probably a pretty small price to pay to get you there.

For systems design there are great books too, but honestly YouTube is pretty much your best friend for this one. It's really great to just listen to people walk through their thought process for different problems. Just watch to avoid the crypto shills like TechLead which I will not link out of principle.

A simple rule of thumb to follow is that if the person is only speaking about the topic and answering exactly the subject you searched for, you're probably in good hands. If they're starting or ending their video encouraging you to "check out" something totally unrelated you should proceed with extreme caution.

Good luck! Let me know in a comment if you manage to land a sweet gig :D

This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Alex Eagleson