从老东家离职了，写点儿东西，和同在职场中继续拼搏的朋友们交流。写下的东西，都是亲身经历的事儿，如果能引起您的共鸣或开心一笑，那么就算没有白费力气码字。如果能对刚入职场的小伙伴儿们有所帮助，那就更欣慰了。

先简单自我介绍一下。2005年入职一家IC行业的日企，2019年离职，差不多在这里服务了15个年头。公司的组织结构不断变化，我的头衔也是发生了多次变化。刚入职时，是 Project Manager，再后来是 Manager、Seninor Manager、Team Manager、Deputy Group Manager，离职前的头衔是Principal Engineer。尽管头衔不断变化，但是工作内容基本没有发生大的变化，带领一个本土团队，做微处理器的技术服务、开发的工作。

当然了，这些年下来，工资也逐步增加。除了2008年时由于经济危机的原因没有加薪外，每年都有加薪。不过，日企的薪资水平，在人才市场处于中等水平。下面是我在日企工作15年中的薪资变化，给您做个参考，对比一下自己的薪资是个什么样的水平。

后续的内容，尽量以小故事的方式（时间、地点、人物）回顾公司生活中的不同阶段，力图增加本帖的趣味性，并在每个小故事的结尾，写一小段评论内容，增加帖子的知识性。

入职日企的面试经历

应聘到这家公司，颇具戏剧性，先简单回顾一下应聘和面试的经历。2004年10月份，从前一公司离职后，在家休息，没事儿就上网看看网上的招聘。偶然间看到了这家公司招聘 Project Manager 职位的信息。于是邮件发了个简历，然后关机，出去准备接儿子。（当时小孩子还在上幼儿园，现在已经是大二的学生了）。

我还未走到楼下，接到了对方人事经理的电话，约我去面试。当时很惊讶，暗想这家公司的效率也忒高了。和人事经理简单交流了几分钟，约定了下周去面试的时间。

第一次面试时，面试主官是一位技术部门的经理（但不是我应聘部门的老大，本部门老大是位日本人，比我晚到岗），中国人。人很和气，后来知道是清华的、研究生毕业。因为这个日企的业务主要是MCU，我之前工作的内容也是基于MCU的产品开发，因此技术部分的面试基本没什么难题，从面试官的表情看得出，对我的技术背景很满意。接着英语交流了一些简单的技术内容。坦白说，本人英文水品还可以，尽管很久不说英文，但基本能对付面试的交流。当年研究生入学后，英文成绩算是优秀，直接免修。

由于本人入职的部门是新设立的部门，和日本本土的技术人员有很多交流，所以还需要日方人员二次面试、最后拍板。面试结束后，人事经理说回去等通知。

等了一周没有消息，于是我电话联系了人事经理，客气地询问上次面试如何。人事经理说，他们对我的表现非常满意。由于日方参加面试的日程未确定，所以没联系我。刚好今天定了日程，正准备给我电话，我的电话就来了。呵呵，运气不错。于是约定了第二轮面试的时间。

第二轮面试，有四位面试官。两位中方的（人事经理和上次面试的部门经理），两位日方的，一位是公司的总经理，一位日本过来的技术部长。由于本次是日本人主要面试，所以全程英文面试。作为总经理的日本人在美国工作过多年，他说的英语还容易理解；从日本过来的部长，我的娘啊，说的英文太难懂了。所幸的是，他说的比较慢，中间有中方部门经理帮助解释，总算把他所提的问题都回答了。

最后问我要求工资多少？我说8000RMB（最后给我定的入职工资是9000RMB，这是后话)。面试结束后，让我回去等消息。大概过了3、4天的样子，人事经理电话通知我，说决定录用我，让我再过去一次，拿纸质的录用通知。

在后续的工作经历中，我作为Manager 也面试过很多人。怎么才能取得面试成功呢？我觉得主要是这么几个因素：

1. 首先，你的背景得符合职位要求。这是干货，来不了半点儿假。比如，我的背景是微处理器的技术开发，那么去应聘Marketing的职位，成功的机率就很低（我试过，没有收到过面试邀约，因为HR的招聘专员，基本是根据关键字筛选简历的）。

2. 其次，面试时要真诚。现在有些面试者，过度包装自己。要知道，面试主官如果要想提一个你回答不出的问题，很容易。几个问题问下来，就得露馅儿。所以，如果有的问题你回答不出，特别是技术相关得问题，可以明确告诉对方，这个以前没有接触过，目前无法给出正确答案。

3. 最后，偶然因素。这个自己无法左右，要看你遇到什么样得面试官了。这个偶然因素有时候甚至决定最后的结果。如果你的品味和面试官很好匹配，那么OK。如果面试官对你的第一印象就不好，很可能会决定了你面试失败的结局。

我曾经拒绝的面试候选人

在我这个团队组建后的3年时间里，陆续有第一批入职的员工离职。做管理职、HR的朋友都知道，员工在一个职位工作3年后，处于职业变动高发期。所以，我也得招募新人，填补留下得空额。

大概是在2008年，HR推荐了几位应聘者的简历。按照流程，笔试，初步筛选技术合格者；面试，通过当面交流双方进一步了解，最终确定成功的应聘者。在本次招募中，也遇到了一位优秀的面试者（下面称他为小刘吧），但我最终拒绝了他的申请。

小刘的英语很棒，口语交流很流利，符合我们的需求。在后续的面试交流中，我发现他仍然有出国深造的打算。这一点埋下了被拒的种子。

我们当时有一项业务，是微处理器（MCU）的功能验证，坦白说，这是项很枯燥的工作。这次招募新人，就是接替这个工作。在技术环节的面试交流中，小刘的技术背景也很不错，应该是足以胜任我们这个职位的技术要求。

后来我告诉他，这个工作很枯燥，问他如何看待这个工作？小刘说，他不怕枯燥，肯定会把这个工作做好。这个回答，最终让我做出了拒绝他的决定。

问题出在哪里呢？首先，我认为他的能力超出了职位需求（over qualified），基本不会长期地安心于这个工作；其次，我感觉他不够诚信。枯燥的工作内容，如果让人感到枯燥，我觉得是人之常情。如果说不会感觉枯燥，就有点不真诚了。归根结底，是他的回答，和我的预期不匹配。

他的面试失败原因，就是我上面提到的偶然因素。遇到的面试官和你不匹配造成的。

我的第一次出差 && 我的第一份出差报告

相关人物：公司总经理“铃木 "，技术部门经理C

2006年 5月份的样子（时间太久，记不确切了），公司的客户 （Logo 是兄弟俩的那个） 发生了小部分 8-bit MCU（单片机）不能正常写入程序的故障，需要技术支持。我们这个部门是新设立的部门，部门名称正是 MCU 应用技术部，支持客户也是一个份内职责。由于本部门刚成立，人员配备尚不完整，所以本次出差，自然落到了我这个 Team Leader 头上。

次日，和FAE（现场应用工程师） 一起到用户处，通过现场复现用户所述的故障，很快确定了，故障并非我们产品本身的问题，而是用户写入设备的问题。由于用户是批量生产，所以用户自己做了个工具（工装）。长时间连续使用、磨损、氧化，造成接触不良，导致写入失败的故障。

问题找到了，我们也给出了解决方法（ =>定期更换工装的接触探针）。

第一次出差，问题顺利解决，心情不错。晚上和几个同事整了点小酒。呵呵。

第二天回到办公室后，面试我的中方部门经理老C告诉我（我所在部门的老大，是日本人，晚我9个月到岗，因此，2005年大部分时间，是我在负责本部门的运营，），需要提交出差报告，通过邮件发送给他和总经理铃木。

很快写好了出差报告（我的英文写作能力，还是很自信的），通过邮件发送给了总经理和部门经理老C。

很快，收到了总经理铃木的回复邮件。这个邮件对我触动很大，即使10多年过去了，仍然记忆犹新。尽管邮件的细节记不清了，但关键的内容还能回忆起来。

W san ( san，是日本人称呼用的词汇，翻译成中文是“桑”。抗日神剧中经常出现）

Your report is a bad example of business trip report （你的报告是典型的烂报告）

.......... （中间的细节记不清了）

What's your next action items? （你的下一步工作计划是什么？）

Who will follow it? （谁将跟踪这件客户支持？）

What's the schedule? （日程安排是什么样的？）

.........

总之，把我写的出差报告批的狗屁不是。之后重写了报告，回答了老板提出的所有问题，才算过关。这件事对我触动很大，在之后的工作中，我花了很大力气提高自己的写报告技能，并在后来给我的下属作过多次的报告技能的培训。尽管这位前总经理已经离职多年（据说，已经驾鹤西去了），我仍然对他给我的批评，心怀感恩。

点评：

在公司工作，特别是大公司公司、外资公司，写报告的技能是非常重要的。正所谓“干得好，不如报告写得好”。

报告的目的，是为了快捷、准确地传递信息。好的报告，必须能让你报告的目标受众，很容易地找到他关注的信息。因此，报告需要使用目标受众易于理解的词汇、方式，阐述所需汇报的内容，以便报告更容易理解。

例如，对于工程师，报告的内容通常是和技术相关的；而看你报告的人，也可能包含非技术职位的人员，例如，市场总监。那么，你的报告应该尽量减少技术术语的使用、而是使用更通俗易懂的词汇，表达你的内容。

一次记忆深刻的客户支持

相关客户: 四川长虹，位于四川绵阳

这是发生在2007年11月的真实故事。当时，公司为长虹提供了一款新型的处理器芯片，长虹利用这款处理器，设计、开发了一个新品遥控器。长虹负责遥控器的整体设计，但核心代码，是我司另一部门、负责方案（Solution）开发的同事开发的。

这位仁兄是北大毕业的，个性十足，年龄长我几岁。2010年公司第一次合并时离职了。后来他在绵阳购买了住房，定居在四川绵阳。今年我再次去绵阳出差期间，特意和他约了一次小酒。他现在自己有个小公司，日子过得很是惬意。

书归正传。

长虹已经开发了遥控器样品，初步测试结束后，生产了5000（我们叫做小批量），在生产线的最后环节，做功能检测时，问题发生了。当时得到的反馈是：

1. 有个别（不是所有）遥控器，正常按几次按键后，会发生死机，按键不起作用了；

2. 如果把遥控器的电池卸掉、再装上，遥控器恢复正常工作，且不再出现死机故障；

负责代码开发的同事，搞不定这个问题，找到我们这个部门请求支持。由于同事反馈的信息，都是零零散散的，形不成有效的证据链，且故障不可复现，所以当时判断不出故障的原因，究竟是软件原因，还是硬件原因。所以决定到用户现场去，和用户交流，获取第一手的资料。

为了确定是否芯片本身的问题，我们的芯片设计部门也派出了一名同事（设计团队的一名课长，中国人，比我年轻，但入职时间比我早得多）。我们这边，最初我是打算派一名工程师去调查的，但设计部门的同事要求我和他一并前往（我俩相同级别），于是决定次日出发，预定酒店、机票等等。

第二天午前时分，到达绵阳机场，坐出租车去酒店。印象中当时的出租车是小面包车，并且发票还是手写发票。半小时后，到达同事提前帮忙预定的酒店，我记得酒店的费用是380元/晚。当时我们出差的住宿标准是500元/晚，这在当地能住很不错的酒店了。

午饭、短暂休息后，和代理商的工程师一起赶到长虹的生产车间。现场和生产线上的测试工人师傅详细了解了测试方法、发生故障的现象，并且拆解了遥控器样品。当时得到的初步结论是，故障的原因，应该不是遥控器的电路板焊接造成的。那么，问题的原因一定出在遥控器的核心处理器及其程序代码了，而这一部分正是我们公司提供的，这下麻烦大了。

设计部门的课长，也和日本总部做了深入的沟通，确定芯片本身肯定不存在问题，因为已经有其他公司，使用相同款的处理器，开发了遥控器，且已经大批量生产。那么可能性最大的就是这位北大同事写的代码了。

不过，如果是软件的问题，那么同样的故障现象，应该发生在所有的样品，才是符合通常逻辑的。但当时的事实是，仅有个别几个发生故障。所以也不能肯定，就是软件造成的。但软件的可能性比较大。该怎么排除软件原因或者说明确是软件原因呢？

最后，我想了一个方法，试图调查是否软件的原因。

由于手指按遥控器上的按键时，会发生一个电脉冲信号，发送到遥控器中的处理器芯片，通知芯片有按键动作，需要处理。那么，使用信号发生器，在处理器芯片的管脚上，发送不同频率的脉冲信号，代替人的手指按下按键时产生的脉冲信号。通过这个方法，看看是否会出现用户处发生的故障。

于是，马上电话通知团队成员，在公司的实验室，按照这个方法，做大量的测试（不同频率的信号，循环发送到芯片的连接按键的管脚上）。傍晚时分，收到了团队成员的电话，实验有了结果，并且获得了明确的结论。

一次记忆深刻的客户支持 （续）

同事电话中说，当信号发生器发送频率为 180KHz的信号到芯片的管脚时，会发生遥控器死机的现象。并且是可以复现的，其他频率的信号，不会发生遥控器死机现象。这个现象充分解释了用户处发生的故障：当用手指按下遥控器的按键，碰巧产生了180KHz 的脉冲信号时，那么造成遥控器死机。而这个频率的脉冲，不是每次按键都发生的，是偶尔发生，和用户按键的力度、速度有关。所以，用户在测试时，偶尔会发生死机故障。

好了，现在原因定位了：是遥控器的程序代码有问题。

当时和我司写代码的那位北大仁兄交流说，应该是代码有问题。他很不以为然，毕竟他在遥控器方面经验丰富，并且这个代码基本是从现成产品移植过来的，感觉不会有问题。

初步定位了问题的原因，那么下一步需要给出解决方案，因此还需要做更深入的调查。后续的调查，需要深度分析遥控器的源代码。结果和北大的那位同事协调，同意开发一部分源代码给我们调查。最后，恰恰是这部分代码，是造成当前故障的原因。

经过团队的几天努力，最后确定是代码中一条程序指令的位置不正确，造成这个故障现象。后来我专门写了一篇案例分析，用于团队成员的拓展培训。以下是案例分析中的最后一项内容：感想。