I’m a New Zealander based in Seoul. This is what it has looked like from the inside, from both sides of the hiring table, and what I’d tell anyone thinking about the move.

How I got here

#

My route in was a master’s in computer science at Kyung Hee University, from March 2017 to February 2019, after a BSc at Waikato and a year in network operations at a telco back home. Every semester our lab went to KSC and KCC, two domestic computing conferences. At KSC 2018 in PyeongChang the sponsors included several of Korea’s biggest tech companies, and there were recruitment booths for anyone job hunting, which is worth knowing if you’re a grad student here.

Since then:

The engineering was the familiar half. The support startup is where I learned how much of shipping software is actually operations, and the creator platform’s backend ran on more stacks than I’d choose today. The local differences sit at the edges. Naver is a search engine you have to care about: when I launched a new website for Kiwi Alumni, I did its SEO for Google and Naver both. Korean platforms crawl under names you won’t guess (Naver’s crawler is Yeti, and Kakao’s link previews come from one called kakaotalk-scrap). And Korean online banking still wants its own security software installed on your computer.

None of that is the hard part, though.

What 눈치 is, and why “optics” isn’t it

#

눈치 is the sense for what other people think, want or expect, picked up from the situation rather than from anything they’ve said. 눈 means “eye”, and Euny Hong, whose 2019 book The Power of Nunchi is the best-known English introduction, translates the whole word as “eye-measure”. It turns up in a few everyday phrases. Someone who is 눈치가 빠르다 is quick to read a room. Someone who is 눈치가 없다 can’t read one at all, and it isn’t a compliment. And 눈치를 보다 is keeping an eye on how others are reacting, usually someone senior, and adjusting to stay on the right side of it.

The English word people reach for is “optics”, and it’s the wrong one. Optics is how something looks from outside, whatever it actually is: “the optics of announcing bonuses in the same week as the layoffs”. It’s about appearances, and it’s managed by whoever is being looked at. 눈치 mostly points the other way. It’s about how well you see other people, not how you look to them. The two only meet in 눈치를 보다, where you watch everyone else in order to manage how you look to them, and that’s the version that turns up in articles about Korean offices.

The examples in those articles are much the same each time: not leaving before your team lead does, the 눈치 people feel about actually taking their annual leave (연차), knowing when you’re allowed to go home from a 회식 (a team dinner), and deciding whether to contradict a senior in the meeting or quietly afterwards. Whatever you make of them, they share a shape. Each is a rule that everyone follows and nobody states.

It’s a separate problem from the language, too. Korean is in the words. 눈치 is in everything around them.

Where it shows up on a dev team

#

That shape is what dev teams run on. A few months into my first management job I wrote a post about team norms that began with this: most of the friction I dealt with wasn’t technical. It was people running on different unspoken assumptions about how fast a code review should come back, what “done” actually means, and whether it’s rude to ping someone twice. I didn’t use the word then, but that list is what 눈치 reads, every line of it. Each one is a rule a team agrees on without saying, and a newcomer can only pick it up by watching.

In the same post I grumbled about new hires learning the norms “as folklore instead of hearing them explicitly during onboarding”, and about global teams assuming their baseline is everyone’s. Folklore is the best English word I’ve found for what 눈치 runs on. When you’re the foreigner on the team, yours is the baseline that’s off, and the folklore isn’t written down anywhere you could read it.

The standup is where it costs the most. In 2023 I wrote about a project I was leading that fell behind while I waited for someone to ask about it. Someone finally did, three weeks later, and by then it was a disaster. Good 눈치 doesn’t fix that. Reading the room tells you what nobody wants to hear; it doesn’t tell you to say it anyway. The habit I took away is the opposite of waiting. Say it first, in writing, before anyone asks: “This is taking longer than I thought. Now looking at 8–10 days instead of 5. Want me to cut scope or push the deadline?”

When you’re the one being read

#

In February 2024 I started managing an engineering team at a Seoul software company, and 눈치 turned round. As a developer I’d been the one reading the room. As the manager, I was the room. What I said in a meeting, what I didn’t, how quickly I replied and what time I went home were all things other people could now read.

A lot of what I’d written as a project lead applies with more force once you’re the manager. If people don’t feel safe telling you what’s broken, you’ll be the last person to find out. Sit on information too long and people can sense it, and the rumour mill fills whatever silence you leave. “I don’t know” feels like failure when five people in a meeting are waiting on your answer, which is exactly why it’s worth saying. And the line I keep coming back to: people can’t read your intent, only your words. In a team that runs on 눈치 they’ll try anyway, from your face, from what you skip and from when you leave, which is a good reason to give them less to guess.

What I leaned on was unglamorous. One-on-ones with everyone, kept about the person rather than the sprint, with the plain question that does most of the work: “Is there anything you need from me or the team to help with your tasks?”

A short list of team norms, three to five of them, written where everyone could see them, including what happens when the manager breaks one. Going to ask the people who will never speak up in a room of eight, instead of waiting for them to. And an honest “no, and here’s why” in place of a “we’ll see” that never comes up again, because a vague answer is just one more thing to read the room for. A month in, the product team’s outing started at a café with a workshop on each other’s values and team norms, which is about as direct an answer to 눈치 as a company can give: a morning spent saying out loud the things that usually go unsaid.

Being hired as a foreigner

#

I don’t have a recruiting playbook for Korea. What I have is the hiring manager’s side of it, and the advice that falls out of that is 눈치 pointed at the employer before you sign.

When I was hiring as a manager, the developers I most wanted were never on the job boards, and founders, as I’ve written before, would much rather hire someone they’ve already worked with. So the best way in is anything that lets people see you work first. An internship at a small company has a habit of quietly turning into a job offer. A hackathon gives you a whole weekend of it: in 2023 I was on a team of four that won the Seoul Tech Impact Hackathon, hosted by Lunit Global, with an app for finding street food vendors, who in Korea don’t have addresses.

Then there’s the coffee chat. I wrote that how someone behaves in a relaxed conversation tells you more about working with them than a rehearsed interview ever will, and that it runs both ways. For a candidate it’s the one chance to read a team before you’re inside it. The questions I’d ask from the candidate’s chair: what’s the biggest challenge the team is facing right now, why did you join and what’s kept you here, and what’s something about working here that might surprise me. That last one is a polite way of asking for the 눈치 up front. Evasive answers about turnover or direction tell you plenty on their own.

If you’re hiring a foreign developer

#

If you run a team in Korea and you’re hiring a developer from somewhere else, the most useful thing you can do is the phrase from that norms post: make the implicit explicit. Don’t leave them to learn your rules as folklore. Tell them in the first week how fast reviews are expected back, what “done” means, whether a second ping is rude, what time people actually go home, and whether taking leave involves anything beyond the form. The last two are the classic 눈치 questions, the ones nobody inside the team thinks to say.

After that it’s the boring habits that leave less to read. Tell people before they ask; a Friday email to stakeholders with three bullets (what shipped, what’s next, anything you’re worried about) takes ten minutes. Ask the quiet ones directly rather than waiting for them in the meeting. Give real answers, “no” included, with the reason attached. And interview every candidate with the same questions against the same rubric. That one took me a while to learn, but it’s the only fair way to compare people; otherwise you end up favouring whoever you spoke to most recently. It also means the candidate who doesn’t know your team’s unspoken rules gets asked exactly what the one who does gets asked.

The New Zealand community here

#

In 2018, while I was still a student, I took the photos at a Kiwi Chamber leadership breakfast, and wrote afterwards that I really enjoy volunteering for events that promote the relationship between the two countries. Since January 2020 I’ve chaired Kiwi Alumni, a community for New Zealanders in Korea and for people who studied in New Zealand and now live and work here. It’s a volunteer role, and mostly people work: organising events and building relationships with the New Zealand Embassy and education institutions, plus unglamorous jobs like a new logo and a website members can actually find things on. In 2023 we ran Kiwi Alumni Night with the Embassy, and it ended up on KTV.

What I wrote after that night is the nearest thing this post has to a thesis. People who’ve lived in both Korea and New Zealand understand how to bridge the differences, because they’ve experienced both cultures. If you’re coming here to work, find those people, wherever you’re from. They’re the ones who’ll tell you in plain words what the room was saying.

Freelancing from Seoul

#

I went freelance in October 2025, after leaving the manager’s job. In practice that’s contract DevOps and MLOps work, mostly on-premise: a high-availability PostgreSQL cluster, then serving infrastructure for LLMs on the same hardware. More of it has turned out to be quality control than plumbing, watching traces and multi-turn conversations to find where model output drifts. Since February 2026 I’ve also been building a marketplace and community app of my own, on the side.

Freelancing doesn’t get you out of 눈치; it changes what you read. The first thing I look at anywhere I land is the monitoring, because it tells you more about a team than the README does. That’s 눈치 for systems: reading what a team actually does rather than what it says it does.

What I’d tell someone considering it

#

1. Come in through a door where people see you work before they hire you. Mine was a master’s. A hackathon, an internship at a small company or your own country’s community here do the same job, and the community is where you’ll find the people who’ve lived on both sides.
2. Don’t rule out small companies; most of my career has been at them. At a ten-person company there’s nobody to hand the boring work to, and what you build actually goes live.
3. Read the team before you join. Use the coffee chat, ask what would surprise you about working there, and take evasive answers about turnover seriously.
4. Don’t wait to be asked. A slipping estimate, a risky change, a decision someone else depends on: say it first, in writing.
5. Ask for the unwritten rules out loud: how fast reviews come back, what “done” means, whether a second ping is rude. If nobody has written them down, offer to.
6. Learn the stack around your stack. Naver and Kakao matter here in ways your Google habits won’t cover.

The engineering is the half you can prepare for before you arrive. 눈치 is the half you learn on the job, and the quickest way I know to learn it is to ask people to say the quiet part out loud, and to say yours first.

Since moving into an engineering management role this year I’ve spent a lot more time on the hiring side of the table, and the biggest lesson so far is that letting a candidate talk generally about their CV tells you almost nothing. A resume says what someone worked on. It says very little about how they work.

Behavioural questions in the STAR format are the best tool I’ve found for closing that gap: a real story from the candidate’s past, steered through those four beats. It sounds like HR boilerplate — it is HR boilerplate — but it forces specifics, and specifics are where the signal is.

The shape of a good answer

#

Take a question like “Tell me about a time you resolved a complex bug.” You’re listening for the situation (what was going on and why it mattered), the task the candidate was personally on the hook for, the actions they took — the “I”, not the “we” — and the result, ideally with a number attached.

A strong answer sounds something like this one, about technical debt:

“Our deployment pipeline took 45 minutes, and flaky tests meant developers often re-ran builds several times. I tracked the time lost over a month — roughly 15 hours per developer. I presented that to leadership and proposed a two-sprint investment to parallelise the tests and fix the flakiest ones. Deployments dropped to 12 minutes, and our deployment frequency doubled.”

Situation, task, action, result, in five sentences, with the candidate’s own contribution unmistakable. Put that next to “we had a slow pipeline so we fixed it” and you can see why the structure earns its keep.

The questions I keep coming back to

#

Rather than trying to cover everything, I organise questions around the competencies the team actually needs right now:

That last one is my favourite. How someone talks about a failure tells you more than three success stories, and it’s very hard to rehearse.

Where the interview actually happens

#

Candidates rarely give you the full STAR arc unprompted, and that’s fine — the follow-ups are the real interview. If someone says “we improved performance”, ask by how much and how they measured it. If everything is “we”, ask what they personally did. If a story wraps up suspiciously neatly, ask what they’d do differently next time.

The other thing that took me a while to learn: ask the same questions of every candidate and score the answers against a simple rubric. It feels mechanical, but it’s the only fair way to compare people. Otherwise you just end up favouring whoever you spoke to most recently.

None of this replaces a technical assessment — you still need to see whether someone can build things. But hypotheticals are easy to bluff and past behaviour is hard to fake. After a year of running these, I trust a well-probed story far more than a polished answer about strengths and weaknesses.

STAR in four lines

#

• Situation: what was going on, and why it mattered.
• Task: the part the candidate was personally responsible for.
• Action: what they did themselves. If it’s all “we”, ask what they did.
• Result: what came of it, ideally with a number. If they say they improved something, ask by how much and how they measured it.

Further Reading

#

On this site:

• The Coffee Chat: A Precursor to the Hiring Process — getting to know candidates before the formal process starts
• Prioritizing Team Dynamics in Engineering Management — hiring for how someone will fit the team
• The Benefits of Interning at a Startup — useful context when evaluating early-career candidates
• Retrospectives: The Power of Feedback Loops — the same feedback habits apply to your interview process

Elsewhere:

• The STAR Method: The Secret to Acing Your Next Job Interview — The Muse’s guide, written for candidates
• Google re:Work: Structured Interviewing — the research behind structured interviews
• First Round Review: 40 Favorite Interview Questions — good for stealing
• Joel Spolsky: The Guerrilla Guide to Interviewing — a classic that still holds up

A coffee chat is 30–45 minutes, informal, at a café or over a video call. No whiteboard, no panel, no trick questions. I talk about what we’re building and why, they talk about what they’re working on and what they’d want next, and both of us leave knowing whether a deeper conversation makes sense. Hiring is a matching problem more than a selection problem, and this is the fastest way I know to trade the information that matching actually needs.

Why I bother

#

I’ve stopped thinking of these chats as recruiting. They’re just conversations, and every so often one turns into a hire — sometimes eighteen months later, when the person’s circumstances change. The pipelines that reliably produce good hires are built out of relationships like that, not out of job ads.

They also fix the job-description problem. JDs are generic by necessity. Over coffee, a candidate can ask the questions that actually matter to them: what does success look like in the first six months, who would I be working with, what’s the hairiest technical problem on the team right now. People who hear honest answers to those questions self-select well.

And a chat shows your culture instead of describing it. Whether you turn up prepared, curious, and respectful of someone’s time says more than any careers page. It runs both ways, too — how someone behaves in a relaxed conversation tells you more about working with them than a rehearsed interview ever will.

The moments where a coffee chat earns its keep: approaching someone who isn’t looking, warming up a referral before anything formal, and talking with someone weighing a career shift — IC to management, startup to enterprise, or the reverse. In a tight talent market, that covers most of the people you want.

How I run one

#

The first message decides everything. Generic outreach gets deleted. Do your homework and be honest about your intentions:

“Hi Sarah, I noticed your talk on distributed systems at QCon and your blog posts on event sourcing. We’re tackling similar challenges at [Company] as we scale our payment infrastructure. Would you be open to a 30-minute coffee chat? No interview agenda—just curious to hear your perspective and share what we’re working on.”

That works because it’s specific, upfront, and offers something (a conversation about interesting problems) rather than only asking for time. Then make it easy: offer a few time options, pick a spot convenient for them or a video tool that doesn’t need a download, and send a proper calendar invite so nobody’s guessing.

The chat itself only needs a loose shape. A few minutes of real small talk and why you reached out. Then their story — current work, what they enjoy, what frustrates them, what they’d want in the next thing — where your job is mostly to listen. Then yours: the mission, the team’s actual challenges, hard parts included, because candidates respect transparency and can smell a sales pitch. The most valuable stretch is the open one near the end: what would need to be true for them to consider a move? Close with explicit next steps, even if the next step is just “let’s stay in touch”.

Follow up within 24 hours with a short note that references something specific, and deliver anything you promised — an intro, a link, whatever. The boring aftermath is the real culture demo.

If you do this more than occasionally, keep a simple spreadsheet of who you’ve talked to and check in every so often, even with no role open. And it needn’t be a manager-only activity — some of the best chats happen when your engineers grab coffee with impressive people in their own networks. That’s where good referrals come from.

Questions that earn their slot

#

Ones I ask:

• “What’s been the most interesting problem you’ve worked on recently?”
• “What would you want to be different in your next role?”
• “What’s your learning style? How do you like to grow professionally?”
• “What questions do you have that would help you evaluate whether this could be a fit?”

Ones I’d ask if I were on the other side of the table:

• “What’s the biggest challenge the team is facing right now?”
• “How do you measure success for this role?”
• “What does the path to promotion look like?”
• “Why did you join the company? What’s kept you here?”
• “What’s something about working here that might surprise me?”

If you’re the one invited

#

Most people who look up what a coffee chat is are on the other side of the table from me: someone has asked them for one, and they want to know what they’re walking into. Here’s what I’d tell you from the side that sends the invitations.

It isn’t an interview. Nobody is scoring you and there’s no test, so you don’t need to prepare answers. It is still a first impression, though, so treat it like meeting a future colleague rather than a friend of a friend. The difference from an interview is that you’re allowed to be curious, and you’re expected to ask as much as you answer.

Wear what you’d wear to work there on an ordinary day. If you don’t know, smart casual is never wrong. On a video call, have the camera on and find a quiet room; that matters more than the shirt.

Preparation takes about half an hour. Read what the company makes and anything the person has written or built. Have a two-minute version of what you work on now and what you’d want next, because that question is coming. Bring two or three of your own questions; the list above is a fair start.

As for what to talk about: your work, what you enjoy about it, what you’re curious about in theirs. Leave salary for later unless they raise it. It’s perfectly fine to ask whether there’s a role in mind and what the process would look like if there were.

Whoever did the inviting usually pays. Offer, but don’t make a thing of it. Send a short thank-you within a day that mentions something you actually talked about, and you’ve done more than most.

And if you want one yourself, ask. Keep the message short, say why that person, and make it easy to say yes: “I’ve been following your team’s work on the new search, and I’m thinking about moving into platform engineering. Would you have 30 minutes for a coffee or a call in the next few weeks? Happy to work around you.” Most people say yes to a request that specific.

Ways to ruin it

#

The fastest is turning it into a stealth interview. Start quizzing someone on technical skills or sliding in behavioural questions and you’ve broken the implicit deal — save that for the formal process. Over-selling is a close second: the hires that stick are the people who joined with clear eyes about the hard parts. Turning up unprepared, or going silent afterwards, does quieter damage; every chat shapes what that person tells their network about you.

From my side of the table, the warning signs are a candidate with no curiosity about anything, a conversation that feels purely transactional, or someone who describes every past employer with the same bitterness. Candidates should keep their own list: a rep who can’t explain why the work matters, evasive answers about turnover or direction, and anyone more interested in selling you than understanding you.

Not every chat leads anywhere, and that’s fine — most don’t. The point is that the next time you need to fill a critical role, you’re not starting from a blank job ad. You’re starting from a stack of real conversations. Reach out with an invitation to coffee, not a job description.

Further Reading

#

Related Articles on This Site:

• Using the STAR Method for Developer Interviews - for when the chat turns into a formal interview process
• Three Things I’m Focusing on as a New Engineering Manager - what makes teams work, which is what you’re matching for
• Why You Should Intern at a Startup - useful context when chatting with someone weighing a startup move

External Resources:

• First Round Review: Hiring Engineers - startup hiring guides from experienced operators
• Lara Hogan’s “Questions for Our First 1:1” - written for 1:1s, works brilliantly over coffee
• Patrick McKenzie on Salary Negotiation - worth reading to understand the candidate’s side of the table
• Who: The A Method for Hiring - Geoff Smart and Randy Street’s framework for systematic hiring
• Harvard Business Review: Hiring and Recruitment - research-backed pieces on talent acquisition