u/devlk Team

Ask specific questions, make it easy to try, and tell people what kind of feedback you want.

When you share a project (here or anywhere):

1. One-line summary: what it is and who it's for.
2. A live link that works in seconds, with a demo login if needed.
3. The code, if you want code feedback.
4. Specific questions, for example:
   • "Is the sign-up flow clear?"
   • "How would you structure this API differently?"
   • "Does the README explain how to run it?"
   • "What would make you actually use this?"
5. Your experience level, so people can pitch the feedback right.

When you receive feedback:

• Thank people, even for criticism.
• Ask follow-up questions instead of defending your choices.
• Look for patterns: if three people mention the same problem, it's real.

Good places for feedback: the weekly Show your project Friday thread in c/showcase, open-source communities, and friends who match your target users.

Building a portfolio for job hunting? Read developer portfolio projects that impress hiring managers.

You don't need to keep up with everything, and nobody does. Focus on depth in your area and awareness of the rest.

A sustainable approach:

1. Know your core deeply: your main language, framework and fundamentals. These change slowly and matter most.
2. Skim, don't chase: a weekly newsletter or two about your stack is enough to notice important changes. You don't need to try every new tool.
3. Learn new things when you need them, for a real project or a problem at work. You'll remember them far better.
4. Set a time budget: for example a couple of hours a week of deliberate learning, not every evening.
5. Prefer fundamentals over trends: databases, networking, testing, system design and clear writing stay valuable for decades.

Signs you're overdoing it: constant anxiety about falling behind, starting many courses and finishing none, or learning eating all your rest time.

Rest is part of getting better. Share what you're currently learning in our learning thread.

Start with the systems you already work on, then learn the core building blocks step by step.

1. Understand your current system: draw how a request flows through your company's application, from client to load balancer to servers, database, cache and queues. Ask seniors to explain the parts you don't understand.
2. Learn the building blocks one at a time:
   • HTTP, DNS and load balancers
   • Databases: indexes, SQL vs NoSQL, replication
   • Caching and when to use it
   • Message queues and background jobs
   • CDNs, rate limiting, consistency
3. Read real architectures: many companies publish engineering blog posts explaining how they built and scaled their systems.
4. Practise classic problems (a URL shortener, a chat app) using a framework: requirements, estimates, API, data model, design, trade-offs.
5. Join design discussions at work: read design documents and ask why decisions were made.

The free System Design Primer is a good structured resource, and our beginner's framework for system design interviews shows how to put it together in an interview.

They can be, for some people, but research carefully before paying.

What a good bootcamp gives you:

• Structure and a clear curriculum.
• Accountability and deadlines.
• Mentors, code review and a peer group.
• Sometimes career support and employer connections.

What it can't guarantee:

• A job. Outcomes depend heavily on your own effort, your projects and the job market.
• Deep fundamentals in a few months; you'll still need to keep learning afterwards.

Before paying, check:

1. Independent outcomes: talk to recent graduates (find them on LinkedIn) about their experience and job search. Be cautious of headline placement rates you can't verify.
2. The curriculum: is it relevant to jobs in your market?
3. Instructors: do they have real industry experience?
4. The total cost and refund policy.
5. The time commitment, and whether you can sustain it.

Free and low-cost alternatives (official documentation, free courses, open-source contributions and building projects) can work just as well if you're disciplined.

Whatever you choose, what gets you hired is real projects and interview preparation. See developer portfolio projects.

It matters less than you think. Pick the one that motivates you, build real things, and learn the basics of the other side along the way.

Frontend first might suit you if:

• You like seeing results immediately and care about design and user experience.
• You want to build things you can show friends and employers quickly.
• Path: HTML and CSS → JavaScript → TypeScript → a framework like React.

Backend first might suit you if:

• You like logic, data and systems more than visuals.
• You're interested in APIs, databases, performance and infrastructure.
• Path: one language (for example JavaScript/TypeScript, Python, Java, C# or Go) → HTTP and REST → SQL and databases → a framework → authentication and deployment.

Either way:

• Learn Git, the command line, HTTP basics and SQL. Every developer uses them.
• Build at least one project that has both a frontend and a backend, even a simple one, so you understand how they connect.
• Check job posts in your target market to see which roles are in demand.

You can always switch later. The skills transfer more than people expect. See how to get your first developer job for the next steps.

Escalate step by step. Stay professional and keep everything in writing.

1. Check the basics: did they receive the invoice? Is it correct, and does it include any PO number or details they require? Sometimes it's simply stuck in their accounts process.
2. Send a friendly reminder shortly after the due date:

Hi [name], just a reminder that invoice [number] for [amount] was due on [date]. Could you let me know when payment is scheduled? Thanks!

3. Follow up firmly a week later, referring to the payment terms you agreed and asking for a specific payment date.
4. Pause work if your contract allows, and tell them politely that you'll resume once overdue invoices are paid.
5. Use the platform's process if you worked through a freelance marketplace. Many have payment protection and dispute processes for eligible contracts.
6. Consider formal options for significant amounts: a formal demand letter, or legal advice. Weigh the cost against the amount owed.

Preventing it next time:

• Take a deposit from new clients.
• Invoice by milestone or monthly, not only at the end.
• Write clear payment terms in the contract.

See how to invoice international clients for a template with payment terms.

Always have something in writing, even if it's a simple agreement over email. Key points:

1. Parties: who you are and who the client is.
2. Scope of work: exactly what you'll deliver, and what's not included.
3. Deliverables and timeline: milestones and dates.
4. Payment: rate or fixed price, currency, payment method, schedule, deposit, and who pays transfer fees.
5. Revisions: how many rounds are included and how extra work is charged.
6. Change requests: how new requirements are quoted and approved.
7. Intellectual property: when ownership of the code transfers to the client (often after full payment), and whether you can reuse generic components.
8. Confidentiality: what you must keep private.
9. Portfolio rights: whether you can show the work publicly.
10. Termination: how either side can end the agreement, and payment for work done so far.
11. Late payments: what happens if invoices aren't paid on time (for example, work pauses).

Tips:

• Templates are a good starting point, but adapt them to the project.
• For large or long-term contracts, a short review by a lawyer is worth it.
• Make sure your invoices match the contract terms; see how to invoice international clients.

Not legal advice. Contract law varies by country.

For your first projects, hourly (or small fixed-price milestones) is usually safer.

Hourly

• ✅ Protects you when the scope is unclear or grows.
• ✅ Simple to explain.
• ❌ Some clients worry about open-ended cost, and you need to track time.

Fixed price

• ✅ Clients like knowing the total cost, and you're rewarded for working efficiently.
• ❌ Risky if you underestimate or the scope keeps growing. Beginners often underestimate.

A good middle ground for beginners: fixed-price milestones.

1. Break the project into small milestones (design, feature A, feature B, deployment).
2. Price each one separately, with a clear written scope.
3. Agree that anything outside the scope is quoted separately.
4. Get paid per milestone.

Whatever you choose:

• Write down exactly what's included and what isn't.
• Agree how many revision rounds are included.
• Ask for a deposit or first milestone payment from new clients.

To work out what to charge, use how to set your rate as a remote developer. To bill properly, see how to invoice international clients.

Upwork offers several withdrawal methods, and which ones are available depends on your country. Check your own account first.

In Upwork, go to Settings → Get paid (sometimes shown as Withdrawal methods). The available options are listed there. Upwork's help pages explain the current fees and limits for each.

Methods commonly available to freelancers in many countries include:

• Direct transfer to a local bank account
• Payoneer
• Wise, in some countries
• Wire transfer (SWIFT) to your bank

Availability, fees and exchange rates change, so compare them in your own account rather than relying on old forum posts.

Things to compare:

• Upwork's withdrawal fee for each method
• The exchange rate you'll get, which often matters more than the fee
• How long it takes to arrive
• Whether your bank charges for incoming foreign transfers

Practical tips:

• Make sure the name on your bank or payment account exactly matches your Upwork account.
• Keep records of every withdrawal for tax purposes. Check current tax rules with the Inland Revenue Department or an adviser.
• Your bank may ask about the purpose of incoming foreign payments; "freelance software services" with invoices or platform statements usually covers it.

If you withdraw from Upwork regularly, share which method works best for you (and when you checked).

Both can work well. It depends on what you value.

Through a local agency or company:

• ✅ Local employment contract and benefits, more stability between projects, local HR support.
• ✅ Easier to get started: they find the clients.
• ❌ Pay is usually lower than the client pays for you, because the agency takes a margin.
• ❌ Less direct relationship with the client; you may be moved between projects.

Directly with a foreign company (as a contractor or through an employer of record):

• ✅ Often higher pay, and a direct relationship and career inside the company.
• ✅ More ownership and visibility.
• ❌ You may handle your own taxes and payments (as a contractor), with fewer protections.
• ❌ Harder to find, with more competition.

A common path: start with an agency or local company working for foreign clients to build experience and references, then move to direct remote roles.

Questions to ask any option: Who is my legal employer? How am I paid, and in what currency? What happens if the project ends?

See how to compare job offers and how to find remote developer jobs from Sri Lanka.

Remote trust comes from visibility and reliability. Make your work and progress easy to see.

First 30 days: learn and set expectations

• Ask your manager: "What does success look like for me in 30, 60 and 90 days?"
• Agree on how you'll communicate: a daily written update, weekly one-on-ones, preferred channels.
• Ship something small early, like a bug fix or a small improvement.

Days 30–60: deliver reliably

• Give short written updates: what you did, what's next, any blockers.
• Flag problems early: "This is taking longer than expected because X. Here are my options."
• Write clear pull request descriptions and document what you learn.

Days 60–90: take ownership

• Own a feature or area end to end.
• Suggest improvements, with reasons.
• Help others in team channels.

Habits that build trust remotely:

• Respond within your agreed hours.
• Be visible in shared channels rather than only in private messages.
• Keep your status and calendar up to date.
• Do what you said you'd do, or tell people early if you can't.

More on remote contracts and working hours: working remotely for a US or EU company.

Many teams work well with about 2–4 hours of overlap, but agree on it explicitly and keep it sustainable.

From Sri Lanka (UTC+5:30), US working hours fall in your evening and night, and the difference changes when the US switches daylight saving time on and off.

Things to agree with your team:

• Which hours you overlap, for example your 7–10 pm with their morning.
• Which meetings you must attend live, and which can be recorded or handled in writing.
• Response-time expectations outside overlap hours.
• How on-call works, if there is any.

Making it sustainable:

• Shift your day rather than extending it: start later and finish later, instead of working a full day and then a night shift.
• Protect your sleep and set clear "off" hours.
• Do your deep-focus work during your own daytime; use the overlap for meetings, reviews and collaboration.
• Push for asynchronous habits (written updates, documented decisions) to reduce the need for meetings.

Before accepting an offer, ask exactly what overlap they expect. Daily work into the early morning is hard to sustain for long. See remote job interviews: questions to ask.

Plan for outages before they happen, and communicate quickly when they do.

Setup:

• A UPS for your router and modem. Even a small one keeps your internet up during short power cuts. Your laptop battery covers the computer.
• A backup internet connection: a mobile data plan on your phone or a separate router, from a different provider than your main connection if possible.
• A charged power bank for your phone.
• For longer cuts: know a nearby place with power and internet (a co-working space or café) you can move to.

Habits:

• Push your work often (commit and push frequently), so nothing is stuck on your laptop.
• Keep a status message or quick-message template ready: "Power cut in my area. I'm on mobile data and may be slower to respond for the next hour."
• Tell your team in advance about scheduled outages.

In interviews, mention your setup when asked about remote work. It addresses a real concern employers have.

More remote-work basics: working remotely for a US or EU company.

Some do, but it's harder. Most remote-first companies prefer people who can work independently.

Why it's harder:

• Juniors need more guidance, which is harder to give remotely.
• Remote roles get many applicants, so companies can choose experienced people.

How to improve your chances:

1. Look for companies with structured mentoring: remote companies with apprenticeship or junior programmes, and teams that mention onboarding and mentorship in their job posts.
2. Build proof you can work independently: open-source contributions with real code review, freelance projects, or projects you planned, built and shipped on your own.
3. Show excellent written communication. Clear READMEs, issue descriptions and messages matter a lot remotely.
4. Consider a hybrid path: start with a local company (in-office or hybrid) for a year or two, then move to remote roles. This is the most common route.
5. Look at local companies serving foreign clients, which can give you international experience with local support.

When you're ready, use the best remote job boards and how to find remote developer jobs from Sri Lanka.

Always ask something. It shows interest, and the answers help you decide whether you want the job.

About the work:

• What would I work on in my first three months?
• What does a typical week look like for this role?
• What's the biggest technical challenge the team is facing right now?

About engineering practices:

• How do code review, testing and deployment work?
• How are technical decisions made, and how much input do engineers have?
• How do you balance new features with technical debt?

About growth:

• How is performance reviewed, and how do promotions work?
• What has helped people succeed in this role?

About the team and culture:

• How long have people on the team been here?
• What's the on-call or after-hours expectation?
• (For remote roles) How much time-zone overlap do you expect, and how does the team communicate?

Avoid asking about salary in early technical rounds unless they bring it up, and don't ask things the website or job post already answers.

Pick two or three questions per interview, and ask follow-ups based on the answers. See also comparing job offers for the questions that matter at offer stage.

Pick a real, work-relevant weakness, show you're aware of it, and explain what you're doing about it.

Avoid:

• Disguised strengths: "I'm a perfectionist" or "I work too hard". Interviewers have heard these many times.
• Weaknesses that are central to the job: "I don't like writing code."
• Very personal topics.

Use this structure:

1. The weakness, stated honestly and briefly.
2. Its impact: how it showed up at work.
3. What you're doing about it, with concrete actions.
4. Progress so far.

Example:

"Earlier in my career I often stayed stuck on a problem for too long before asking for help, because I wanted to figure it out myself. It slowed down a couple of tasks. Now I set myself a time limit, around an hour, after which I write down what I've tried and ask a teammate. It's made me faster, and I've learned a lot more from those conversations."

Use your own genuine example. Follow-up questions will test it.

More behavioural questions are in behavioral interview questions for developers.

Follow the rules they give you. If there aren't any, ask.

• Searching documentation and references (official docs, API references, Stack Overflow for specific errors) is normal. That's how real work is done, and most companies expect it.
• AI coding assistants are a grey area. Some companies explicitly allow them, some ban them, and some ask you to disclose how you used them. If the brief doesn't say, ask: "Are AI coding tools allowed for this assignment?"
• Copying a complete solution from someone else or the internet isn't acceptable, and it usually becomes obvious in the follow-up interview.

The real test: in the review call, you'll be asked to explain your code, justify decisions and often extend it live. If you can't explain something you submitted, that's a red flag, however you produced it.

Good practice:

• Understand every line you submit.
• Mention in the README any significant libraries or references you relied on.
• If you used AI tools and they're allowed, say how you used them.

Our full guide: take-home coding assignments: how to stand out.

Freezing happens to almost everyone. What matters is how you recover.

In the moment:

1. Say it out loud: "Let me take a moment to think this through." Silence feels longer to you than to the interviewer.
2. Go back to the problem: restate it in your own words and work through a small example by hand.
3. Start with brute force: "A simple approach would be X. It's O(n²), but let me get it working and then improve it." Moving forward breaks the freeze.
4. Ask a clarifying question. It's legitimate, and it gives you thinking time.
5. Accept hints gracefully. Interviewers often want to help; using a hint well is a positive signal.

Before interviews:

• Practise solving problems out loud, ideally with a friend or by recording yourself.
• Do mock interviews; the format itself becomes less stressful with repetition.
• Prepare your setup (editor, language, quiet room) so nothing unexpected adds stress.

Remember: interviewers assess your reasoning and communication, not just the final answer. A clear partial solution often scores better than you'd expect.

More preparation tips are in the software engineer interview process.

There's no magic number. Recognising patterns matters far more than how many problems you've done.

Solving 300 problems by memorising answers helps less than understanding about 15 common patterns well:

• Two pointers, sliding window
• Hash maps for counting and lookup
• Stacks and queues
• Binary search (including on answers)
• Trees: traversals, BFS and DFS
• Graphs: BFS, DFS, topological sort
• Heaps and top-K problems
• Intervals
• Basic dynamic programming
• Backtracking

A practical approach:

1. Study one pattern at a time and solve a handful of problems for each, mostly easy and medium.
2. For each problem, explain your approach out loud before coding, and analyse time and space complexity.
3. If you're stuck after 20–30 minutes, read the solution, understand it, then solve it again a few days later without help.
4. Do some timed practice to simulate tests.

Also check what the company actually asks. Many companies, especially smaller ones and remote-first teams, use take-home tasks or practical coding instead of puzzle-style questions. See what to expect at each interview stage.

Compare total value, not the headline number.

A contract rate usually has to cover things an employer would otherwise provide. Before comparing, subtract or account for:

• Paid leave and public holidays. As a contractor you often aren't paid for days you don't work.
• Employer contributions and benefits that local employees receive, such as retirement fund contributions, health insurance and bonuses.
• Taxes you'll handle yourself as a contractor. Check current rules with the Inland Revenue Department or an adviser.
• Payment and currency conversion fees.
• Equipment, internet and backup power.
• Less stability: shorter notice periods and gaps between contracts.

Also think about currency. Being paid in USD protects you if the local currency weakens, but your income in local terms will move as exchange rates change.

Then weigh the non-money factors: learning, the team, growth and work hours.

Our guides to comparing job offers and setting your rate as a remote developer have worked frameworks.

Make the case with evidence of your value and the market, not with threats.

1. Pick the right time: a few weeks before review cycles or budget planning, after a strong delivery, or when your responsibilities have grown.
2. Collect evidence:
   • What you've delivered, with results.
   • New responsibilities you've taken on (mentoring, owning a service, client work).
   • Market data for your role and level, from community salary threads, recruiters and job posts.
3. Ask for a dedicated meeting about compensation.
4. Make a specific request:

"Over the past year I've taken ownership of X and delivered Y. Based on that and what similar roles pay, I'd like to discuss adjusting my salary to [number]."

5. If the answer is no or "not now", ask: "What would I need to achieve to reach that, and by when?" Agree on the goals and a date, in writing.

Keep a running record of your wins (a "brag document") so this is easy each year.

Scripts for offers and raises are in our salary negotiation guide.

You usually don't have to, and it's often better to talk about your expectations instead.

Your current salary may be lower than what the new role should pay, especially if you're underpaid now or moving to a bigger company or a remote role. Anchoring on it can cost you.

What to say instead:

"I'd prefer to focus on the value of this role. Based on my research and experience, I'm looking for a range of [X to Y]. What's the budget for this position?"

If they insist:

• You can politely repeat that you're focused on the range for this role.
• If you choose to share it, mention your full package (bonus and benefits) and explain why your expectations are higher: "My current base is X, but this role has more scope, and the market rate for it is closer to Y."

Never lie about your current salary. Some companies verify it, and getting caught can end the process.

The full approach, including what to do when the offer arrives, is in how to negotiate your developer salary.

Many companies review salaries once a year, but practices vary a lot.

Common patterns:

• An annual review cycle, often linked to performance reviews.
• A review after probation at some companies.
• Promotion raises when you move up a level, usually larger than annual increments.
• Ad hoc increases when someone has a competing offer. (It's better not to rely on these.)

What to do:

1. Ask how it works during the offer stage: "How are salary reviews done, and how often?" Get the answer in writing if you can.
2. Know your review date and prepare evidence of your impact beforehand.
3. Ask clearly if your review is missed or the increase is below market. Our salary negotiation guide has scripts for asking for a raise.
4. Watch the bigger picture. With high inflation, a small increment can still mean a real-terms pay cut.

If increments are consistently skipped despite good performance, read when to switch jobs.

How often does your company review salaries? Share (anonymously) below.

QA is a good starting point. You already understand how software breaks. Make the move deliberate.

1. Move into test automation first if you're in manual QA. Writing automated tests (with Playwright, Selenium, Cypress or the testing tools in your company's stack) means writing real code every day.
2. Learn your company's main stack and read the codebase. Understanding how features are built makes you more useful immediately.
3. Ask to fix small bugs you find, with a developer reviewing your changes. It builds a track record inside the company.
4. Tell your manager your goal clearly and ask what an internal move would require. Internal transfers are often easier than external applications, because people already trust you.
5. Build one or two projects in the stack you want to work in, for your CV.

In interviews, frame your QA background as a strength: you think about edge cases, testing and quality, which many developers don't do well.

See junior to senior developer for what's expected as you grow.

They can help, but they don't replace experience.

When certifications help:

• Cloud, DevOps and data roles, where employers want proof you know a platform.
• Service and consulting companies, which sometimes need certified staff for partner programmes and client requirements.
• Career changers, where a certification shows structured learning in a new area.
• Getting past keyword filters for roles that list them.

When they matter less:

• For general software engineering roles, interviews test what you can build and explain, not certificates.
• A certification without hands-on experience is easy to spot in technical interviews.

How to get the most value:

1. Choose one that matches the jobs you're targeting.
2. Build a real project while studying: deploy something on that cloud, with infrastructure as code if possible.
3. Put the project on your CV next to the certification. The combination is much stronger than either alone.

Check whether your employer pays for exams. Many companies have learning budgets, and it's a good thing to ask about when negotiating an offer.

Be brief, honest and forward-looking. Most interviewers care much less about the gap than candidates fear.

• Give a one- or two-sentence reason. You don't have to share private details. "I took time off for family reasons, and I'm now ready to return full time" is enough.
• Show what you did to stay current, if anything: courses, side projects, open-source contributions, freelance work.
• Move the conversation forward: "…and I'm excited about this role because…"

On your CV:

• Use years only, or months and years, consistently.
• If you built projects or freelanced during the gap, list them; they fill it honestly.
• Don't hide or invent dates. Background checks can reveal it, and dishonesty is a much bigger problem than a gap.

Before applying, refresh your skills with a small project in your stack. It gives you something current to talk about and rebuilds confidence.

Read what to expect at each interview stage to prepare.

Master one first, then broaden.

Employers would rather hire someone who is genuinely productive in one stack than someone who knows a little of five. Depth shows you can build real things, debug hard problems and understand the ecosystem: frameworks, testing, tooling and deployment.

A practical path:

1. Pick one language based on the jobs you want. Look at real job posts in your target market.
2. Go deep: build real projects, learn its standard library, testing tools and common frameworks, and read other people's code.
3. Learn the fundamentals that transfer: data structures, HTTP, SQL, Git, debugging, writing tests.
4. Then add a second language that complements the first. For example, a frontend developer learning a backend language, or a Python developer learning SQL deeply.

Once you know one language well, picking up another takes far less time, because most concepts carry over.

If you're starting out, read how to get your first developer job.

You can build the connection. Just do it respectfully and make it easy for people to help you.

1. Find the right people: search LinkedIn for engineers (not only recruiters) at the company, ideally in the team you're applying to, or people who went to your university.
2. Send a short, specific message. For example:

Hi [name], I'm a backend developer applying for the [role] at [company]. I noticed you work on [team/product]. Could I ask two quick questions about how the team works? If you think I'd be a good fit after that, I'd really appreciate a referral, but no pressure at all.

3. Make it effortless: include your CV, the job link and a two-line summary of why you fit.
4. Engage before asking: comment thoughtfully on their posts, contribute to their open-source projects, or meet them at meetups and online communities.
5. Accept "no" gracefully. Many people will happily refer someone they've actually talked to, but not a stranger who only sent a CV.

Many companies pay employees a referral bonus, so a good referral helps them too.

Make sure your CV is ready first: how to write a developer CV that gets interviews.

One short stint is rarely a problem. A pattern of many short stints can be.

Hiring managers mostly worry about two things: whether you'll leave before you become productive, and whether you stayed long enough to deliver something meaningful.

• One year with a clear reason is fine: better growth, a big pay increase, a layoff, a bad environment, moving to remote work.
• Several jobs of under a year each can raise questions. Be ready to explain them honestly and positively.
• Have results to point to. "In 12 months I shipped X and improved Y" makes the length matter much less.

When asked in interviews, keep it short and forward-looking: "I learned a lot there, especially X. I'm looking for more ownership of Y, which this role offers." Never criticise your previous employer.

Our guide on when to switch jobs lists the signs it's genuinely time to move, and the questions to ask yourself before you do.

Have you changed jobs early? Did it help or hurt? Share below.

Short answer: often no, but it depends on where you apply.

• Many companies hire on skills. If you can show working projects, pass the technical interviews and explain your decisions, plenty of employers (especially startups, product companies and remote-first teams) will consider you without a degree.
• Some employers do filter by degree. Large companies, government roles, and some visa or work-permit processes may require one. Read job posts carefully.
• A degree helps with fundamentals. Data structures, algorithms, networking and databases come up in interviews. Without a degree, you'll need to learn these deliberately.

If you don't have a degree:

1. Build two or three real, deployed projects (see portfolio projects that impress hiring managers).
2. Learn the fundamentals interviews test.
3. Get experience any way you can: internships, open source, freelance work.
4. Use referrals; they help get past degree filters.

Our guide on getting your first developer job without experience covers the full plan.

If you got your first dev job without a degree, or with a degree in another field, share how below.