Developer Job Hunting Guide | Resume, Portfolio & Interview Prep

The Developer Job Process

Getting hired as a developer is not one event — it’s a funnel with real attrition at every stage, and most of the anxiety around job hunting comes from not knowing where you are losing ground. A strong candidate with a weak resume never gets to show their skills in an interview. A strong interviewer with no portfolio never gets past the recruiter screen. Treating the process as a single pipeline, rather than a single “am I good enough” question, makes it much easier to diagnose what to fix when things stall.

1. Resume & LinkedIn    → get past the first filter (ATS + recruiter)
2. Portfolio            → show you can build real things
3. Recruiter screen     → 30min, background and culture fit
4. Technical interview  → coding, system design, or take-home
5. Final/team interview → behavioral, values, team fit
6. Offer & negotiation  → don't leave money on the table

Each stage filters for something different, and each has its own failure mode. Resumes get rejected for formatting and keyword mismatch long before a human judges your actual experience — this is a mechanical filter, not a judgment of your ability. Recruiter screens filter for basic communication and whether your stated expectations (salary, location, seniority) match the role. Technical interviews filter for problem-solving process, not just the final answer. Final rounds filter for whether the team actually wants to work with you day to day. Knowing which stage you keep failing at tells you exactly what to fix: if you’re not getting screens, the resume is the problem; if you’re not converting screens to onsites, it’s usually the portfolio or a mismatch in stated experience level; if you’re failing onsites, it’s interview mechanics, not your underlying skill.

---

Resume

Your resume has to survive two very different readers, and most candidates optimize for only one of them. The first reader is software — an Applicant Tracking System (ATS) like Greenhouse, Lever, or Workday that parses your document into structured fields before any human sees it. The second reader is a recruiter or hiring manager who skims dozens of resumes in a sitting. A resume that beats the ATS but bores the human never gets a callback; a resume that reads beautifully but breaks the parser never reaches a human at all. You need to satisfy both.

What Actually Matters

ATS systems scan for keywords — use the job description's words
Human reviewers spend 6-10 seconds — make it scannable

Format:
  1 page (0-5 years experience)
  Single column
  Standard section headers (ATS-safe)
  No tables, graphics, or images
  PDF format

The mechanical reason multi-column layouts and graphics hurt you is worth understanding, because it’s not a style preference — it’s a parsing failure. Most ATS software extracts text by reading left to right, top to bottom, in the order text boxes appear in the underlying PDF structure. A two-column resume with your skills in a sidebar often gets read as one garbled line mixing the sidebar and the main content, which means the parser either mis-files your skills under the wrong section or drops them entirely. The same applies to text inside tables, icons used as bullet substitutes, and headers/footers — many parsers skip them. This is why “boring” formatting outperforms “designed” formatting for a software job: the ATS is your first audience, and it has no aesthetic judgment, only a parser.

For the human reader, the 6-10 second number comes from actual recruiter eye-tracking studies, and it explains why bullet order matters as much as bullet content. A reviewer typically looks at your most recent title and company, scans your bullet points for numbers and recognizable technology names, and then decides whether to keep reading. If your strongest achievement is the fourth bullet under your second job, it may never be seen. Put your most impressive, most relevant line first in each section, not chronologically last.

Resume Structure

[Name]                     [City, State | Remote]
[Email] | [LinkedIn] | [GitHub] | [Portfolio URL]

SUMMARY (optional, 2-3 lines)
  Full-stack developer with 2 years experience building React/Node.js
  applications. Contributed to open source (1,200+ GitHub stars).

SKILLS
  Languages: TypeScript, Python, SQL
  Frontend:  React, Next.js, Tailwind CSS
  Backend:   Node.js, FastAPI, PostgreSQL, Redis
  Tools:     Docker, GitHub Actions, AWS (EC2, S3, RDS)

EXPERIENCE
  [Company Name] — [Title]                    [Month Year – Present]
  • [Achievement with number, not task description]
  • Reduced API response time by 60% by adding Redis caching layer
  • Migrated 3 legacy services to TypeScript, reducing runtime errors by 40%
  • Led development of user authentication system handling 10K+ daily logins

PROJECTS
  [Project Name] | GitHub: github.com/you/project | Live: project.com
  • What it is and what problem it solves (1 line)
  • Tech stack: React, Node.js, PostgreSQL, Docker
  • Notable achievement: 500+ users, featured in HackerNews, etc.

EDUCATION
  [Degree] | [Institution] | [Year]
  Relevant coursework: Data Structures, Algorithms (if relevant)

A few structural decisions here are deliberate and worth explaining, because candidates get them wrong in predictable ways. The SUMMARY section is optional and should be cut entirely if it doesn’t say anything a reviewer couldn’t infer from the rest of the page — a generic “hardworking team player passionate about technology” line wastes your most valuable screen real estate. Only include a summary if it adds information: years of experience, a specialization, or a notable metric like open-source stars or production scale. The SKILLS section should be organized by category (language, frontend, backend, tools) rather than one long comma-separated list, because a recruiter scanning for “React” or “PostgreSQL” needs to find it in under a second, not read a paragraph. And PROJECTS should sit above EDUCATION for anyone with less than two years of professional experience — hiring managers weight demonstrated work over coursework, and burying your best project below a bachelor’s degree line undersells it.

Writing Strong Bullets

❌ Weak (task):
  "Worked on the frontend using React"
  "Fixed bugs in the API"
  "Helped with database design"

✅ Strong (achievement + impact):
  "Rebuilt checkout flow in React, reducing cart abandonment by 23%"
  "Identified and fixed N+1 query causing 2-second API timeout; reduced to 50ms"
  "Designed PostgreSQL schema for inventory system handling 50K+ products"

Formula: [Action verb] [what you did] [measurable result]

The reason “weak” bullets read as weak isn’t grammar — it’s that they describe a task, and tasks are interchangeable. Every junior developer has “worked on the frontend.” What differentiates candidates is evidence of judgment and impact: what problem existed, what you specifically changed, and what measurably improved because of it. If you genuinely don’t have a hard number — and early in a career, you often won’t — don’t fabricate one. Use a defensible estimate (“reduced page load time noticeably, later confirmed via Lighthouse to be ~40%”) or fall back to scope and outcome (“rebuilt the checkout flow used by all paying customers, cutting reported bugs from 12/month to 2/month”). Interviewers will ask you to explain any number you put on a resume, so only include ones you can defend under a follow-up question — a bullet you can’t explain in the room does more damage than a modest one you can back up in detail.

---

Portfolio

A portfolio exists to answer the one question a resume alone cannot: can this person actually build something end to end, without a manager breaking the work into tickets first? Bootcamp grads and self-taught developers in particular are judged more on portfolio quality than on resume text, because they don’t yet have professional experience to point to — the portfolio is the evidence. Even candidates with a few years of experience benefit from one strong side project, since day-job code is rarely something you can show, and a portfolio piece proves you can make technical decisions independently rather than just execute someone else’s spec.

What to Build

Tier 1 (most impactful — shows real engineering):
  - A SaaS product with actual users (even 10 is impressive)
  - Open source contribution to a known project
  - Tool that solves your own problem and has GitHub stars

Tier 2 (solid, shows full-stack skills):
  - Full-stack CRUD app with auth, DB, deployment
  - REST or GraphQL API with documentation
  - Chrome extension with users

Tier 3 (still useful as learning projects):
  - Tutorial projects (don't make the hero project)
  - Clones (clone Trello, Twitter, etc. — shows you can read real requirements)

What NOT to build:
  - Todo apps (everyone has one)
  - Another weather app
  - Portfolio of portfolio apps

The distinction between tiers is about what each project proves, not how complex the code is. A Tier 1 project — something with real, even tiny, external usage — proves you can ship, handle feedback from actual users, and deal with the unglamorous parts of software (auth, error handling, deployment, uptime) that tutorials skip. A Tier 2 CRUD app proves competence with the fundamentals but not much beyond that, since thousands of bootcamp graduates have built nearly identical ones. This is exactly why Tier 3 projects — todo apps, weather apps, recipe-finder clones — actively hurt you when used as your headline project: a hiring manager who has reviewed hundreds of these can tell within seconds that it’s a tutorial follow-along, and it signals you haven’t yet built anything from your own problem or idea. It’s fine to have one or two Tier 3 projects on GitHub as evidence you practice — just never lead with them.

A concrete example: a candidate with no professional experience but a Chrome extension with 200 active users and a handful of GitHub issues from real users will usually beat a candidate with a computer science degree and five polished tutorial clones, because the extension demonstrates the full loop of building, shipping, and responding to feedback — the actual job.

Making Projects Stand Out

README structure for a portfolio project:

# Project Name — One-sentence description

## Live Demo
[Link to live app] | [Video demo (2-min Loom)]

## What It Does
3 sentences: what problem it solves, who uses it, what makes it interesting.

## Tech Stack
- Frontend: React 18, TypeScript, Tailwind CSS
- Backend: Node.js, Express, PostgreSQL
- Infrastructure: Docker, deployed on Railway

## Key Technical Decisions
- Chose PostgreSQL over MongoDB because the data is highly relational
- Implemented optimistic updates for instant UI feedback
- Added Redis caching, reducing DB load by 70%

## Local Setup
```bash
git clone ...
docker compose up -d
npm install && npm run dev
```

Treat the README as a second resume for that specific project — it’s frequently the only thing a reviewer reads before deciding whether to click through to the live demo or the code. The “Key Technical Decisions” section matters more than it looks: it’s the part that shows reasoning, not just output. Anyone can list a tech stack; explaining why you chose PostgreSQL over MongoDB, or why you added Redis caching after noticing a specific bottleneck, demonstrates the same judgment an interviewer is trying to assess in a system design round — except here you had unlimited time to think it through, so it should be your best, most considered answer. A live demo link is worth disproportionately more than a bare GitHub repo, because most reviewers will not clone and run your code; if they have to set up a local environment to see it work, most simply won’t.

---

Technical Interview Preparation

Companies gate hiring on technical interviews because resumes and portfolios are self-reported — a coding round is the one place where a candidate has to demonstrate skill live, without editing history or outside help. It’s an imperfect test (plenty of good engineers interview poorly under pressure, and plenty of strong interviewers are mediocre day-to-day engineers), but it remains the industry standard, so preparing for the interview as its own skill — separate from being good at the job — is not optional. The three formats below test different things, and most candidates over-invest in one and neglect the others.

Coding Interviews (LeetCode-style)

Study plan (3 months, 1-2 hours/day):

Month 1: Foundations
  Arrays, strings, hash maps, two pointers, sliding window
  Target: Easy problems in 15-20 min

Month 2: Core patterns
  Binary search, recursion, DFS/BFS, stack/queue
  Target: Medium problems in 25-35 min

Month 3: Hard problems + review
  Dynamic programming, graphs, trees
  Practice under timed conditions

Resources:
  NeetCode.io — structured curriculum + video explanations
  Blind 75 list — 75 essential problems
  LeetCode — practice platform

Three months sounds long, but the schedule front-loads pattern recognition on purpose: once you’ve internalized 10-15 core patterns (two pointers, sliding window, BFS/DFS, DP), most “new” problems turn out to be a known pattern wearing a different word problem. Grinding random problems without this structure is why some candidates solve 300+ LeetCode problems and still freeze in an interview — they’ve memorized specific solutions instead of recognizing patterns, and the interview problem is worded just differently enough that pattern-matching fails. Timed practice matters as much as volume: solving a medium problem in 45 minutes at home with no pressure does not predict solving it in 25 minutes with an interviewer watching, so simulate the constraint, not just the content.

# During the interview:
# 1. Clarify constraints before coding
#    "Can the input be empty? What are the value ranges?"
# 2. State your approach before coding
#    "I'll use a hash map to track frequencies — O(n) time, O(n) space"
# 3. Write clean, readable code (not clever)
# 4. Test with examples (including edge cases)
# 5. Discuss time/space complexity

def two_sum(nums: list[int], target: int) -> list[int]:
    seen = {}  # value → index
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i
    return []

Notice that four of the five steps in that comment block happen before and after you write code — that ratio is intentional, and it’s the single most common thing junior candidates get backwards. Interviewers are grading your process, not just whether the final function works, because in a real job you rarely get a perfectly specified problem; you get an ambiguous ticket and have to ask the right clarifying questions before writing anything. A candidate who silently codes a correct solution but never clarifies constraints or discusses complexity often scores lower than one who talks through a slightly rougher solution out loud, because the interviewer has no visibility into how the silent candidate thinks, and “how you think” is what’s actually being evaluated. If you get stuck, narrate the stuck-ness — “I think a hash map gets me O(n) here, but let me check the constraint on input size first” — rather than going quiet, since silence reads as being lost, even when you’re not.

System Design Interviews

Framework (45-minute interview):

1. Clarify requirements (5 min)
   "How many daily active users?"
   "Read-heavy or write-heavy?"
   "Consistency vs availability tradeoff preference?"

2. Capacity estimation (5 min)
   "10M DAU, 100 requests/user/day = 1B requests/day"
   "~12,000 requests/second (10% write, 90% read)"

3. High-level design (15 min)
   Draw: clients → CDN → load balancer → app servers → DB + cache

4. Deep dive (15 min)
   Database schema, API endpoints, caching strategy, scaling

5. Handle bottlenecks (5 min)
   "DB is bottleneck → read replicas → then shard"

Common systems to practice:
  URL shortener, Twitter feed, YouTube, Uber, WhatsApp, Google Drive

System design rounds usually only appear for mid-level and senior roles, or for junior candidates at companies that want early signal on growth potential — so if you’re applying to your first job, this round matters less than nailing the coding interview, and it’s fine to deprioritize it accordingly. The most common failure mode isn’t lack of knowledge, it’s skipping step 1 and jumping straight to architecture. Candidates who launch into “I’d use Kafka and shard the database” before establishing scale, read/write ratio, or consistency requirements are designing a system for a problem they haven’t confirmed exists — interviewers notice this immediately, because real system design always starts from constraints, not from a favorite toolset. The opposite failure, over-engineering, is just as damaging: proposing a multi-region, eventually-consistent, microservices architecture for a problem that a single Postgres instance with a read replica would solve for the next two years of growth signals you don’t yet have production judgment about when complexity is actually warranted.

Behavioral Interviews (STAR Format)

STAR: Situation, Task, Action, Result

Prepare 6-8 stories that cover:
  - Leadership / taking initiative
  - Technical challenge overcome
  - Conflict with a teammate
  - Failure and what you learned
  - Handling ambiguity
  - Collaboration and mentoring

Example:
Q: "Tell me about a time you faced a difficult technical problem."

S: "Our e-commerce checkout was failing for ~5% of users at peak times."
T: "I was tasked with finding and fixing the root cause within 2 days."
A: "I added logging to identify the pattern — all failures were during
    DB writes. Traced to connection pool exhaustion. Implemented PgBouncer
    for connection pooling and increased pool size."
R: "Failure rate dropped from 5% to <0.01%. Also documented the incident
    and set up alerts for connection pool metrics."

Behavioral rounds exist because interviewers are trying to predict something coding rounds can’t measure: whether you’ll handle ambiguity, disagreement, and failure well once you’re actually on the team, since those situations happen constantly and are rarely covered by a leetcode-style test. Preparing 6-8 stories in advance is not optional polish — it’s the difference between answering fluently and freezing, because behavioral questions feel conversational but are actually being scored against a rubric, and “I don’t really have an example of that” is a worse answer than a mediocre one. Reuse the same story for multiple questions when it genuinely fits (a single well-chosen incident can answer “technical challenge,” “handling ambiguity,” and “failure” depending on which part you emphasize), but be ready for the interviewer to dig one level deeper than your prepared answer — “what would you do differently now?” or “how did your teammate react to that?” — so know your stories well enough to improvise inside them, not just recite them. Honesty matters more than polish here: interviewers who ask for a story about failure are specifically listening for genuine ownership of a mistake, and a story where “the failure” is thinly disguised as someone else’s fault reads as evasive rather than self-aware.

---

Job Search Strategy

Where to Apply

Tier 1 (higher interview → offer rate):
  Employee referrals — ask everyone you know
  LinkedIn connections at target companies
  Recruiter outreach responses

Tier 2 (solid volume):
  Company career pages (bypass ATS at smaller companies)
  LinkedIn Jobs
  Indeed

Tier 3 (high volume, lower conversion):
  AngelList / Wellfound (startups)
  Glassdoor
  Built In (tech hubs)

Specialties:
  Remote: Remote.com, We Work Remotely, Remote OK
  Startups: YC Job Board, AngelList
  Freelance: Toptal, Upwork, Gun.io

The tiers above are ranked by conversion rate, not availability, and the gap between them is large enough to change your strategy entirely. A referral effectively skips the resume-screening stage, because someone inside the company is vouching that you’re worth a recruiter’s time — this is why referred candidates convert to interviews at multiples of the rate of cold applications, even when the resume is identical. That means the highest-leverage use of your time is often not submitting more applications, but messaging two or three people you know (or can reasonably reach through alumni networks, past coworkers, or open-source collaborators) at companies you’re targeting and asking if they’d be willing to refer you. Cold applications through job boards still work and should make up the bulk of your volume, but treat Tier 3 boards as a numbers game where a 2-5% response rate is normal, not a sign something is wrong with your resume.

Realistic Numbers: What the Funnel Actually Looks Like

It helps to know the shape of the funnel before you’re in the middle of it, because the raw numbers can feel discouraging without context. A reasonable expectation for a junior developer applying broadly: out of 100 well-targeted applications, 10-20 turn into recruiter screens, 5-10 of those turn into technical interviews, and 1-3 of those turn into offers. Experienced developers see a better ratio but a longer cycle per company, since each round takes more calendar time to schedule. The practical takeaway is that a string of five or six rejections in a row is well within normal variance, not evidence that your approach is broken — the signal to actually change strategy is when your screen-to-application ratio or interview-to-screen ratio is near zero across 30+ applications, not after a short losing streak.

Application Process

Research before applying:
  - Read recent company blog / engineering blog
  - Check Glassdoor reviews (interview process, culture)
  - Find the tech stack (LinkedIn jobs, StackShare, their GitHub)

Customize for each application:
  - Match your skills to their requirements
  - Reference their specific tech stack
  - Mention something specific about the company/product

Cover letter (when required):
  3 paragraphs:
  1. Why this company / product (specific, not generic)
  2. Your most relevant experience for THIS role
  3. What you'll contribute + call to action

Customization is a genuine trade-off against volume, and knowing when to spend the extra 15-20 minutes per application matters. For a role you’re only moderately interested in on a high-volume job board, a tailored skills match with minimal customization is usually enough. For a company you’re genuinely excited about, or one that came through a referral, invest the full research pass — read their engineering blog, understand their product, and reference something specific in your materials. Generic applications (“I am a hardworking developer excited about this opportunity”) are easy for both ATS keyword matching and human reviewers to spot, and they read as low-effort regardless of how strong the underlying resume is, because the reviewer has seen hundreds of nearly identical openers that week.

---

Salary Negotiation

Do your research first:
  Levels.fyi — public comp data by company/level
  Glassdoor — salary ranges
  LinkedIn Salary
  Blind — anonymous discussion (grain of salt)
  Asking peers in the field

The conversation:

Recruiter: "What are your salary expectations?"
You: "I'm flexible, but based on my research for this role and
      my experience, I'm targeting around $X. Is that in range?"

(Never be the first to accept — always counter)

Offer received: "Thank you, I'm very excited about this opportunity.
I'd like a week to review the full package. Would that be possible?"

Counter offer: "I'm very interested in joining the team. Based on my
research and the scope of this role, I was hoping we could get to $Y
[10-15% above offer]. Is there flexibility there?"

If they say no: negotiate other things:
  - Signing bonus
  - Extra PTO
  - Remote work flexibility
  - Earlier performance review
  - Professional development budget

Negotiation feels uncomfortable for most junior developers, largely because it’s framed as confrontation instead of what it actually is: a normal, expected part of the hiring process that companies build room for. Most employers extend an initial offer below their actual budgeted range specifically because they anticipate a counter — recruiters and hiring managers negotiate offers routinely and are not offended by a reasonable, well-researched ask. The riskiest move is not countering too aggressively; it’s not countering at all, since the offer you accept on the spot is very rarely the best one the company was willing to make. That said, negotiating leverage is real and varies: a candidate with a competing offer in hand has meaningfully more room to push than one negotiating in the abstract, and it’s fair to mention (truthfully) that you’re weighing another opportunity if that’s genuinely the case — just never bluff a competing offer that doesn’t exist, since it’s easy to get caught in a follow-up question and damages trust for the rest of the relationship.

---

Networking

Effective networking (not asking for jobs):

1. Twitter/X — follow engineers at target companies, engage genuinely
2. LinkedIn — comment on posts, not just connect
3. Discord/Slack communities — contribute answers, ask good questions
4. Local meetups / conferences — in-person connection is memorable
5. Open source — contribute to projects the company maintains

When reaching out:
  "I saw your talk on [topic] at [conference] — your point about [X]
  resonated with my experience at [Y]. I'm working on [similar thing]
  and would love to chat for 20 minutes if you have time."

  Not: "Hey, can you refer me to your company?"

  Genuine connection first → job conversation naturally follows

Networking done well is a long game that should start months before you actually need a job, not a last-resort tactic when applications aren’t converting — and that timing is exactly why most developers under-invest in it: it doesn’t pay off immediately, so it’s easy to deprioritize. The reason “Hey, can you refer me?” as an opening message rarely works is that it asks someone you’ve never interacted with to spend their internal credibility vouching for a stranger, which is a big ask with nothing behind it. A message that references specific, genuine engagement with someone’s work costs them almost nothing to respond to, and if the conversation goes well, the referral request becomes a natural next step rather than the entire point of the interaction. Open-source contribution is a particularly effective form of this, because a real, merged pull request to a company’s public repository is concrete, checkable evidence of both skill and initiative — it does more to open a conversation than almost any cold message could.

---

Post-Interview Checklist

After each interview:
  [ ] Send thank-you email within 24 hours
      "Thank you for the time today. I really enjoyed discussing [X].
       It clarified my excitement about [specific thing about role/company]."
  [ ] Note what questions were asked (for your prep notes)
  [ ] Note anything you struggled with (address in your prep)
  [ ] Follow up if no response after 1 week
      "I wanted to follow up on my interview from [date].
       I remain very interested in the role and would love to hear
       if there are any updates."

The thank-you note is not a formality — at companies where the interview panel debriefs and compares notes, a thoughtful follow-up referencing a specific point from the conversation can genuinely tip a borderline decision, because it’s additional evidence of communication skill and real interest in the role, not just a template email. Keep your notes on what was asked even after you get the offer or the rejection: interview questions at a given company are often reused across cycles, and a rejected candidate who reapplies six months later with targeted preparation on exactly what tripped them up the first time has a real advantage over a first-time applicant.

Handling Rejection and Silence

Job searches involve far more rejection and unexplained silence than most first-time candidates expect, and this is worth naming directly because the emotional toll of ambiguous “ghosting” is often harder to manage than a clear no. Companies rarely explain why they passed on a candidate — legal liability concerns mean most rejection emails are templated regardless of the actual reason — so don’t over-interpret a generic rejection as a verdict on your skills; it may just as easily reflect budget changes, an internal candidate, or a slightly closer fit elsewhere. Set a personal rule for how long you’ll wait before treating silence as a no (two weeks past your last follow-up is reasonable) so you’re not checking email obsessively, and keep applying and interviewing elsewhere throughout, since a search that stalls entirely while you wait on one promising lead is a common and avoidable way to lose momentum. If you do get specific feedback, however brief, take it seriously and adjust — feedback offered voluntarily during a search is rarer and more valuable than almost anything you’ll read in a guide like this one.

---

More career guides (Korean on pkglog.com)

This site also publishes Korean deep-dives that pair well with this English overview: job posting channels & application tracking, resume, screening, and interview delivery, habits & weekly review, and senior / return-to-work positioning. Use them if you read Korean or run pages through translation.

Related Articles

• Git Workflow Best Practices
• GitHub Actions CI/CD Guide

---