链接：https://www.zhihu.com/question/22420900/answer/21458811
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
Facebook 工程师说 Facebook 只招 full stack engineer，那我就来说说 Facebook engineer 都是怎样的人啦。
我觉得任何一方面的具体经验都不重要，重要的是思维方式和学习能力。首先说思维方式，那就是不为自己设限，不会想着自己是前端工程师，所以后端的东西我就一点也不碰。Facebook 的工程师，级别越高就需要保持越大的影响力。如何创造更大的影响力，就是寻找当前杠杆效应最明显的问题来解决。有些问题你解决了的话，投入进去的时间每小时能换回来一千美元；有些问题你解决了的话，投入进去的时间每小时能换回来一百万美元。然而哪些问题更值得解决，这是动态的，往往还存在衰减效应。如果现在性能瓶颈在后端，你做了一个季度两个季度优化后，瓶颈就已经不在后端了，你再优化下去衰减效应就会越来越明显。等瓶颈变成前端了，你是不是就说因为你不懂，所以不愿意碰？那就相当于寄望于公司有个前端很懂性能优化的人来解决，但如果公司没有这样的人那就没有人来解决了。
Facebook 的众多海报当中，有一张写的是「任何一个 Facebook 的问题，都不是别人的问题」。有问题，你就需要去评估是否值得解决。如果值得解决，你就应该着手去解决，而不是假设公司内会有另外一个人比你更合适解决这个问题。这时候很可能你就需要去做你从来没有做过的事情，需要学习你原本可能完全不懂的技术。如果你是个专门做数学模型的博士，加入 Facebook 原本是打算做搜索结果优化的，结果发现这不是最急需解决的问题，JavaScript 性能才是最需要解决的问题，你怎么办？如果你以为 Facebook 需要的是你做数学模型的经验，那你就错了。Facebook 需要的是你完成博士学位的学习能力。你从来没做过 JavaScript 并且觉得 JavaScript 很恶心？正确的做法是立即在网上买几本 JavaScript 入门的书连夜看完，然后着手分析性能瓶颈并且解决。在你完成手动优化后，你还可以思考一下能否把这做成自动化，例如说在代码提交时分析 JavaScript 语法树并且指出可能成为性能瓶颈的地方，又或者说从用户浏览器那里收集性能数据扔到 Hive 然后再从中分析产生瓶颈的特征。这些都可能涉及到一些你没有做过也没有学过的东西，但问题摆在那里你就需要去解决，而无论这要求你去钻研什么。这就是我所说的学习能力。
这是高级工程师和初级工程师的主要差距。尽管在高级到初级这一维度上，美国工程师和中国工程师是有重叠的，但美国的教育体系和行业传统使得美国应届生比一般中国工程师更偏向于高级那一端。美国学生的优势在于，他们的教育体系让他们习惯面对开放性问题。一家公司万千问题当中，此时此刻哪一个最值得解决？这不是中国工程师擅长的问题，因为实在是太开放了。中国教育让人擅长在给定条件下解决问题，太开放反而不知道从何入手。此外因为绝大多数文献都是英文的，所以要钻研什么对于能读懂英文的人来说都可以非常成体系的学习，这对于很多拒绝阅读英文的中国工程师来说很不利。拒绝阅读英文意味着永远只能接受别人的二手资料，对于很多概念的理解只能停留在技师的层面，而无法上升到工程师或者科学家的层面。链接：https://www.zhihu.com/question/22420900/answer/21770992
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
做这样一个简单的 app:
一个天气应用，干净清爽的界面，天气信息一目了然。它不仅可以精确预测未来 10 天的天气，还可以显示某地的历史天气信息。它具有自定义提醒功能，支持 web 版本， iOS 版， Android 版。
为什么想要做这样一个 App ？因为你喜欢旅行，但没找到一个天气 App 可以提供你下个月或者某个特定月份的天气信息；因为你懒你没有每天看天气预报的习惯，你想要在第二天温度达到 30 度以上或者温差有 +/-7 度的时候，获得温馨提示；因为你要成为一个 Full Stack Engineer ，你必须不断训练每个 stack 的能力。
## Web版
你决定用 MySql 来存储用户数据，用 NoSql 存储历史天气数据。你用 Redis 作为 cache ，缓存一些最常请求的天气数据。你用 Python 写后台，功能简单，后台不复杂，用户注册登录，抓取返回某城市的天气数据，某地的历史天气数据，很快便搞定。
后台开发并测试好了，接下来是 Web 前端。你十分清楚一个好的 UI 设计对一个 App 的重要性，你也明白 UI 的设计不只是为了美观，更重要的是提高信息的可读性和程序的可用性。幸好你平日的积累这次派上用场了。你把之前保存下来的上百个优秀的UI设计作品拿来研究，你从书架上拿出Norman 的那本经典 - The Design of Everyday Things 重新细读。最终你用白纸黑笔敲定了第一个版本的 UI，简洁直观，没有任何多余的设计，所有元素的排列间距 大小颜色都恰到好处。你相信即使天气不好，但用户只要使用这个 App 都会有着愉悦的心情。
那么开始写前端吧。啊，别急，都忘了还有 Icon 和 Logo ，可是不会 PS ，不会 AI ，不会 Sketch 怎么办呢，学吧。你平日喜欢结交不同领域的朋友，正好几周前在一个活动上你认识一位朋友做设计的。她花一个下午的时间教你基本的 Sketch 的使用，并对你的 UI 设计给出了一些意见。你请她吃了顿晚饭表示感谢，然后立即回家根据她的一些建议重新调整了 UI ，这次你在 PS 里把 UI 画了出来，Icons 和 Logo 也顺道一起做了。
接下来的一周，你学习 HTML，CSS，以及 Javascript，并漂亮地把前端搞定。
## 发布 App
在朋友圈发了个状态，找人帮你做 Beta 测试。他们都首先问你是什么 App，一开始你简单回答一个天气的 App。但你发现，这不能提起他们的兴趣。你觉得你需要用语言，用故事包装一下。不光是作为别人「是什么 App」提问的回答，也是成为 Full stack Engineer 道路上的一个重要技能。
你去看了所有你喜欢的产品的主页，从他们的文案上获得一些灵感启发；你读了经典的 On Writing Well ，发现好的文案，好的设计，其实和好的代码很相似，都是重在交流，如何让他人毫不费劲地明白你要表达的内容。你的故事要吸引人，你的产品介绍要在1分钟内解释清楚，并确保你的父母可以毫无压力听明白。
一切就绪，产品上线了。反响不错，用户持续增加。很多用户希望有移动版本，于是你立即投入到iOS 版本的开发上。
## iOS 版 及 后台优化
你花一周不到时间学习了基本的语法和工具使用便投入到 App 的开发中。你知道 Learn by Doing 是最好也是最快的。由于之前学习了设计的基础，UI ，Icons 很快搞定，不久 iOS 版本便发布了。iOS 的发布带来了更多的用户增长，后台服务器的压力颇大，你知道是时候优化后台了。
你在 AWS 上多开了 2 台服务器，并写了一个 Script 来自动化部署过程。
你改用 uWSGi 协议，用 uwsgi 作为 Application Server。
你使用 Nginx 来做并发，负载均衡 ...
......
......
## 成立公司
用户持续增长，每天你都会收到十几二十封用户的邮件。你很感激这些愿意花时间给你写邮件的用户，你相信他们是你最重要的用户，是潜在的付费用户。如果你把他们像上帝一样对待，他们同样也会把你看作是上帝。所以除了睡觉时间的发来的邮件，每一封邮件，你都会在2小时内给予回复。
果然这样的付出是收获巨大的，他们不仅惊讶且非常感谢你的快速回复，他们会在app store里给你★★★★★的评价，他们在社交网站上分享你的app，他们甚至会主动提出捐款给你。
你从快速的用户增长中嗅到了商机，你开始思考如何赚钱。广告你是坚决不能允许的，你认为再精确的广告也会影响用户体验。你设计了 2 个不同的付费方案，你打算用 A/B 测试看哪个方案更好。你分别给 200 个用户发去邀请尝试付费的邮件，邮件内容你精心打磨过，并在最后写上：CEO & Founder. 通过分析 2 种方案的用户行为，你决定将使用第一种方案。
接下来，你相信差不多是时候成立个公司了。为了省时间，你花 2000 块钱找了个园区挂靠并帮你注册公司。公司的名字让你头疼了很久，你不想只是简单的用这个 App 的名字作为公司名字，你知道公司将来还会做出其他优秀的产品。你希望这个名字简单易记，同时其含义也是你公司文化的象征。
公司注册下来了，但银行那边得自己跑。你联系了一些媒体编辑，邀请他们来试用你的产品；你重新设计了产品主页，并开始写产品的 Blog ；你在各大社交网络都给 App 注册了账号，即做社区客服也为宣传... 这些事大大压缩你写代码的时间。以往你都是以代码量作为衡量自己当天工作效率的指标，所以这些天你总感觉没做啥工作。
这样的发展早已超过你的预期，这个 App 从一个 Side Project 几乎变成了你生活的全部。你跟你女朋友半个月才出去约会一次，她抱怨不断；你1个月没跟朋友出去玩耍喝酒了；你 2 个月都没锻炼过身体... 你意识到, YOU CAN NOT DO THIS ALONE，你需要帮手，你需要找人一起把这个做下去。
但你不是要成为 Full Stack Engineer 么？你现在是了么？
## Full Stack Engineer
设计，后台开发，前端开发，移动开发，运营维护，PS，文案... 好像都会了，这算 Full Stack Engineer 了么？
不，这只是踏上成为 Full Stack Engineer 的第一步。你知道目前只是每个 stack 都懂一点，离senior 或者 expert 还差得远，而要每个 stack 都做到极致，需要大量的时间和精力。精力有限，产品开发紧迫，力不从心啊，这条道路也太孤独，因为你不需要与任何人进行协作。难道要把一些stack的任务交给别人做么？这样算是放弃成为 Full Stack Engineer 么？
不！这不是。
什么是 Engineer？「Engineers are versatile minds who create links between science, technology, and society」。
Engineer 的本质工作是设计，开发出应用于大众的产品。
一个真正的 Full Stack Engineer ，他从生活中发现问题，洞察需求，他设计解决方案，并开发出初始版本的产品。为了达到目标，他愿意去学习任何领域的技能和知识。同时他不追求一个人完成所有工作，如果有人可以比他在某方面做得更出色，便会十分热情的邀请他们加入。
最终他的职位也许不再是 Engineer ，他不再设计 UI ，不再写代码 ... 他的工作不再是 design and building an app or product，因为他有更大更重要的任务要做 - design and building a team or a company which builds great products.
而这时，社会给了他们另一个称呼 - 创业者。尽管众人已忘记他们 Engineer 的身份，但在他们骨子里，内心深处，自己始终都是一个 Engineer 。当他们需要从头再来时，他们毫不犹豫从设计开发产品做起。Nikola Tesla，Ferdinand Porsche，Henry Ford，Jack Dorsey，Mark zuckerberg，Elon Musk ... 细数那些改变了或正改变世界的创业者，他们大多数是 Engineer 背景，热衷于设计创造。他们学习技能和知识，不是为了成为某个领域的专家；而是因为那些 是完成自己目标所需要的。
以上，为我认可的 Full Stack Engineer