We all want a good job. But ask people what a good job is, and most say “a good salary” and stop there. If you can’t describe your dream job, you can’t recognise it when you see it, and a company can’t tell that you’re the one they’re looking for.
Hiring works both ways. The company is choosing you, and you are choosing them. This article is about doing your half on purpose: write down what you want, find the companies that match it, and show them, before day one, how working with you will look.
01Write your own list
Nobody else can write this list for you. A job that’s a dream for one person is a nightmare for another. So start with a blank page and be honest.
Here is the top of my list. My dream job is a team where people respect each other, support each other and move in one direction. The opposite is a job of isolated tasks, where you get a ticket and have to figure everything out on your own. I’ve done both, and I know which one makes me do my best work.
To write yours, look back before you look forward:
- What gave you energy? Think of the best week you’ve had at work. What were you doing, and who were you doing it with?
- What drained you? The worst week usually tells you more than the best one.
- What did you learn the most from? Growth often hides in a person, not a project.
- What did you pretend not to mind? Long commutes, constant on-call, silent managers. Write them down anyway.
Then sort everything into three groups. Keep the must-haves short: if everything is a must-have, nothing is.
| Must have | Nice to have | Deal-breaker |
|---|---|---|
| A team that supports each other and shares one goal | A four-day week in summer | Working alone with no one to ask |
| Quality is everyone’s job, not only QA’s | Conference budget | “Just test it before Friday” culture |
| Room to build things, not only run them | Office near a park | Blame after every incident |
This is an example. Your three columns will look different, and that’s the point.
02Turn every wish into something you can check
“A supportive team” is a feeling. You can’t see a feeling in a job post. So for every must-have, decide what it looks like from the outside and what you’ll ask to find out.
| What I want | How to spot it | What to ask |
|---|---|---|
| People support each other | Pairing, code reviews, onboarding docs, people thanked by name in public posts | “When someone gets stuck, what happens next?” |
| One direction, not isolated tasks | The team talks about goals and users, not only tickets | “How does a task get to me, and who decides what matters most?” |
| Respect | How interviewers treat your time, and each other, during the process | “Tell me about a disagreement on the team and how it ended.” |
| Quality is shared | Developers write tests too; QA is in planning, not only at the end | “Who writes tests here, and when does QA first see a feature?” |
| Learning | Engineering blog, talks, internal demos | “What did the team learn this year, and how did it spread?” |
03Find the companies that match
Don’t start from job boards. Start from your list, then look for companies that already show those signals in public.
- Read how they write. Engineering blogs, release notes and job posts show a culture. “You will own” alone in every line can mean you’ll be alone. “You’ll work with” is a better sign.
- Look at their public code. Open-source repos show how they review, how they talk in pull requests and whether tests exist.
- Talk to people who work there. One honest coffee chat tells you more than ten reviews. Ask what a normal week looks like.
- Read reviews for patterns, not stars. One angry review is noise. Five reviews that say “nobody helps new people” is a signal.
- Make a short list. Ten companies you really want beat a hundred applications you don’t care about.
04How does a company know you’re the one?
Honestly, it mostly can’t. A recruiter sees a page of text that looks like hundreds of others. Everyone is “a team player” with “strong communication skills”. An interview is an hour of guessing on both sides.
So stop asking them to guess. Show them. The strongest proof is not a sentence about your work. It’s a small piece of your work, done for them.
05Prepare a demo for them
Pick one small, real slice of their public product and do what you would do in your first week. Some examples:
- QA or SDET: a small automated test suite for their public website, or a short audit of accessibility, broken links and mobile layout, with findings ranked by impact.
- Developer: a small feature or fix idea built on their public API, with tests.
- Designer: one screen of their product, redesigned, with the reasons written down.
- Anyone: a one-page plan for your first 30, 60 and 90 days, based on what you learned about them.
Keep it fair to you and to them:
- Keep it small: a few hours, not a few weeks. It’s a sample, not free consulting.
- Use only what’s public. Never run load tests or security scans against their servers without permission.
- Be kind about what you find. “Here’s what I’d fix first” lands better than “your site is broken”.
- Make it easy to open: a link, a short README, nothing to install.
06Show how working with you will look
The demo shows what you can do. Now show how you do it, because that’s what a team actually lives with every day.
- How you communicate: include the kind of short update you’d send at the end of a week: what’s done, what’s next, where you’re blocked.
- How you ask for help: write down the questions you’d ask their team. Good questions prove you understood the product.
- How you hand things over: a README that someone else can follow without you. That’s exactly the support culture you’re looking for, offered first.
- A short video: a three-minute screen recording that walks through the demo. People who won’t read a document will watch a video.
Send it with a short, personal note: why them, what you built, and one sentence on how you’d like to work together.
07Interview them back
Bring your list to every interview. Ask the questions from step 02, and listen to how they answer as much as to what they say. Do the people interviewing you look like a team that moves in one direction? Do they talk about “we” or only “I”? A great offer from the wrong team is still the wrong job.
08Keep the journey honest
- A no is information, not a verdict. Some companies say no because they aren’t your team either. That’s the list doing its job.
- Update your list after every interview. You’ll learn what you really care about by meeting teams that don’t have it.
- Reuse your demos. Every demo you build is a portfolio piece, even if that company never answers.
- Track it simply: company, why it matches your list, what you sent, what happened, what you learned.
Your checklist
- I wrote my own list: must-haves, nice-to-haves, deal-breakers.
- Every must-have has a signal I can spot and a question I can ask.
- I have a short list of companies that match, not a long list that doesn’t.
- For my top companies, I built a small demo of my work, for them.
- The demo shows how working with me will look, not only what I can do.
- I interview them as carefully as they interview me.
A dream job isn’t something you’re lucky enough to be picked for. It’s a match you define, look for and prove, one step at a time.