How To Get A Job In 2026

The job market right now is brutal. But most people are spending their time fixing the wrong thing.

You sent 40 applications, got 2 rejections and 38 silences, and now you're sitting there thinking something is wrong with you.

Nothing is wrong with you. The work is probably fine. The presentation layer is not.

Recruiters are not reading you like a book. They scan for a reason to spend another thirty seconds. The resume gets you looked up. LinkedIn checks whether you are real. Your portfolio frames the quality of the work. GitHub is where a technical person can investigate further. If those four surfaces do not work together, the scan stops.

This post is everything I would fix on that layer. How to present yourself. How the resume should change with the company. How to optimize LinkedIn, your portfolio, and GitHub so they read as one person.

I've been a hiring manager and recruiter for over five years, mostly in tech, and I've reviewed hundreds of thousands of applications. This is me talking to you the way I'd talk to a candidate I'm working with directly. The biggest gap I see is not qualification. It is knowing how to present yourself.

What happens after your resume lands

Most recruiters and hiring managers are not reading your profile like a book. They are scanning for a reason to spend another thirty seconds on you. The resume gets you looked up. LinkedIn checks whether you are real. Your portfolio frames the quality of your work. GitHub is where a technical person can investigate further.

This is why the four surfaces cannot contradict each other. If the dates do not match, the company links are broken, or the portfolio looks unfinished, the scan stops. If you do not have famous logos, the work and the framing have to do more of the work for you.

Present yourself properly

Here is where most people immediately blow it. They send the exact same packet to every single company. Same resume, same LinkedIn, same three projects in the same order, 200 times. And you end up looking like everybody else in the stack. Nothing distinctive about you at all.

Just having a resume and firing it at a bunch of roles does not work anymore. Volume is not a metric. The only number that matters is how many high quality presentations you sent: the right framing, for the right team, with work they can actually click.

The presentation layer is four surfaces that have to read as one person. Resume, LinkedIn, portfolio, GitHub. Same body of work. Different job for each surface. If the dates, titles, or company names do not match, or the portfolio looks unfinished, the scan stops.

What you put first still has to change with the company. A founder at 11pm and a recruiter in Greenhouse are not looking for the same signal. The work below is how I would present that work by function.

Now the part that separates you: your work

If there is a website or portfolio field in that application, you fill it in. Every single time.

What is behind that link should be case studies of things you have actually done. Anything not under NDA, anything public that shipped where you have attribution. Design it clean and simple. Nothing fancy.

• Designers: show the process, not just the pretty final screens.
• Engineers: ship something public. A repo, a live tool, something someone can click and actually use. One real working thing beats ten bullet points.
• Marketing and non-technical: people think they cannot do this and you absolutely can. The campaign, the numbers, the before and after, the launch you ran.
• Finance: a model you built, a teardown you wrote, a breakdown of a deal. That is your portfolio.

The point is showing that you do work, and that the work exists somewhere I can go look at it. Your profiles are part of that surface: here is what a recruiter actually sees on your LinkedIn and GitHub.

Yara generates the portfolio per company too, same body of work presented for that specific team.

How to optimize resume

This is the thing most people have never heard. It is not one resume. And it is not a biography. A resume has one job: give the reader a clear picture of what you do and did, so they can visualize you solving their problem on their team.

That means every line should answer: what did you do, for what team, on what surface or feature, with what tools, and what changed because of it. If someone reads your bullet and cannot picture you owning a specific system at their company, the line failed.

Picture the person on the other end. Who is opening this, what are they opening it in, how much time do they have. The reader changes, so the document changes.

Under 50 people. Clean, simple, nice layout. That's it. A human is reading this, probably a founder, probably at 11pm. Make it easy on their eyes.

50 to 150. Mostly the same, but now there's real ATS software in the mix. Greenhouse, Ashby, whatever they're running. Keep it simple and clear. Humans are still doing most of the deciding.

Over 150. Now you switch. Always use the ATS-friendly templates, the boring ones. Serif font, standard sections, standard headers. There are specific format conventions for engineering, design, growth, and you follow them.

A company that size has a mature recruiting process, which means machines and screeners are in the path before a person ever sees you, and a beautiful custom layout is just going to get chewed up.

What they care about changes too

It's not just format.

A recruiter at a large tech company cares more about pedigree. Where you worked, where you studied, the names. That's the filter.

A company in the middle cares more about your work and your projects, but they're still leaning on pedigree as a proxy.

Startups and earlier stage don't really care about any of that. They care about projects and your ability to actually execute. Can you ship, have you shipped. That's the entire test.

Anatomy of a bullet: four parts

Every strong bullet has the same skeleton. Miss a part and the line gets weaker at that step.

1. Verb. Active builder language, not vague contributor language.
2. Surface. The specific team, feature, or system you owned.
3. Mechanism. How you built it, which proves it was actually yours.
4. Outcome. What changed: scale, delta, money, or time.

Watch a payments bullet get sharper at each step. This is the pattern I use when I rewrite resumes:

Before: Worked on the payments system
After: Built the double-entry ledger every payout settles through, authored the RFC and shipped v1 solo, $40M/mo across 2,000 merchants with zero reconciliation breaks

Not every bullet needs a clean number. A page where every line ends in a percentage reads as try-hard. Aim for verb, surface, and mechanism on every line. Add outcome wherever it is true.

Here is the same pattern on work I actually ship at Yara:

Before: Worked on the Yara agent
After: Built the Eve agent runtime integration for Yara chat: 96 tools, durable streaming, billing gates on every LLM call, turn recovery when the browser drops the stream

Before: Contributed to job search features
After: Shipped the chat search orchestrator that turns natural language into ranked role results, p95 under 8s across live search snapshots

Builder verbs, not operator verbs

This is the piece I care about most. Reviewers read your verbs to decide which kind of person you are. The same underlying work passes or fails on that word alone.

Operator verbs (weak): maintained, supported, operated, responsible for, contributed to, worked on, assisted with, helped with.

Builder verbs (strong): designed, built, authored, shipped, owned, founded, rewrote, launched.

A devtools-infra team once told me they wanted people who built products to increase dev efficiency. They passed on a resume that said "DevOps engineer maintaining hyperscale infra." Same candidate pool, different verbs, completely different read.

Before: Maintained CI/CD pipelines serving 400 engineers
After: Built the remote-cache layer for our Bazel fleet, cut median build from 11m to 90s for 400 engineers

Before: Responsible for the apply flow
After: Built the browser-extension apply lane: ATS form detection, autofill from resume data, usage-metered cloud overflow when the extension cannot reach the form

If you actually built something and your resume says you "helped maintain" it, you just talked yourself out of a job you can do. Be that person. Say you built it. Just do not lie about it.

Name the surface

Nobody hires "a backend engineer." They hire the person who built denial prediction, or the runner scheduler, or the ledger core. The test: someone should read your bullet and know exactly which system you would own at their company.

Before: Built ML models for healthcare claims
After: Built the model that flags claim denials before submission, cut denial rate 23% across 40 provider groups

Before: Developed internal tools
After: Built the in-app walkthrough engine: DOM injection, step capture, session replay for onboarding

Before: Worked on creator monetization
After: Owned the payout eligibility service: KYC gates, tax form collection, and the ledger every creator withdrawal runs through

Before: Built portfolio features at Yara
After: Shipped the portfolio codegen pipeline: sandbox builds, preview iframes, and per-audience share links on the public site

Add context: team, product, users

Context fails in two opposite directions, and the fix is opposite too.

Nobody's heard of your company. Your metric is floating in space. One clause fixes it: what the product is, who uses it, at what scale.

Before: Built the matching engine, cut latency 80%
After: Built the matching engine behind a freight marketplace, 3,000 carriers and ~$200M booked a year, cut match latency from 4s to 800ms

Everybody's heard of your company. Now the logo is working against you. "SWE at Meta" makes me assume you owned some small widget on a giant machine. Name the team, the headcount, the corner you shipped.

Before: Software Engineer, BigCo, 2021 to 2024
After: Founding engineer on a 6-person team inside the ads org, built the bid-simulation service every campaign budget runs through

Before: Founder, Yara
After: Founder of Yara (yara.so), AI job-search copilot: chat agent, resume tailoring, portfolio builder, and browser-extension apply for candidates

Quantify the right thing

A number turns a claim into a fact. Most resumes either skip them or reach for vanity metrics.

These land: scale (2,000 merchants, 400 engineers, 200k requests/month), delta (31% to 48%, 11m to 90s), money ($40M/mo settled, LLM spend down 60%), time (p95 12s to 3s, shipped solo in two weeks).

These are noise: lines of code, "10+ projects," meetings run, "improved performance by 80%" with no baseline.

One hard rule: never put a number on your resume you cannot talk about for five minutes. They will ask. An undefendable number is worse than no number at all.

Be specific about AI and ML work

Writing "AI/ML experience" in 2026 is like writing "computer experience." Everybody says it. It filters nothing.

One AI platform team passed on a batch of strong ML-infra profiles because what they actually needed was production agentic systems: custom agent harnesses, tool calling, orchestration loops, evals, multi-agent or semi-autonomous flows, and the latency, cost, and reliability tradeoffs of running frontier models in production.

Three lanes. Name the one you actually did:

• Agentic / LLM application engineering - harnesses, tool calling, durable streaming, turn recovery. This is what most teams are hiring for.
• ML training infra - training pipelines, feature stores, distributed training. A real specialty. Label it, do not blur it into "AI experience."
• RAG and vector plumbing - adjacent, not the same thing. Many teams want to know you built agent loops, not just retrieval.

Before: Used LangChain for LLM features
After: Built a custom agent harness on Eve because LangChain did not fit our tool-approval and billing gates, 96 registry tools with zod schemas and usage metering on every call

Before: ML engineer with LLM experience
After: Built production agentic search for Yara: natural-language job queries, dynamic result tables, snapshot persistence, and subagent routing for long-running research

Timestamp when you joined

When you joined matters as much as where. A bare date range hides it. At a company nearing ten years old, the people with interesting experience are usually the ones who joined sub-50 headcount. Someone who joined in the last year or two of a big name is rarely worth a screen on the logo alone.

Before: Senior Engineer, BigPayrollCo, 2021 to 2024
After: Senior Engineer, BigPayrollCo (joined at ~40 people / eng #12, left at 400), built the multi-state tax engine while the team 10x'd

Before: Employee at fintech startup, 2022 to present
After: Employee #8 at fintech startup (joined at 35 people), owned billing from first invoice to $30M ARR

Joined early? Say the headcount or employee number. Company scaled under you? Say the multiple. Joined late at a big name? Anchor the line to something you built, because the logo will not carry it. Never invent an early-employee number that is not real.

Ownership artifacts beat titles

For senior and staff candidates, titles do not prove ownership. Artifacts do. The question on a clean big-company ladder is: did they own anything, and can they prove it?

Proof that lands: RFCs authored, systems started from zero, conference talks, public postmortems, promotion velocity as a delta (L3 to L5 in three years says more than L5), being the escalation point for other teams.

Before: Senior Engineer, led various initiatives across the platform
After: Senior Engineer, authored the ledger RFC and shipped v1 solo, then led the migration that moved 100% of payout traffic off the legacy path in six weeks

Before: Staff Engineer, platform team
After: Staff Engineer, 0-to-1 owner of the agent runtime: designed tool registry, billing middleware, and durable-stream recovery that cut lost-turn incidents to near zero

"Led various initiatives" is one of the most ignorable phrases in tech resumes. It claims ownership while naming nothing.

Rewrite your bullets tonight

Open each line and answer these five questions inside the sentence:

• What team?
• What tool or stack?
• What surface or system?
• Who used it?
• What moved?

Then find the question a reader would ask next and answer that too. If it names a tool but no impact, add the impact. If it names an impact but no surface, name the surface. If it names a famous employer but no team, name the team.

Tailor your keywords. Pull the actual language out of the job description and make sure it exists in your resume, because at a bigger company that is literally what you're being matched against.

Do not send generic AI slop. I can spot an AI-generated resume instantly. The blue columns, the sidebar, the same three bullet phrasings on every single one. Stay away from templates with a headshot in the top left corner.

What makes you stand out is projects. Real work sitting in the document, not just employment history.

I wrote a full breakdown of resume mechanics, templates, and the before-and-after comparison here. This section is the bullet-writing bar from about 200 hiring manager conversations. Run the checklist above on every line before you send anything.

How to optimize LinkedIn profile

The resume is the entry point. LinkedIn is where people decide whether the resume was telling the truth. It has one job: legitimacy and clarity.

A good LinkedIn profile lets me understand what you did, what you are working on, and where I can see more. It does not make me read three paragraphs under every job.

• A clear profile photo that still works at a small size.
• A clean banner instead of a random technology stock image.
• A simple headline, not a paragraph of every skill you know.
• An About section that is short, specific, and written by a person.
• Experience entries that show what you owned and what changed.
• Projects, publications, or a portfolio in Featured.
• Verification where it is available and useful.

The open to work banner is another one I would avoid. If you want recruiters to know you are open, use the recruiter-only setting. The public banner usually frames you as actively searching before anyone has seen the work. LinkedIn explains the setting here.

Keep the headline simple. "Founding Engineer at Company" is clearer than a long list of technologies. Say what you do and, if there is room, the specific thing you have worked on.

In the About section, answer three questions: what do you do, what have you built, and what are you looking for? Avoid filler like passionate, results-driven, and innovative unless the sentence says something concrete.

For experience, distill what you did on the team and why it mattered. If a sentence could be pasted onto the profile of four thousand other people with the same title, it is not doing much work.

A random IT banner makes the profile feel less intentional.

Verification is a useful trust signal, especially while fake applications and employer scams increase.

No company logo can make a real company look made up. Control the company page and the media attached to it.

A long skill list is harder to understand than a simple statement of what you do.

Nobody wants to read a wall of biography before they know what you actually do.

Distill each role to what you did, what you worked on, and why it mattered.

Featured is where you put the things you actually want someone to click. Your portfolio, your best project, the repo, the case study, or the product you shipped. If Featured is empty, you built the funnel and removed the bottom of it.

LinkedIn profiles I like

These are the profiles I would study if you want to see what this looks like in practice:

• Alex Stauffer: simple explanation of what he does and what he has worked on.
• Bettina: clear profile, clean presentation, and work that is easy to find.
• Scott Bianco: concise profile with the work and background doing the talking.

What I like about these is not that they are identical. It is that I can quickly understand what the person did, what they are doing now, and where to go next. Good work speaks louder than pedigree. Pedigree can help, but it should not be the only reason someone keeps looking.

I broke this down separately in how recruiters actually read your LinkedIn.

How to optimize portfolio

If your company website is good, use it. If it is confusing or it does not show the work, you need your own surface. You cannot control what people assume about your work if the only thing they can click looks unfinished.

The first ten seconds matter. Put the work first. Keep the homepage to three to five strong projects. Write one to three sentences about each one and make the click worth it. A portfolio is not a museum of everything you have ever touched.

For designers, show the process where it helps, not every screenshot you have. For engineers, ship something people can click or run. For marketing, show the campaign and the before and after. For finance, show the model, teardown, or deal work you actually did.

I would avoid device mockups when the actual interface is the point. They make the work harder to see. I would also avoid purple gradients, obvious template layouts, strange side tabs, poor contrast, and any visual style that looks generated before it looks like you.

Device mockups hide the interface. Show the actual work when the interface is the point.

Purple gradients and generic landing-page patterns are easy to recognize and easy to ignore.

A side tab that does not help navigation adds another thing to decode.

Generic AI language and component choices make a portfolio feel generated instead of authored.

Navigation should be obvious. A small interaction detail should not become the whole design.

A laptop outline is not a case study. The work needs to be visible without the prop.

Section labels do not add much when the work itself is not clearly presented beneath them.

Bright cards and large numbers are not a substitute for showing what you actually made.

Do not make availability the main visual on your portfolio. Let the work make the case first.

The best portfolios are easy to navigate and have personality without making the visitor work. Study the ones you like for the principles: clean work layouts, strong writing, real projects, and a clear path from the homepage to the thing you built.

My full breakdown is in how to build a portfolio that gets you hired.

Portfolios I like

These are the references I would send someone who wants to study good portfolio structure. Do not copy the pixels. Look at how the work is organized, how easy it is to navigate, and how much personality comes through without making the site difficult to use.

Engineers

• Shaoruu: technically strong, very unique, and built around a video game feeling.
• Andrew K. Chan: simple navigation and excellent technical writing.
• Thariq: separates professional and personal work, then shows projects and interesting writing.

Product designers

• Csim: clean work layout, thoughtful animation, and strong writing that explains why the work matters.
• ch.sh: a great work layout, strong projects, and a useful stack section for resources, libraries, components, and agencies.
• Rauno: interesting slide and scroll mechanics with a lot of personality.
• Arjun Mahesh: a widget-based layout with an unusual navigation system and simple project explanations.
• Rachel Chen: a unique project presentation with strong thumbnail widgets and a smart collection of work and concepts.
• B. Guillaume: clean graphic design work with a good scroll effect and clear project pages.

Design engineers

• Raphael Salaja: clean projects, easy-to-find skills, and concise writing.
• Jakub Antalik: strong project breakdowns and a very clean Selected Work section.
• Jakub Kr: projects you can actually use, live links, code snippets, and writing that is simple to follow.
• Emil Kowalski: simple project layout, great writing, and real component libraries behind the work.

Portfolio references I would avoid copying

• Priyanka Lakkad: the gradients, scroll behavior, and visual language make the site feel less polished than the work should.
• Apurva Ulabhaje: old product mockups, inconsistent color, and dated interface primitives.
• Wix portfolio template: recognizable template structure and weak hierarchy.
• Econfolio: awkward typography, clipped animation, and a layout that makes the content harder to understand.
• Impeccable's AI slop breakdown: a useful reference for spotting generic AI-generated UI choices.

More portfolio references from my notes

These were also in the original list. They are worth browsing for different ways to present work, especially if you are a design engineer or want a simpler portfolio.

• ethanniser.dev
• bedes.qui.gg
• kiranpa.tel
• floriankiem.com
• joshuawolk.com
• willphan.com
• henryheffernan.com
• bengubler.com
• mammademin.com
• jordienric.com
• edgarlr.com
• paco.me

How to optimize GitHub

GitHub is usually not the first thing a recruiter reads. It matters later, when a hiring manager, engineer, or founder wants to see if you actually build things.

At a high level, what matters is consistent work, good projects, a clean profile, and READMEs that make the projects easy to understand. If you have not used GitHub at work, open source and side projects can make a massive difference.

• Pin the projects you would genuinely want to discuss.
• Write one clear sentence explaining what each project does.
• Use a short README with a screenshot, setup, and a live link when possible.
• Show the decisions you made, not only a list of technologies.
• Link your email, portfolio, and LinkedIn from the profile.
• Open source useful work or skills if that is part of what you do.

Do not optimize for a green graph. I have never seen a hiring decision turn on a streak. A wall of automated commits is worse than a sparse graph because it looks like you are gaming a number.

A profile with no bio, links, or work gives the reader nowhere to start.

The profile should make it easy to connect the account to a real person and their work.

A technology badge wall is decoration. A good project and a clear README are proof.

If your work is private, turn on private contributions so an empty graph does not imply that you stopped writing code. If your GitHub is empty, that is a projects problem, not a profile problem. Build one thing you actually wanted to exist, document it, deploy it if you can, and pin it.

I wrote the technical version separately in do recruiters actually look at your GitHub.

Profiles I like

These are the specific profiles I used as references. The common thread is not a perfect green graph. It is good work, clear projects, simple READMEs, and enough personality that I understand why the person built the thing.

• Jakub Antalik: excellent open source work through Transitions Dev and UI libraries, clear documentation, useful READMEs, and a solid commit history.
• Noah Solomon: concise profile README, projects across LLM fine-tuning and reinforcement learning, and consistent activity.
• Shaoruu: a lot of personality, including a Rust engine for Minecraft, with projects that are genuinely interesting to investigate.
• Raphael Salaja: strong TypeScript projects, a UI wiki, Caligraph, clean READMEs, and open sourced skills that show how he works.
• Jakub Krehel: simple layout, useful skills attached to popular projects, and consistent history without overcomplicating the profile.
• Rasmus Andersson: the Inter font family, CLI work, virtual computer work, and a profile with a clear body of technical work behind it.

Other GitHub profiles worth browsing

• fuma-nama
• pondorasti
• ZeroX-DG
• hunterchen7
• goksu
• Lee Robinson
• dancer
• Paco Coursey
• i-am-henri
• Pedro Duarte
• floguo
• uuuulala
• ahujasid
• aidenybai
• cpcramer
• isidentical
• louisgv
• bcherny
• Jarred Sumner
• pqoqubbw
• Shu Ding
• Andrew Barba
• jordienr
• mufeez-amjad

What does not work on GitHub

• No bio, no social links, and no way to understand who you are.
• Barely any activity and no projects you have actually worked on.
• An extremely long README full of random sections and widgets.
• Projects with no description, no README, and no way to run or view them.

Make the four surfaces one funnel

Your resume should carry the links. LinkedIn should make the work easy to find. Your portfolio should explain the work clearly. GitHub should give a technical person something real to investigate.

Check that the dates, titles, and company names match. Click every link yourself. If someone enters through your resume, can they reach a project they care about in two or three clicks? If not, fix the handoff.

The part that matters most

This is more general than tactical, but I think it might be the most important thing here.

Be confident in yourself. Know that you can do this.

This process is hard, and it feels genuinely jarring when the rejections come in and nothing is going your way. But presenting yourself is an iterative process and you are in control of it. Every single thing in this post is something you can change.

So do not let four rejections or six rejections or however many you're sitting on right now become the story of who you are. Never let that be the core of your identity. It degrades everything downstream. It shows up in how you present your work. A lack of confidence is visible in the first thirty seconds of a profile.

Flip side: don't be so overconfident that you stop improving. There's a balance and you have to find it.

The market is difficult, that's true. There's a flood of AI-generated applications hitting every single posting now, which means the way you compete is not volume. It is presenting yourself better than anyone else in that stack: a resume that matches the company, LinkedIn that proves you are real, a portfolio that makes the work easy to see, and GitHub that gives a technical person somewhere to go.

Don't give up on the first thing that doesn't work. Just improve.

That's the whole presentation layer. That's everything I'd tell you as a recruiter if you were sitting across from me and we were fixing how you show up.

Frequently asked questions