我是住在首尔的新西兰人。这篇写的是从内部看到的韩国开发现场，坐在招聘桌两边看到的东西，以及我想对考虑来韩国工作的人说的话。

我是怎么来的

#

入口是读研。在新西兰怀卡托大学读完本科，又在一家电信公司做了一年网络运维之后，我于 2017 年 3 月到 2019 年 2 月在庆熙大学读计算机科学硕士。实验室每学期都会去参加韩国国内的两个计算机学术会议 KSC 和 KCC。2018 年在平昌举办的 KSC，赞助商里有好几家韩国大型科技公司，还设了面向求职学生的招聘展位。如果你是在韩国读研的外国学生，这一点值得知道。

之后的经历是这样的：

工程是熟悉的那一半。在那家客服初创公司我才明白，交付软件的很大一部分其实是运维；创作者平台的后端跑在比我今天会选的多得多的技术栈上。韩国特有的差别都在边边角角。Naver 是你必须在意的搜索引擎：我给 Kiwi Alumni 上线新网站的时候，SEO 是按 Google 和 Naver 两边一起做的。韩国平台的爬虫名字你很难猜到（Naver 的爬虫叫 Yeti，KakaoTalk 的链接预览来自一个叫 kakaotalk-scrap 的东西）。还有，韩国的网上银行到现在还要你在电脑上装它们自己的安全软件。

不过这些都不是难的部分。

눈치是什么，为什么不是「optics」

#

눈치是一种感觉：不靠别人说了什么，而是从情境里察觉别人在想什么、要什么、期待什么。눈 是「眼睛」的意思。用 2019 年的《The Power of Nunchi》一书把눈치介绍给英语世界的 Euny Hong，把这个词译成「eye-measure」，也就是「用眼睛量」。它出现在不少日常说法里。说一个人「눈치가 빠르다」（눈치快），是说他很会看场合；说一个人「눈치가 없다」（没有눈치），是说他完全看不懂，这可不是夸人。而「눈치를 보다」（看눈치）是一直留意别人的反应，通常是上级的，好让自己站在不被讨厌的那一边，相当于中文的「看眼色」「看脸色」。

英语里大家这时候会拿出来的词是「optics」，我觉得用错了。optics 讲的是不管实际如何，从外面看起来怎样，比如「在裁员的同一周宣布发奖金，optics 很难看」。它关乎外表，管理它的是被看的那个人。눈치大多指向相反的方向：重点不是你在别人眼里怎么样，而是你把别人看得有多清楚。两者唯一的交点是「눈치를 보다」：观察所有人，好管理自己在他们眼里的样子。外媒写韩国职场时写到的，正是这个版本。

那些文章举的例子大同小异：不要比组长先下班，真要休年假（연차）时得看的눈치，聚餐（회식）时什么时候可以走，以及要反驳上级的话，是在会上说还是会后私下说。不管你怎么看这些例子，它们的形状是一样的：每一条都是所有人都遵守、却没人说出口的规矩。

而且这和语言是两回事。韩语在话里，눈치在话以外的一切里。

눈치在开发团队里出现在哪儿

#

开发团队靠的正是这种形状。第一次当经理几个月后，我写了一篇关于团队规范的文章，开头是这样的：我处理的摩擦大多不是技术问题，而是大家对一些事各有各的默认假设，比如代码评审该多快回、「完成」到底指什么、催第二次算不算没礼貌。那时我没用这个词，但那张清单每一行都是눈치要读的东西。每一条都是团队心照不宣的约定，新人只能靠观察学会。

同一篇里我还抱怨过，新人学规范是「当成口口相传的民间故事」，而不是在入职时被明确告知；也抱怨过跨国团队默认自己的标准就是所有人的标准。要描述눈치靠什么运转，我找到的最好的英语词就是 folklore，民间故事。如果团队里只有你一个外国人，偏离标准的就是你，而那些「故事」哪儿都没写下来。

代价最大的地方是站会。2023 年我写过自己负责的一个项目落后了，我却一直等着有人来问。三周后终于有人问了，那时已经是一场灾难。눈치好也解决不了这个问题。会看场合，你就知道哪些话没人想听；可它不会告诉你照样要说。我从中得到的习惯正好和等待相反：在别人问之前，先用文字说出来。「这件事比我预想的要久，现在估计要 8 到 10 天，不是 5 天。要砍范围，还是推迟截止日期？」

当你成了被读的那个人

#

2024 年 2 月，我开始在首尔一家软件公司带一个工程团队，눈치的方向就此反了过来。当开发的时候，是我在看场合；当了经理，我自己就是场合。我在会上说了什么、没说什么，回消息有多快，几点下班，全都成了别人可以读的东西。

我当项目负责人时写过的很多东西，当了经理之后更加适用。如果大家不敢放心地告诉你哪里出了问题，你就会是最后一个知道的人。信息捂得太久，大家是能感觉到的，你留下的沉默会被小道消息填满。会上五个人等着你回答时，「我不知道」感觉像是失败，而这恰恰是它值得说出口的原因。还有我反复想起的一句话：别人读不到你的意图，只读得到你的话。在一个靠눈치运转的团队里，他们照样会去读：读你的表情、读你跳过了什么、读你几点走。所以最好少给他们留猜的余地。

我靠的都是些不起眼的做法。和每个人做一对一，聊的是这个人而不是这个 Sprint，再问一个能解决大部分问题的朴素问题：「有没有什么需要我或者团队帮忙，好让你的工作更顺利？」

一份简短的团队规范，三到五条，写在所有人都看得到的地方，包括经理违反了规范会怎样。主动去问那些在八个人的会上永远不会开口的人，而不是等他们开口。再就是用一句坦白的「不行，原因是这样」，代替一句之后再也不会被提起的「再看看」，因为含糊的回答只是又多了一件需要察言观色的事。我入职一个月左右时，产品团队的团建是从一家咖啡馆开始的，先做了一个关于彼此价值观和团队规范的工作坊。一家公司能给눈치的回答，很少有比这更直接的：花一整个上午，把平时不说出口的东西说出来。

作为外国人被招进去

#

我没有一套针对韩国求职的打法。我有的是招聘经理那一边的经验，由此得出的建议，就是在签合同之前，先对公司用一用눈치。

我当经理招人的时候，最想招的开发者从来不在招聘网站上；而且我以前也写过，创始人更愿意招自己已经共事过的人。所以最好的入口，是任何能让别人在招你之前先看到你怎么干活的地方。小公司的实习经常会悄悄变成一份正式工作邀约。黑客松能让人看你一整个周末：2023 年，我和另外三个人组队，拿下了由 Lunit Global 主办的 Seoul Tech Impact Hackathon 冠军，做的是一个应用，用来找韩国那些没有地址的路边小吃摊。

然后是咖啡聊天。我写过，一个人在轻松的聊天里怎么表现，比一场排练过的面试更能说明和他共事是什么样子，而且这是双向的。对候选人来说，这是进去之前读懂一个团队的唯一机会。如果坐在候选人的位置，我会问：团队现在面临的最大挑战是什么？你为什么加入，又是什么让你留下来？在这里工作有什么可能会让我意外的事？最后一个问题，是在礼貌地请对方提前把눈치告诉你。如果对方在人员流动或公司方向的问题上含糊其辞，这本身就说明了很多。

如果你要招外籍开发者

#

如果你在韩国带团队，准备招一个从别的地方来的开发者，最有用的一件事就是那篇团队规范文章里的一句话：把隐性的东西变成显性的。别让他们把你的规矩当民间故事去学。第一周就告诉他们：评审一般多久回、「完成」指什么、催第二次算不算没礼貌、大家实际几点下班、休假除了填表还有没有别的讲究。最后两条是典型的눈치问题，团队里的人连想都不会想到要说。

之后就是一些让人少猜一点的无聊习惯。在别人问之前先说：周五给相关人员发一封三行的邮件（这周上线了什么、接下来做什么、有什么担心的），只要十分钟。会上别等安静的人开口，直接去问他们。给真正的答复，包括「不行」，并且附上理由。还有，用同样的问题、同样的评分标准面试每一个候选人。这一条我花了些时间才学会，但这是公平比较人的唯一办法，否则你会偏向最近聊过的那个人。这也意味着，不懂你团队潜规则的候选人，和懂的人被问到的问题一模一样。

这里的新西兰社群

#

2018 年我还是学生的时候，在 Kiwi Chamber 的一场领导力早餐会上负责拍照，事后写道，我非常喜欢为促进两国关系的活动做志愿者。2020 年 1 月起，我担任 Kiwi Alumni 的主席。这是一个面向在韩新西兰人，以及在新西兰读过书、如今在韩国生活工作的人的社群。这是志愿职位，大部分是和人打交道的工作：组织活动，和新西兰驻韩大使馆及各教育机构建立关系，还有一些不起眼的活儿，比如新 logo，比如一个会员真能找到东西的网站。2023 年我们和大使馆一起办了 Kiwi Alumni Night，还上了 KTV。

那晚之后我写下的一句话，最接近这篇文章的主旨：在韩国和新西兰都生活过的人，知道怎么在两者之间架桥，因为两种文化他们都经历过。如果你来韩国工作，不管你来自哪里，去找这样的人。他们会用大白话告诉你，那个场合到底在说什么。

在首尔做自由职业

#

辞掉经理的工作后，我在 2025 年 10 月开始做自由职业。实际做的是合同制的 DevOps 和 MLOps 工作，大多是本地部署：先搭了一个高可用 PostgreSQL 集群，然后在同一批硬件上搭 LLM 推理服务。做下来发现，质量把控比铺管道多：盯着 trace 和多轮对话，找模型输出从哪里开始跑偏。2026 年 2 月起，我还在另外做一款自己的集市加社区应用。

做自由职业并不能让你摆脱눈치，只是换了要读的对象。不管到哪个团队，我最先看的都是监控，因为它比 README 更能说明一个团队。这算是对系统用的눈치：读的不是团队说自己在做什么，而是它实际在做什么。

想对考虑来韩国的人说的话

#

1. 从一扇能让人在招你之前先看到你干活的门进来。我走的是读研这条路。黑客松、小公司的实习，或者你自己国家在这里的社群，作用都一样；而在社群里，你能找到两边都生活过的人。
2. 别把小公司排除在外，我职业生涯的大部分时间都在小公司。十个人的公司里，没人可以让你把无聊的活儿推给他，而你做的东西真的会上线。
3. 加入之前先读懂团队。用好咖啡聊天，问问在这里工作有什么会让你意外的事，对方在人员流动上含糊其辞，要当回事。
4. 别等别人来问。估算要延期、改动有风险、别人在等你做决定：先说，用文字说。
5. 把没写下来的规矩大声问出来：评审多久回、「完成」指什么、催第二次算不算没礼貌。如果没人写下来，主动提出你来写。
6. 学会你技术栈周边的那一圈。在这里，Naver 和 Kakao 的重要性，是你的 Google 习惯覆盖不到的。

工程是你来之前就能准备的那一半。눈치是你在工作中才学得会的另一半，而我知道的最快的学法，是请别人把没说出口的那部分说出来，并且自己先说。

先坦白我的立场：我的职业生涯大部分都在小公司度过，现在也在一家小公司带开发团队。但每次有学生问我该选哪边的实习，我几乎都会推荐那个更小、更糙的选项。

创业公司实习 vs 大公司实习，一张表看完

#

放在一起比，大概是这样。后面是展开讲的版本。

活儿是真的

#

在一家十个人的公司，没有人可以接手那些没意思的杂活。实习生要发布功能、跟客户聊天、坐进规划会议，产品、市场、运营都会碰到，有时一周之内全轮一遍。确实乱，但成长也是真的快。

更好的是，你做的东西会真的上线。你可以指着产品里的某个地方说“这是我做的”。做出一个东西、然后看着有人在用，这个循环会上瘾，而大公司几乎从不让实习生碰到它。

还有个很实际的好处：成长中的创业公司缺人，创始人也更愿意雇已经共事过的人。一段不错的实习，常常会悄悄变成一份 offer。

你能近距离看创始人怎么干活

#

在大公司，你可能到离职都见不到 CEO。在创业公司，你八成就坐在他们旁边。他们怎么做决策、怎么扛压力、在所有事都显得紧急时先抓哪一件，你每天都看得到。这些没有任何课本会教。

扁平的结构是把双刃剑。你和上线之间没有三层审批，所以对做什么、怎么做有真正的话语权；但反过来，也没人手把手带你。有人在这种环境里如鱼得水，有人会被吓到。报名之前，最好先弄清楚自己是哪一种。

诚实的缺点

#

薪水通常更低，体系基本没有，可能没有专门的导师，公司本身两年后也未必还在。这些我不打算粉饰。但如果你想从内部搞明白一门生意到底怎么运转，我至今没找到更快的路。

我自己很快就要走这一步了，所以最近一直在找过来人聊，能找到的书也都翻了翻。目前最清晰的一条结论是：从工程师到工程经理，不是往上走一级，而是横着跨进一份完全不同的工作。你的产出不再是代码，而是团队做出来的一切。这话人人都说，但据说人人都还是低估了它的分量。

到底变了什么

你不再亲手解决技术问题，转而去解决人的问题。日历被 1:1、计划会议和跨团队协调填满，招聘和绩效评估也落到了你桌上。工作的重心变成：确保团队拥有干活所需的东西——背景信息、清晰的优先级，以及尽可能少的干扰。

别扭的地方在于，你还得保持足够的技术水平，能在架构讨论里站得住脚、做出靠谱的技术判断，同时又要接受"写代码的人不再是我"这个事实。我见过几个两头都想抓的经理，结果多半是两头都做砸。

工程师和工程经理，放在一起看

过来人提醒得最多的，就是反馈周期这一行。当工程师时，你几乎每天都能拿到一点小小的成就感。当了经理，成就是真的，但来得很慢，你得习惯在一段时间里都不知道某个决定到底对不对。

看起来最要紧的几项能力

沟通占了大头。你成了团队、产品和管理层之间的翻译，光是确认这三拨人在聊同一件事，就能耗掉多得惊人的时间。比任何流程都管用的是信任：如果大家不敢告诉你哪里坏了，你就会是最后一个知道的人。日历是真的会把人活吞的，守住思考的时间、留给团队的时间，是一场没有尽头的仗。还有，你得明白公司到底想干成什么，否则你根本没法把团队带向一个有意义的方向。

头衔到手之前的准备

我反复听到、也能亲自作证的一条建议：在别人给你头衔之前就开始带。带一个项目，指导一个人，牵头做点什么。过去一年我一直在做项目负责人的角色，这段经历比任何一本书都管用。当然书也有用——Camille Fournier 的 “The Manager’s Path” 是人人都推荐的那本，读完确实明白为什么。技术也别放下，架构之争永远不会停。最后，找一位已经完成这个转变的导师，他们能帮你绕开那些事后看来"这也能踩？“的坑。

取舍

你对"东西怎么造"的影响力变大了，但很少再亲手去造。我猜有些日子会觉得很爽，有些日子会想写代码想得不行。过来人都说这很正常。半年后再来问我吧。