how to get a swe j*b in 2026

recently, i was fortunate enough to quit my software engineering j*b. unfortunately, i also had to find a new j*b. this article will go over my experience, and hopefully help you get a j*b of your own.

the search

i applied to 54 companies, mostly targeting senior android engineer roles. the biggest thing to remember here is that job applications are 90% luck. really!

the formula for applying to jobs is something like:

applications * resume pass % * 0.1 (bad luck constant) = # interviews

maximizing the two variables you have control over is what this section will talk about.

resume

most recruiters will spend 10-20 seconds looking at your resume. they'll scan for well known companies/universities and keywords related to the position. if you're lucky, maybe they'll read a couple bullet points. that's it.

because of this, when it comes to resumes, there's not a ton you can do if you have a bad one. however, there's also not nothing you can do. here are a few tips to maximize your chances.

• know your audience - recruiters, even "technical" ones, are not engineers. technical achievements that would impress you and i may not impress them. instead of going extremely in-depth on the technical details of your work, try to focus more on communicating why this work was valuable.

• show impact - every bullet point on your resume should connect back to the value it created for the business. a good format to follow is action verb + task + outcome.

• use numbers - it's very difficult to explain the impact of your work without context. use numbers whenever possible, even if you have to guesstimate.

• don't make mistakes - when a recruiter is looking at your resume, they're looking for any reason to say no. this can be anything, even minor things like typos or broken links. triple check your resume to make sure a dumb mistake doesn't ruin your chances.

POV: you are a well crafted, qualified resume with a minor typo

applying

finding jobs is pretty simple. pretty much every company posts on linkedin - this is where i found 99% of the jobs i applied to. however there are some tricks to where and how you apply.

• try to be first - being one of the first applicants gives you a decent advantage. companies move very slowly. usually when a job is posted, it's not preemptive, but reactive; they need someone ASAP. you can use this to your advantage - i recommend checking linkedin every few days and using the 'date posted' filter.

• quantity > quality - i often hear people say they customize their resume to each position, or even worse... write cover letters. in my experience, this is not worth doing, except for maybe the ~3 companies you're most interested in. applying to jobs is a numbers game, and spending > 1 minute on a single application is almost never worth it.

• always apply with a referral - if you can ofc, continued below

referrals

the offer i ended up accepting didn't have a job posting. i got it because my old manager randomly called me up and told me her team was hiring. this referral not only let me apply to a position that didn't exist, and get past the resume screen. it also helped me throughout the interview process, because i had someone advocating for me.

all that to say, referrals help A LOT. however, there are good referrals, and there are bad referrals. the 'referrals tier list' probably looks something like:

S: old manager who likes you and is now a hiring manager

A: recruiter who has been spamming your DMs on linkedin

B: old coworker you worked closely with

C: old coworker you never really worked with

....

Z: random employee you cold DMed on linkedin

referrals are like pizza/sex, in that even the bad ones are pretty good. however, the good ones can be worth their weight in gold. and good referrals are not made through networking/linkedin BS, but by working closely with someone and staying in touch. that's all you have to do, and it's something you can start doing right now.

if you haven't already done this, however, here are some other ways you can get referrals:

• scour your email/linkedin DMs for messages from recruiters. it doesn't matter how old, or if the recruiter is even still at the company. just having some form of contact can help a ton with getting your foot in the door.

• make cool stuff and post about it. i got ~7 leads from essentially tweeting "i need a job". imagine how many i could've gotten if i posted a project or something to show why i'm worth hiring. people on x (and in general) are very nice and want to help you.

• cold DM people on linkedin. this is the worst type of referral, but it is still a referral. i've gotten at least two people interviews at my old company this way. a polite but direct "hey would you mind taking a look at my resume and potentially referring me to X role" is best here.

the interviews

the next section will go over how to pass interviews. for most companies, the process will look something like:

1. recruiter screen

2. technical screen

3. onsite

4. pray (please please please please please please)

5. offer

this does vary, sometimes there will be online assessments, take home projects, or more/less interviews. however most companies follow this general format.

the recruiter screen

the recruiter will ask you about your experience, and why you're interested in the position. this interview is fake, as long as you're not extremely unqualified or insane you should be fine.

the technical screen

the actual first interview. some general tips for these:

• get to coding as quick as possible. if they ask you to give an intro, make it < 1 minute.

• prioritize completion. for these interviews, there will often be a hard requirement to get a working solution. that should be your first priority, over things like code quality and finding the optimal solution.

• prepare 2 or 3 questions to ask at the end. don't try and make these sound "smart" just come up with a few things you're genuinely curious about.

for me, the technical screen usually fell into one of three buckets. sometimes it was a combination of two. these buckets were:

• leetcode

• practical coding

• technical trivia

leetcode

thankfully, companies are asking these questions less and less. however, they're still something you need to be ready for. all the questions i was asked fell in the easy to medium range, but it's still good to be ready for hards. i also didn't get asked any questions that required knowledge of obscure algorithms/data structures, so i'd worry less about becoming a DSA expert, and more about developing general problem solving skills.

how to prep?

get familiar with basic concepts; basic sorting and searching algorithms, and data structures like graphs, linked lists, stacks, and queues. then, do some problems - the blind 75 is a good starting point. don't just solve the problem, talk through it out loud and time yourself to simulate an interview. once you're done solving it (or give up) look at the solutions on leetcode to see how you could've improved.

practical coding

the questions i encountered most often were more practical coding problems. since i was interviewing for android, these often asked me to build a simple app; usually simplified versions of popular apps (e.g. TikTok, Tinder) or an app that fetched data from an endpoint and displayed it in a list. another common question type was "create a class to do X". for example, a class BankAccount with deposit()/withdraw()/history() methods.

how to prep

thankfully, these types of questions were similar to things i'd do at my job. however, it's still good to practice doing them in an interview. have AI generate some practice problems, then solve them while timing yourself and talking out loud.

technical trivia

these types of questions test your knowledge of whatever domain you're in. for android, they were mostly things like "what is a coroutine", "what is the activity lifecycle", etc. they usually didn't take up the entire interview, and were followed by a leetcode/practical question.

how to prep

these are really the type of thing where you either know it or you don't. however, it doesn't hurt to google or ask AI for some practice questions.

the onsite

the onsite is generally 3-4 interviews over the course of a day or two. it will usually be online, but i did have two that were actually on-site. some general tips:

• give yourself time. i made the mistake of booking onsites on days where i had work, or other interviews. this was a bad idea, as onsites are exhausting. take the day off from work, and don't schedule anything else.

• be someone they'd want to work with. the onsite round is less pass/fail, and more vibes based. show your interviewers that you're interested in their company, ask thoughtful questions, and show them why they'd enjoy working with you.

generally, the onsite will always have these interviews:

• technical

• behavioral

• systems design (if interviewing for a senior role)

then, there's usually one more "curveball" interview. these are more unique to the company, and more difficult to prepare for, so i'm not going to cover them all. however some examples that i had were:

• AI coding

• product sense

• pair programming

another thing a few companies had me do was prepare a take home project, which we then built off in the onsite. for example, the take home would be to build an app, then in the interview we'd add a new feature.

i'll go over each type of interview below.

technical

like the technical screen but harder.

behavioral

"tell me about a time where you did X" questions. also questions about your experience, and why you want to work at the company.

how to prepare?

first, come up with 5-10 anecdotes from work. these should be difficult problems you solved, how you dealt with a difficult situation, or anything really that you're proud of or makes you look good.

next, come up with 5-10 practice questions. things like "tell me about a time when you had a disagreement with a coworker", "tell me about a time you met a tight deadline", etc.

then, match each question to one or more of your anecdotes, and write a thorough response. if this anecdote is from your current job, do some research to get all the details and any metrics.

once you've done all this, you'll have a cheatsheet for behavioral interviews. study this until it's easy to recall and discuss each anecdote, and give it a quick skim before each interview.

systems design

in this interview, you'll be asked to create a high level design for an app. it'll often be something well known, like DoorDash or Twitter. the interview will take place on a white boarding app like excalidraw.

i usually broke these interviews into 3 parts:

1. gather requirements - ask questions. figure out the functional requirements (what does the app do, how many screens, what does each screen do) and non-functional requirements (who is the app for, how many users). list these out before doing anything.

2. list endpoints - write out all the endpoints you'll need. for frontend, these can be a black box, you don't have to go into implementation details. also write out the API/DB models for each piece of data.

3. put everything together - now that you have your requirements and endpoints, you need to create a diagram to show how everything works together. this involves drawing a bunch of boxes and arrows representing screens, endpoints, and other components of your app, and how they connect.

how to prep?

there's a ton of systems design interview resources online, from people who are way more qualified than i am. however, here are some tips from my experience.

get familiar with core systems design concepts. for frontend, some that came up a lot were:

• polling vs websockets vs server side events

• REST vs gRPC vs GraphQL

• pagination (offset vs cursor)

it also helped to watch some practice interviews. for mobile, i recommend this channel.

i also recommend doing some practice interviews yourself. these interviews cover a lot of ground, and it's very easy to mismanage your time.

one more piece of advice - there is a kind of systems design 'template' that lots of interviews use, and most of the interview prep is geared towards. this is stuff like 'design Twitter', where you're creating a small app that has a couple screens and calls a few APIs. most interviews will follow this template, but not all.

i had one interview where i was asked to create a 100% offline app. this threw me off, since i didn't need any of the endpoint/data model stuff i'd been prepping. the interview was much more about seeing how i actually thought through problems, not how well i'd memorized prep videos. at the end of the day, systems design is pretty similar to what you do as a senior engineer, and you can only prep so much.

AI coding

this was a new type of interview that was pretty interesting. i was given a pre-built app, with a list of roughly prioritized bugs/tasks. i was asked to finish as many bugs/tasks as i could, in whatever order i thought made the most sense.

before the interview i was given a prepaid card to buy whatever ai tools i needed, which i used to buy codex credits. the interviewers were fine with me using whatever tools/custom setup i was used to.

the goal of this interview is to see how you actually work. a lot of the focus was on how i problem solved and prioritized different tasks. it's also meant to test how familiar you are with AI tools. at times the interviewer would stop me to ask why i did things a certain way, or ask general questions about how i work with AI.

how to prep?

this interview was the most similar to my day to day work, so there's not much to prep for. i'd suggest reviewing your current AI workflow and thinking about ways it could be improved, or questions that reviewers might ask.

the offer

congrats! you got an offer. if it's an offer you're very happy with, you should just take it. if it's an offer you're only kind of happy with, you should probably still take it, the market's rough. however, if you have multiple offers, and/or are looking to negotiate, this section covers how to do that.

the first, and most important thing to know, is that negotiation requires leverage. if you currently have a job, this gives you some leverage, but the most useful thing is to have competing offers.

another thing to know is that negotiation doesn't start at the offer stage. often recruiters will ask about salary expectations during the first interview. a common negotiating tip here is "never say a number first". i've found this to be a bit impractical. what's worked better for me is "make sure the number you say is at the top of the company's range". this is less catchy but more practical. salaries in big tech are fairly standardized, and you can get a very good idea of how much a company pays from levels.fyi. if it's a startup, do some research on their funding, and assume you can ask you can ask for more equity. you don't want ask for something too low, but you also don't want to ask for something too high, as that may cause the recruiter to write you off. the sweet spot is usually just around/above the max they can offer.

another tip is that 'final' offers are never final. for the first offer i got, i tried negotiating an extra $15k. the recruiter came back and said he could only do $10k. later, i told him i was planning on taking another offer. so he called his manager, who gave me a better offer. declining an offer is never a card you should play if you're not serious, but it is a card that holds a lot of negotiating power.

one thing that is also very helpful is to carefully time your interviews. you won't be able to negotiate, and secure the best offer for yourself, if you finish interviewing with different companies at vastly different times. keep in mind that company size is inversely proportional to speed. for startups, i was able to go from first interview -> final in a week. for bigger companies, the fastest they could do was ~3 weeks. of the offers i got, one had a 24 hour deadline, and one had a 1 week deadline. schedule your interviews accordingly.

one last tip, is that negotiating is not for everyone. it adds a lot of stress, and to be honest, wastes people's time (including yours). i tried very hard to get competing offers, which meant applying to some companies i wasn't as interested in, doing dozens of interviews, and having uncomfortable conversations with recruiters. in the end, i wound up with an extra $10k. this was probably worth it, but it was very stressful, and is not for everyone. the 'apply to a few companies you really like and focus solely on them' strat is definitely worth considering.

the end

idk how to end this. if you got this far, thank you for reading! i really appreciate it. if you have any questions, or disagree with anything, leave a reply or DM me 🙂