How to find a job as a software engineer

Finding a software engineering job takes more than learning a framework and sending out your CV.

You need to find employers who need the work you can do, show them enough evidence to get a conversation, and prepare for the way they assess candidates. When that doesn’t work, you need a way to understand what to change.

This takes effort even when you already have experience. A difficult search doesn’t mean you’re a bad developer. There might be fewer suitable openings, a location restriction, or a gap between what your application shows and what you can do.

AI adds another difficulty. It makes applications and working software easier to produce, while leaving employers with the question of what you can do yourself. For someone trying to get a first job, there is also the worry that the work they would have learned on is being automated.

My advice is to treat finding work as an ongoing project. Keep it small enough to manage alongside your other responsibilities, and use what happens to guide your next steps.

Understand what AI changes about the search

The concern about entry-level work deserves a serious answer. In its August 2026 revision, Stanford’s research on AI and employment found weaker employment for young US workers in occupations exposed to AI, mainly through reduced hiring. The authors describe early evidence, with limitations, rather than proof that AI caused the changes. They found no widespread job displacement across the economy.

That still leaves a difficult problem for beginners. If a team uses AI for the small implementation tasks it once assigned to juniors, where does a new developer get experience? An employer needs to make room for learning. You cannot fix that by polishing your CV.

I’d look for teams that can explain how they train people and give them progressively harder work. A junior title with an expectation that you independently ship production software using AI deserves questions about supervision.

AI also makes it cheap to send large numbers of applications. Greenhouse’s 2025 hiring survey describes recruiters dealing with application volume and concerns about fabricated experience. This is a hiring vendor’s survey, rather than a measurement of every employer, but it helps explain the distrust on both sides.

A rejection doesn’t tell you whether a person read your application. It also doesn’t prove an AI rejected you. Application systems, employer requirements, and human decisions differ. Be wary of anyone selling a universal trick to beat the filter.

My advice is to spend your effort making the match easy to verify. Give the employer a relevant example they can open and ask you about. Keep applying through official channels, and use genuine introductions when you have them. Sending hundreds of AI-written messages creates more work without necessarily making your case clearer.

Decide what work you’re looking for

“A job in tech” is too broad to guide a search.

Start with a role you can explain in one sentence. For example:

I’m looking for a junior web development role where I can work on JavaScript applications, with a team that reviews my code.

Someone with experience might write:

I’m looking for backend work on a small product team, where I can use my experience maintaining APIs and PostgreSQL databases.

You can change this later. For now, it gives you a way to decide which openings deserve your attention.

Write down your constraints too. Work authorization, location, time zone, and the salary you need can rule out a role before the technical requirements matter.

Remote work can be a good fit, including for a first job. Ask how the team mentors people remotely. An office doesn’t guarantee mentoring, and a small team might have nobody available to teach you.

Look beyond software companies. An engineering team inside a retailer or logistics company can do substantial software work. Ask about its budget, practices, and responsibilities before deciding whether it’s a good place to learn.

Read real job descriptions before learning more tools

Collect a small set of openings that fit your constraints. Read what they have in common.

Are employers asking for JavaScript and browser knowledge? Backend APIs? SQL? Experience with a specific industry? Which requirements appear repeatedly, and which belong to one company’s stack?

This is more useful than adding another framework because someone says it’s popular.

You don’t need to match every preference in a job description. If the core work fits and you have evidence you can do it, applying can be reasonable. A strict location requirement or professional license is a different kind of condition from “experience with our preferred testing library.”

For a first job, include internships, apprenticeships, and graduate programs when you’re eligible. Read their application windows and eligibility rules. They aren’t all open year-round.

Don’t wait until you feel completely ready. You can apply while improving your work. The responses will give you information that another month of preparing alone cannot.

Build evidence someone can assess quickly

If you don’t have professional experience, a project can show how you work.

I’d start with one small, finished project relevant to the roles I want. A second can show another useful skill. You don’t need fifteen repositories, and unfinished copies of the same tutorial won’t tell an employer much.

Suppose you’re applying for web development work. A booking app for a local club could show form handling, validation, database work, and deployment. Keep the scope manageable. You don’t need payments, chat, and a mobile app to demonstrate those skills.

Make the project easy to inspect:

• Provide a working demo, or a short recording if hosting it isn’t practical.
• Explain the problem it solves and who would use it.
• Describe your contribution, especially if you worked with other people.
• Write setup instructions that work from a fresh clone.
• Show a few meaningful tests and explain what they cover.
• Describe a limitation or decision you would revisit.

Check the demo before you apply. If authentication is required, provide a safe demo account with fake data. Keep credentials and real customer information out of the repository.

Your README can be short. Something like this gives a reviewer useful information:

This app lets a club member reserve a room. The server rejects overlapping reservations, including when two people submit at the same time. I added tests for that case. The demo uses fictional members and resets its data daily.

Only say those things if your app does them. A modest project you understand gives you more to discuss than a polished application you can’t explain.

If you used a tutorial, credit it and explain what you changed. If you used AI, be ready to walk through the result, find a bug, and make a change yourself. Employers can set their own rules for assessments, so don’t assume the tools you used for the portfolio will be allowed in an interview.

Show how you work with AI

A working demo alone leaves questions unanswered when an agent can generate much of an application. Help the reviewer understand what you contributed and how you checked it.

For the booking app, you could explain how you discovered that two simultaneous requests could reserve the same room. Show the failing test, the fix, and why the database needs to enforce the rule. That gives an interviewer something concrete to discuss, including if AI helped you implement it.

Keep a short account of a real problem you solved. Describe an AI suggestion you changed or rejected if you have one. Don’t manufacture a mistake to make the story convincing.

Learn to use an AI coding tool, but keep practicing without it too. You need to read unfamiliar code and investigate failures when the tool gives you a plausible answer that doesn’t work. Understanding HTTP, SQL, and the language you’re using helps you check what it produces.

If you put AI tools on your CV, explain what you used them for. “Used an agent to draft tests, reviewed the assertions, and added a missing concurrency case” says more than “proficient in AI.” Only use that example if it describes your work. You don’t need to learn every new agent before applying.

Show your work even when the code is private

Experienced developers often can’t publish their most relevant work. That’s normal.

You can describe a system, your responsibility, and the decisions you made without sharing the source code. Use an anonymized case study when your agreements allow it. Explain what the team needed, what you did, and how you checked whether it worked.

Be specific about your part. “Our team migrated the service” and “I wrote the migration checks and handled the rollout” tell a different story from claiming you designed and built everything.

If you have reliable numbers you are allowed to share, use them. If you don’t, describe the outcome plainly. Never invent a percentage because a CV template says every bullet needs a metric.

People changing careers can use relevant experience too. Working with customers, investigating operational problems, or knowing a particular industry can help explain why you’re suited to a role. Connect that experience to the employer’s work.

Write a CV that makes the match clear

The reader should be able to find your relevant experience quickly.

Put your contact details, location, and strongest relevant work near the top. Include working links to your portfolio or GitHub when they add evidence. For a first role, projects and other work experience may deserve more space than a list of courses.

Use straightforward headings and readable formatting. Follow the application portal’s file requirements. After uploading your CV, check any fields it fills automatically, because imported information can land in the wrong place. Microsoft’s application guidance, for example, explains how formatting can affect the information its system extracts.

Compare these hypothetical project descriptions:

Built a full-stack application using modern technologies.

Built a room-booking app with server-side validation and PostgreSQL. Added tests for overlapping reservations and deployed a demo with fictional data.

The second gives us something to assess. It also gives the interviewer questions to ask.

Adjust the emphasis for each role. A backend employer should see the API and database work early. For a frontend role, highlight accessibility, browser behavior, and how you handled the interface.

Use the employer’s terminology where it accurately describes your experience. Don’t paste the whole job description into the CV, hide keywords, or list tools you can’t discuss.

For someone early in their career, I’d try to keep the CV to one readable page. More experience may need more space. Don’t shrink the text to satisfy an arbitrary page count.

You don’t need a personal logo or a complicated portfolio site. A clear page with your work and contact details is enough to start. A blog can help if you enjoy explaining what you learn, but publishing every week is not a condition for getting hired.

Find openings through more than one route

Use job boards to discover roles, then check the company’s own careers page before applying. Check that the opening is still there and that the location and level fit.

Keep a list of employers you would consider. Include companies you already know, local businesses with development teams, and organizations you discover through people or projects you follow.

I’d keep a few especially interesting companies on that list, but I wouldn’t make the whole search depend on three employers happening to have a vacancy.

LinkedIn can help recruiters find you. Make the role you’re seeking and your relevant experience easy to understand. You can also tell trusted former colleagues, classmates, or people you’ve met at events that you’re looking.

Some of my own opportunities came through people I met at conferences. That’s one reason I encourage getting to know people in the field. It doesn’t mean you need to buy expensive conference tickets. A local meetup or an online community where you participate regularly can give you people to talk to.

You don’t need an audience or a daily posting routine. Ask useful questions, share something you learned, and help when you can. Relationships take time, so keep applying through the normal channels while you build them.

Send a short, relevant message

When you contact someone, make it easy to understand why you’re writing.

Here’s an example you could adapt if it matches your situation:

Hi Marta, I saw your team is hiring a junior web developer. I’ve been building JavaScript applications, including a room-booking project with server-side validation. The demo and a short explanation are here. I’m based in Milan and can work in your hybrid arrangement. Would this be relevant to the role, or should I apply through the careers page?

Don’t send that unchanged to every company. Mention the actual role and the work that makes you relevant. If the company asks for applications through a form, use the form.

AI can help compare your CV with an opening or make a sentence clearer. Give it your real experience and check every claim it adds. Keep confidential work and personal documents out of tools you haven’t assessed. Read the final message aloud and remove anything you wouldn’t say yourself.

A cover letter, when requested, should explain the connection between your experience and this job. You don’t need to praise the company for three paragraphs.

If you’re asking someone you know about an opening, give them the role link and a brief explanation of the match. Let them decide whether they can help. Knowing someone can get you a conversation; it doesn’t establish that you’re qualified or guarantee an offer.

Follow the employer’s stated timeline. If you’ve had no response after it passes, one polite follow-up is reasonable. Repeated messages to several employees are unlikely to make the application clearer.

Prepare for the interview you’re actually getting

Ask the recruiter what the process includes before spending weeks preparing for the wrong thing.

Find out the number of stages, the technical format, and whether there is a take-home assignment. Ask which tools and languages you can use, whether documentation or AI assistance is allowed, and how long each stage should take.

For example, Amazon’s software development interview guidance describes coding assessments and preparation across technical topics. GitLab describes a different process, involving a merge-request review and a discussion with coding improvements. Prepare for the process your employer actually uses.

Practice speaking while you work. A friend can play the interviewer. You can also record yourself explaining a project and notice where the explanation becomes vague.

For a coding exercise, begin by checking your understanding. Say what you are assuming, try a small example, and ask about missing requirements. Then implement and test the solution. If you’re stuck, explain what you’ve tried and what you would investigate next.

Prepare real examples for questions about your past work. Give enough context, explain what you did, and describe the result. For a first job, the example can come from a group project, volunteering, or another kind of employment.

AI can help you rehearse questions or review an explanation. Check the feedback yourself. During an assessment, follow the employer’s rules and ask if they are unclear. Microsoft’s candidate guidance distinguishes preparation from outside assistance in assessments, which requires explicit permission. Don’t assume permission because AI tools are used in the workplace.

Set boundaries around take-home work

Before starting, ask what the assignment should demonstrate and how much time you should spend.

Agree on what to leave unfinished when you reach that limit. A README explaining your approach and what remains can be useful evidence of judgment.

An exercise asking you to build a small feature is different from a request to deliver a usable product for the employer. If the scope looks like substantial unpaid production work, ask for a smaller exercise, a paid trial, or another assessment format.

For a paid trial, clarify the scope, payment, and ownership in writing. Consider the time you can afford to spend on one process, especially if you have several underway.

Treat unfamiliar assessment repositories as untrusted code. Inspect the setup instructions and scripts before running them. If you need to run an unfamiliar assessment, use an isolated, disposable environment without your personal files or credentials. Don’t give a stranger access to your accounts.

Interview the employer too

You are deciding whether to work there. Ask questions about the work you would do and the support you would receive.

For a first role, I’d ask who reviews code, how a new developer gets help, and what the first month would look like. “We move fast” tells you less than a description of how changes get reviewed and deployed.

Ask why the position is open. Is the team growing, replacing someone, or taking responsibility for a new system? What would they expect you to accomplish in the first few months?

Ask how the team uses AI in everyday work. Who reviews generated changes? Which tools are approved, and who pays for them? For a junior role, ask who helps when the agent gets stuck. “Everyone has an AI assistant” doesn’t answer the mentoring question. For an AI-led screening interview, ask what is assessed and whether a person reviews the result.

For any level, discuss on-call duties, working hours, remote expectations, and compensation early enough to avoid a long process for a role you couldn’t accept. Ask what the salary range covers and which parts of an offer are variable.

Before accepting, get the important terms in writing and read them. Compare the full arrangement: pay, benefits, location, responsibilities, and the kind of work you would actually be doing. You don’t have to decide during the call where an offer is made.

Keep a record and look for the point where things stop

A spreadsheet or a plain note is enough. Record the employer, role, source link, application date, current stage, and next action. Keep the version of the CV you sent.

After an interview, write a few notes while you remember it. What did they ask? Where did you struggle? Did you learn something that changes whether you want the job?

Review the search regularly. Different problems call for different changes:

If you find few suitable openings, another CV redesign won’t create vacancies. Review where you’re looking and which constraints you can change.

If you’re applying but rarely getting a conversation, ask someone to compare your CV with an actual opening. Can they see the match? Are you applying at the right level? Does the application make your location and relevant work clear?

If you get interviews but struggle in the technical stage, practice that format. If the process stops after project discussions, rehearse explaining your decisions and contribution.

These are questions to investigate, not automatic diagnoses. Employers cancel roles, select internal candidates, or choose someone with more relevant experience. A handful of rejections doesn’t establish a pattern, and employers may not give useful feedback.

Protect your time and watch for scams

Be cautious with unexpected job offers, especially when someone wants money or personal information before you have verified who they are.

The FTC’s job-scam guidance warns about fake recruiters and checks supposedly sent to buy equipment. A check appearing in your balance does not prove it is genuine. Don’t send money back or buy equipment from a supposed employer’s designated seller on that basis.

Verify the recruiter through the employer’s official website or a contact you obtain independently. A familiar company name and logo are easy to copy. Don’t pay a recruiter to secure a job, or send identity documents and bank details through an unverified message.

Give your search a schedule you can sustain. Leave time to rest, and keep a smaller routine for learning or maintaining your project. Spending the whole day refreshing listings can leave you exhausted without improving an application.

If money is urgent, consider a broader range of work that fits your circumstances. A temporary job or adjacent technical role can give you income while you continue searching. Freelancing is another possibility, but it requires finding customers and managing the work; it isn’t an automatic escape from a difficult market.

For your next step, pick one real opening you would consider. Compare its core work with what your application shows. Fix the largest gap you can address now, then send the application.

Want me to talk about your product? You can sponsor this site.