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.

I’ll admit my bias up front: most of my career has been at small companies, and I run a dev team at one now. But when students ask me which internship to take, I almost always point them at the smaller, scrappier option.

Startup vs big company internship at a glance

#

Side by side, the trade looks like this. The rest of the post is the long version.

The work is real

#

At a ten-person company there’s nobody to hand the boring stuff to. Interns ship features, talk to customers, and sit in the planning meetings. You’ll touch product, marketing and ops, sometimes all in the same week. It’s messy, and you learn fast.

Better still, what you build actually goes live. You can point at something in the product and say “I did that”. That loop of building a thing and watching people use it is addictive, and big companies almost never let interns near it.

There’s a practical upside too: growing startups need people, and founders would much rather hire someone they’ve already worked with. A good internship has a habit of quietly turning into a job offer.

You get to watch the founders up close

#

In a big company you might never meet the CEO. At a startup you’re probably sitting next to them. You see how they make decisions, handle pressure, and prioritise when everything feels urgent at once. No textbook covers that.

The flat structure cuts both ways. There aren’t three layers of approval between you and shipping, so you get genuine say in what you work on and how. On the other hand, nobody is going to hold your hand. Some people thrive on that; others find it terrifying. Worth knowing which one you are before you sign up.

The honest downsides

#

The pay is usually worse. The structure is minimal. You might not get a dedicated mentor, and the company itself might not exist in two years. I won’t pretend otherwise. But if you want to learn how a business actually works from the inside, I still haven’t found a faster way.

The idea

#

Street food vendors in Korea don’t have addresses. A pojangmacha sets up wherever it sets up, and unless you already know the spot, you won’t find it online. Our app puts vendors on the map — literally. That’s good for the vendors, and good for anyone hunting down late-night tteokbokki.

The weekend itself

#

The hackathon was hosted by Lunit Global, who put up the office space. Teams from all sorts of backgrounds, most of us working straight through the night, and organisers who kept everything running smoothly. The kind of event where you look up and it’s suddenly 4am.

The team

#

The team was Sharon Levy, Jonothan Sue, me, and Tiaan van der Riel. Everyone brought something different, so splitting the work was painless. The pitch landed with the judges, I think, because the problem doesn’t need explaining — say “street food vendors are invisible online” out loud and the solution suggests itself.

What’s next

#

We’re working on getting the app into the stores. It started as a weekend project, but the problem it solves is real enough that stopping now would feel like a waste.

If it’s your first hackathon

#

If you’ve never done a hackathon, I’d recommend it. You build something fast with people you’ve never worked with, find out how you actually handle pressure, and once in a while you walk out with something worth continuing. Worst case, you get a weekend of free snacks and a working prototype nobody asked for.

A few things worth knowing before you go:

• Pick a problem you can explain in one sentence. If the judges spend the first minute working out what the problem is, they aren’t listening to your solution.
• Split the roles early, ideally in the first hour: who builds, who designs, who owns the pitch. Working that out at 2am costs far more.
• Build the demo path first. Get the one flow you’ll show on stage working end to end before you add anything else.
• Rehearse the pitch out loud, with the live demo, at least twice. Pitches nearly always run longer than you think.
• Sleep a little. Even a couple of hours makes the morning’s decisions, and the pitch, noticeably better.

Links:

#

https://lnkd.in/drMXUgPB

I think about this a fair bit at work, since I’m building a community app that lives in the shadow of much bigger social platforms: do you build on top of the giants, or compete with them? Both can work. The interesting question is when to switch.

Coopetition examples

#

The well-known examples are all big companies. Samsung makes many of the OLED screens in iPhones while selling Galaxy phones against them. Netflix moved its streaming systems onto Amazon Web Services, finishing in 2016, while competing with Amazon’s own Prime Video for the same evenings on the sofa. Google pays Apple to be the default search engine in Safari, and Android goes after the same phone buyers as the iPhone. In each case both sides decided the shared slice was worth more than keeping the rival at arm’s length.

A startup’s version is smaller and more lopsided. You cooperate with a platform because you need its users, and you compete with it for their attention. Early on it’s almost all cooperation; the question is when to start leaning the other way.

Why coexisting first makes sense

#

Early on, while you’re still hunting for product-market fit, riding the big platforms is usually the right call. Operating inside an ecosystem that already has users teaches you what people actually want. Integrations with popular platforms give you distribution you couldn’t buy. And you can carve out a niche instead of fighting a giant head-on. PayPal started as a payment option for eBay users, and half the successful apps you can name began as add-ons for Shopify or Slack.

Knowing when to compete

#

The shift comes later, once you understand your users better than the platform does. Instagram is the classic case — a photo-filter app that grew into a social platform in its own right. The signs I’d look for: you’ve built genuine domain expertise or technology of your own, and you can see from user behaviour that people want something the incumbents don’t offer. If neither is true yet, competing is just picking a fight you’ll lose.

What this looks like for a community app

#

For a community product, coexisting mostly means integration work, and it’s less glamorous than it sounds. Social sign-on, so joining doesn’t require yet another account. Easy sharing of community content out to people’s social feeds — that’s your marketing budget right there. Notifications when someone gets a mention or shout-out on another platform, embeds and widgets so partners can put community features on their own sites, and API hook-ups with complementary services. On the non-technical side, collaborations with influencers who already live on the big platforms, and campaigns that run across several platforms at once, tend to do more for engagement than anything you build in-house.

None of this is binary, which is rather the point of coopetition. Most startups start by coexisting and drift toward competing as they grow — the trick is noticing when you’ve quietly earned the right to make that shift.