필사 모드: Eight Korean Posts on Changing Jobs and Negotiating Salary — Chosen for Process, Not Success Stories
English- Why so many job-change write-ups still do not help
- How this list was assembled
- Full accounts of the whole process
- Salary negotiation is a question of evidence
- Resumes and career descriptions: escaping the stack list
- Interviews matter most after they end
- Related writing and tools on this blog
- Limits of this list
A note on language. Every linked piece below is written in Korean. The descriptions here are mine, in English, but the destinations are Korean-language pages.
Why so many job-change write-ups still do not help
Search for job-change write-ups and you will find plenty. Yet after reading, little tends to remain, because most of them report an outcome. Where someone went and how much their pay rose is stimulating in the moment but does not tell you what to do next week.
Changing jobs is really a procedure made of stages joined in sequence. You choose where to apply, write a resume and a career description, interview, negotiate terms, hand over your work, and settle a start date. Each stage has its own characteristic mistake. So this list gathers only writing that records the process rather than the result.
How this list was assembled
An editorial pick by one person, not a ranking. I have no way to measure view counts or popularity, and I did not try. I used three criteria.
First, I chose pieces that record the process in order. Posts that state only how much pay increased, or that emphasize the conclusion alone, are out.
Second, I did not collect only stories that worked out. Leaving a new job soon after joining, or changing direction after rejections, is often more useful. I deliberately kept writing that records failure.
Third, I opened every link and checked it. Candidates that would not load, demanded a login, or whose actual content did not match the search snippet were dropped. Community threads that only ask a question rather than recount an experience were also excluded.
These are individual cases, not general laws. Circumstances differ by years of experience, role, and company size, so take the perspective rather than the recipe.
Every link was opened and verified on 2026-08-12. Personal blog posts can disappear or change addresses.
Full accounts of the whole process
All three record the sequence from start to first day. The years of experience and circumstances differ, so placing them side by side reveals a shared structure.
A sixth-year developer changes jobs
Velog — Lim MyeongSeop · November 24, 2024
The author leaves a company joined through a referral after only a few days, then applies to dozens of places before landing somewhere that fits.
Read this if — someone has offered to refer you in and you cannot tell whether to take it.
The most valuable piece on this list, because it does not hide the experience of joining somewhere and immediately leaving. Referral moves look easy because the process is short, and this case exposes exactly how much you fail to verify when it is. In the second search the author greatly enlarges the number of applications, and that contrast reads like a self-diagnosis of what went wrong the first time. The closing decision, made on working hours and family rather than pay, is candid.
A junior developer's job-change retrospective
Velog — Mari · November 17, 2022
Several years at a first company, then a move driven by curiosity about engineering culture, with the emotions recorded alongside the steps.
Read this if — your current job is not bad and you find yourself considering a move anyway.
What makes this distinctive is that the motive was curiosity rather than dissatisfaction. Wanting to know how code review actually runs, and how people work elsewhere, describes many juniors precisely. It walks through interviews, terms negotiation, and giving notice, while acknowledging that leaving a first company was emotionally hard. The stance of treating a move as a growth question while still counting its cost is worth learning.
A 2025 mid-career developer job-change write-up
Velog — 코끼릭 · September 13, 2025
A third-year developer covers a two-month application period through technical interviews, personality interviews, and terms negotiation.
Read this if — you want a realistic sense of how much time preparation actually takes.
Stating the duration is this piece's practical value. Changing jobs does not happen the week after you decide to; knowing it takes months from first application to a confirmed start date is what keeps you from panicking midway. The passage about improving the portfolio after early rejections, and the results changing, is concrete. It also records what became different after the move, so the purpose of the change stays visible to the end.
Salary negotiation is a question of evidence
Plenty of negotiation posts discuss attitude. This one addresses where the evidence comes from.
Raising your salary by changing jobs
Velog — 코딩몬스터TV · January 8, 2021
Compares waiting for recognition inside one company against adjusting through a move, and sets out how negotiating evidence is built.
Read this if — you want a raise but do not know what to base the request on.
The central claim is that leverage comes not from eloquence but from the number of options you hold. With an offer elsewhere, your request has a basis; without one, however well you speak, it stays a request. That leads to the conclusion that negotiating well means the preparation is already finished at the application stage, not at the negotiating table. Note that using a competing offer is a card that can damage a relationship, so take the perspective and adjust the wording to your own situation. It is an older post, so its description of market conditions may not match today.
Resumes and career descriptions: escaping the stack list
Three pieces arrive at the same conclusion by different routes. Write what you solved, not what you used.
How to write a developer resume, in practice
Velog — 딩코딩코 · June 4, 2021
Compares tools for building a resume and contrasts weak versus strong versions of the same sections.
Read this if — you have the blank document open and cannot write the first line.
Its strength is showing the same content as a poor example and a strong one, side by side. Being told abstractly to write about impact is paralyzing; seeing one experience written two ways makes the difference immediately legible. It also covers the ordering of sections, which helps when you are laying out the structure for the first time. The tools and platforms mentioned may look different now, so take the composition principles rather than the specific formats.
How to write a career description
Velog — JeongWu Park · March 23, 2025
Notes from a career-description writing workshop, focused on turning accomplishments into measurable form.
Read this if — you have done a lot but everything looks ordinary once you try to write it.
This is useful because it inverts the problem. The key observation is that having nothing to write is not because the work was ordinary but because there is no record of it. Writing impact with metrics requires having kept those metrics, which means recording now rather than when you start preparing to leave. Organizing by categories such as problem-solving, productivity improvement, and collaboration is also directly applicable. Its virtue is that the conclusion moves from document formatting to how you work.
Examples of resume writing for experienced developers
Brunch — 자기소개서 예시 작성법 · August 18, 2025
Sets out, with structure and examples, how an experienced hire's resume should differ from an entry-level one.
Read this if — you are still editing the resume you wrote as a new graduate.
Its usefulness is naming the mistakes specific to experienced-hire resumes, item by item. Listing only the stack, and failing to separate team results from your own contribution, are the two big ones, and both leave the reader with nothing to verify. It recommends describing situation, task, action, and result separately, and shows that shape as an example. Where the previous two are developer accounts, this one is a document-craft treatment, so all three together do not overlap.
Interviews matter most after they end
Interview write-ups tend to get written only after an offer. This one shows the other side.
A backend developer's interview retrospective: reviewing year one
Velog — 코헤 · October 28, 2025
A first-year backend developer reconstructs the questions and their own answers, then diagnoses what was missing.
Read this if — you cannot even remember what you said once an interview ends.
What makes this good is how specific the self-assessment is. It names the weak areas precisely, such as database design and deployment tooling, and analyzes what the company's structure demands of the role. The post ends with an offer in hand but the decision unresolved because of the terms, and an unresolved ending is closer to reality than a tidy one. Reconstructing an interview to this level immediately produces preparation material for the next one.
Related writing and tools on this blog
- When to change jobs — for the stage where you are deciding whether to move at all.
- Salary negotiation — how to run the actual conversation once you have your evidence.
- A resume that gets read — good alongside the three pieces above.
- System design interview prep — a large share of experienced-hire interviews.
- Salary calculator — for converting an offer into take-home pay to compare.
Limits of this list
Six of the eight are Velog posts. That is where verifiable writing on this topic was easiest to find, not evidence that good writing lives nowhere else. The experience range also clusters between one and six years, so senior-level moves and role changes are absent from this list.
One closing note. Everything here is an individual case. There is no guarantee the same method produces the same result, and negotiation in particular depends heavily on a company's circumstances and timing. Read these for the order of the stages and the items to prepare.
현재 단락 (1/52)
**A note on language.** Every linked piece below is written in Korean. The descriptions here are min...