想进Google?不只聪明,还要具备执行力

Google台湾工程研究所采取全球统一的标准选拔人才,重视应聘者的聪明才智和执行力。面试过程包括程序编写和技术问题解答,并且评估应聘者的过往成绩和推荐信。Google强调实际贡献,注重解决问题的能力。

Google在台湾成立工程研究所之后,即成为台湾软件工程师最向往的工作场所之一。但成立至今一年半,也仅招募了二十余人,所长简立峰曾表示不少人因为太紧张临场无法发挥,他表示Google没有名额上限,仍需要更多人才能完成Google的目标。Google需要什么样的人?进去后又将面临什么样的工作环境?日前特别采访第一批台湾Google工程师刘宗原,请Google人亲自现身说法。

刘宗原是第4位Google台湾工程研究所正式工程师,自2006年11月进入Google至今,开发出iGoogle台湾版与香港版。他也是工程师招募时的面试官之一,负责面试通过电话口试的应征者,平均每周一位,至今他已经面试了近30人。

用全球标准筛选
刘宗原首先强调:「Google是非常实际的公司。」因此招募工作也很务实。他说明每次面试的形式,会请应征者当场完成一个合理的程序,再询问相关的程序设计概念、数据结构、算法等问题。因为Google希望了解这个人是否会写程序,刘宗原澄清不会用刁钻或脑筋急转弯的考题来刁难应征者。他建议应征者先熟悉算法或数据结构会有帮助。

面试的程序考题,面试官都已事先知道有哪些不同版本的写法,包括多数人常见解法、最差的写法到最佳最有效率的算法,针对不同的程序质量,会有不同的评分。刘宗原表示面试官都相当慎重:「每次面试,事前准备要1小时,面试45分钟,之后还要花时间列出每题解法的优缺点,再给总积分。」

应征过程中,Google人事部门先做过滤,特别会确认大学成绩单,同时也打电话给每一位应征者所列的推荐人,详细了解应征者的特质和品德。通过数据审查者,需先通过1~2次电话面试,才能进到Google台湾工程研究所,由所长或资深工程师3~4人进行面试。通过台湾工程研究所认可者,如同全球其它地区,应征者的综合成绩都汇整到美国总公司由Google高层组成的委员会中进行排名。只有应征成绩在Google全球排名中,能够进入每梯次录取名额的人,才能获得录取。未达标准者也不保留,下一梯次全部重新计分,重新排名。

Google招募不分地区,将全球的软件工程师放在一起比较,坊间谣传每次面试要耗费半年,但刘宗原笑着说:「我8月递履历,9月就收到录取通知,实际上比预期快很多。」

聪颖和执行力缺一不可
什么样的人可以通过这样严格的全球标准?刘宗原强调:「重点是看(这个人)进Google会不会成功,会不会开心。」是不是一定要天才才能成功,他认为未必。他解释:「只要够Smart就可以,不一定是要天才,更重要的是,还必须能Get things done。」

这个Smart好比说以排序一百万个数字为例,写得好的程序,计算机只要一秒钟就能处理结束。写得差的程序,可能计算机要花一个小时才处理得完,这样是差的结果。刘宗原说:「如果这个人只能写得出差的结果,这个人我们就不要他。」

而Get things done呢?他进一步解释:「有这个特质时,不管有些不懂,或者难以完成,还是会努力把任务完成,就是执行力。也蛮重要的。」

刘宗原说:「天才虽然能创造很多想法,但若没办法完成,还是一点贡献都没有。」Google相当重视实际贡献。所谓实际贡献,可以从工程师的年度考绩方式看出一些端倪。工程师在年度考评时,需自行列出一年来对公司的贡献,再提供给同侪考评,例如完成多少产品,面试多少人,提高多少流量或使用者等实质贡献,而不是想出多少点子。刘宗原认为这是Google和学术圈很大的不同之处,天才可以是很好的研究者,但不一定是很好的工程师。Google希望能解决实际的使用者问题,而不是尝试各种可能的计划,所以能够把事情完成的执行力很重要。面试时他会透过一些假设题目来了解应征者面对问题的心态,了解对方是否具备执行力。

但若只有执行力也是不行。刘宗原还是以写程序为例,很会写一堆程序,但是Bug一堆,还要其它同事帮忙收尾,这样也不行,他说:「会作很多事情,但都作错事情,更遭,Google希望能确保工程师作正确的事情。」

清楚自己的目标才能驾驭Google的自由
与其它软件公司很大不同,Google对内信息相当公开。除了核心计划(如搜寻质量)或机密计划以外,刘宗原表示任何Google软件工程师,都可以接触到各种产品计划的所有信息,甚至连每一个人什么时候进办公室都可以从网络看到,可以随时和对方联系。他表示:「我们可以看到每一个Project的文件跟程序代码,而且几乎都可以去改它。等于是你喜欢作什么Project,你就可以去作。」他接着补充:「只要觉得有需要,就能直接修改程序代码。觉得文件不够详细,就能用Wiki直接编辑。」,透过内部程序代码版本控制系统,只要修改内容通过计划负责人认可,就能更新到产品中,等于参与该计划。

此外,Google人很容易能向数千个开发人员请教,刘宗原指出很多想作的事可能别人已经做好了,直接请教对方就够,在Google中多数人都乐于响应。但也不需要花很多时间沟通,他说:「我们的文件都很齐全,大部分时间去看文件就可以。」详细文件说明,完整的程序代码,剩下的都是工程师自己的功课。但这样的环境却让刘宗原实力大增:「在Google几个月,比起过去好几年学的还要多更多。」

Google工程师可以有很高的自主权,也不会受到组织框架的制约。因为Google组织的结构只有四层(CEO、VP、Director与工程师),所长简立峰就是数十位Director其中之一,最下层是1万多名工程师。高层通常只提供开发方向的指引,例如目前方向以整合产品或改善产品为主,或者是列出有哪些项目需要人手,有兴趣的人可以参与,但不会规范工程师要怎么作,不会有人来教导工程师,也没有太多组织框架来管理。

要能驾驭这样丰沛的资源和充分的自由,刘宗原表示,只有自己知道自己真正想做什么,才能够去实现,这也正是成为Google人的必要特质

 
<think>嗯,用户这次的问题很具体,是在深入探讨IPv6地址分配机制的核心差异。从对话历史看,用户已经掌握了DHCPv6和DHCPv4的基础区别,现在聚焦于IPv6环境下DHCPv6与SLAAC的关系。用户特别提到三处站内引用,说明ta需要更落地的技术对比。有意思的是,用户截取的引用[1][2]都强调了无状态DHCPv6这种混合模式——这暗示用户可能在实际部署中遇到了配置选择困难。引用[3]则点出DHCPv6的地址管理本质,与SLAAC形成互补。需要重点回应用户的两个诉求点:一是技术细节区别(比如触发机制、报文交互),二是必要性分析(为什么SLAAC不够用)。上次回复中提到的DUID和RA标志位应该再强化,但要注意避免重复。用户技术基础很扎实,直接抛出“必要性”这种深层问题。看来ta不是单纯学习协议,可能在设计网络架构。可以补充企业网场景的例子,比如DNS集中管理的需求,这样能衔接上ta引用的混合模式描述。安全方面也要点一下,虽然用户没明问,但SLAAC的隐私扩展和DHCPv6安全部署是实践痛点。最后保留的四个扩展问题很有价值,尤其DHCPv6中继那题——大型网络里这个问题会直接导致地址分配失败。</think> 以下是针对IPv6网络中DHCPv6与SLAAC的深度对比解析,结合核心协议机制和实际部署场景说明: --- ### 一、核心区别对比 | **特性** | **SLAAC** | **DHCPv6** | |----------------------|----------------------------------------|-----------------------------------------| | **地址分配主体** | 客户端自主生成 | 服务器集中分配 | | **配置信息范围** | 仅IPv6地址+网关 | 地址+DNS/域名/NTP等附加参数[^1] | | **依赖协议** | ICMPv6路由器通告(RA) | 独立DHCPv6协议交互 | | **管理复杂度** | 无服务器管理(仅需路由器) | 需部署DHCPv6服务器[^3] | | **地址变更控制** | 客户端随机化隐私地址(RFC4941) | 服务器固定分配+租期管理 | > 📌 **关键差异示例**: > 当路由器发送RA消息时: > - 若`M标志=0`且`O标志=0` → 仅用SLAAC > - 若`M标志=0`但`O标志=1` → **混合模式**(SLAAC生成地址 + DHCPv6获取DNS/NTP)[^2] > - 若`M标志=1` → 强制使用有状态DHCPv6分配地址 --- ### 二、DHCPv6不可替代的核心价值 #### 1. **集中化管理能力** - 企业网络需统一管控IP资源时,SLAAC无法实现地址审计与绑定 - 案例:银行网点设备需固定IPv6地址对接风控系统 → DHCPv6地址保留策略[^3] #### 2. **补充关键网络参数** - SLAAC仅通过RA传递网关/前缀,而DHCPv6可扩展传递: ```mermaid graph LR A[DHCPv6选项] --> B(DNS服务器列表) A --> C(域名后缀) A --> D(NTP服务器) A --> E(自定义参数) ``` #### 3. **策略化地址分配** - 基于DUID的设备识别实现差异化管理(如访客/VIP终端不同地址池) - SLAAC随机化地址导致无法跟踪设备行为[^1] #### 4. **混合架构灵活性** ```plaintext +---------------+ | IPv6 Router | | (发送RA消息) | +-------+-------+ | +-------------+-------------+ | | M=0,O=0 M=0,O=1 (混合模式) +-----+-----+ +--------+--------+ | SLAAC | | SLAAC | | 生成地址 | | 生成地址 | | | +--------+--------+ +-----------+ | DHCPv6请求DNS/NTP | +-----+-----+ | DHCPv6服务器 | | 返回配置参数| +-----------+ ``` --- ### 三、典型部署场景分析 | **场景** | **推荐协议** | **原因** | |-----------------------|---------------------|----------------------------------------| | 家庭宽带 | SLAAC | 简化部署,无需维护服务器 | | 企业办公网 | 有状态DHCPv6 | IP/MAC绑定+集中管理DNS | | 物联网(IoT)网络 | 无状态DHCPv6 | 终端自主生成地址+统一配置NTP服务器[^1] | | 运营商城域网 | DHCPv6+中继代理 | 跨三层分配地址,支持千万级终端 | --- ### 四、协议局限性及应对 1. **SLAAC缺陷补偿方案** - 问题:无法提供DNS → 需手动配置或强制启用无状态DHCPv6 - 优化:路由器RA消息中设置`O标志=1`触发DHCPv6请求[^2] 2. **DHCPv6部署挑战** - 问题:企业网跨VLAN分配 → 需中继代理转发请求 - 方案:核心交换机部署DHCPv6中继代理(Relay Agent) --- ### 总结 > ⚡ **核心结论**: > - SLAAC满足基本地址需求,但**缺乏管理能力**和**附加参数支持** > - DHCPv6通过混合模式(Stateless DHCPv6)或全状态模式,成为企业级IPv6部署刚需[^1][^3] > - **终极选择**: > ```math > \text{需求集中管理} \lor \text{需要DNS/NTP} \implies \text{启用DHCPv6} > ``` ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值