识，而是他掌握的知识与学会这些所花的时间之比。

对于初入开发岗位的你来说，每一次踩到一个坑然后独立填坑的经历都将会加速你对更多技术领域内的知识和问题的学习速度，也将会提高你作为一个工程师的价值。

如何与产品沟通?

在技术圈里这是老生常谈的话题，我认为与产品沟通的过程中是最能体现出一个程序员情商的时候.无论对方提出的需求是怎样的，你考虑问题的逻辑应该是：当前提的这一条需求做完以后对产品有什么收益?对技术这边又有什么收益?更重要的是leader们是否会在乎这一点?

然而这一切都应该发生在你的内心中，权衡利弊之后如果有什么没考虑到的你可以提出来，如果并不是十分确认自己的想法，你可以等会后私下里和你的leader提出自己的看法，这既是对leader的尊重也是节省开会时间。

幸运的是，在互联网这个行业里，需求沟通的过程中，技术人员的话语权通常还是较大的，然而绝不要滥用你的话语权。

我可以扪心自问的说，在我正式入职以后沟通过的每一位产品，没有和任何一位发生过争吵，相反的是产品们都愿意与我对需求。

这并不是因为我把PM们当大爷一样供着，对任何奇葩的需求都有求必应，而是因为我往往把“与PM对需求”这件事放在“人情”这样感性的层面来考虑，而不像很多程序员那样只考虑代码逻辑的理性思维方式。

人是复杂的动物，一个PM提出了一个看似无理的需求，你却不应该不问青红皂白直接拒之门外，设身处地将心比心的想一想，公司里这样复杂的环境下，他/她是否也有自己的无奈和苦衷?如果有，这个问题是否存在其他折中的解决方案?

武断砍需求的程序员往往错过了这样的商讨“折中方案”的机会，同时也错过了一个让PM认可你的机会!这一点其实很重要。

我见过很多同期进公司的校招生，他们把职场中“老油条们”习以为常的做事方式直接照搬到了自己的行事风格当中，内心里对PM的抱怨将会在潜意识里左右你与PM沟通的态度和方式。

换个角度考虑，我倒觉得在其他职位的人眼中，你的技术多么多么的NB他们是无法直观洞悉的，每一个无理取闹的需求也都是一个你证明自己的机会。

更重要的是，公司里与产品交涉问题并不同于市场上买菜那样，你们的工作很可能在接下来的几个月中都存在沟通和交集，今天你卖给他一个人情，明天他也会替你扛一个线上的错误， (说实话程序员在代码上线之前往往喜欢叫PM来做最后确认，言外之意是上线是你确认的，出了问题也得你扛着.我觉得一个项目是大家一起做的，说句良心话，把所有的责任一股脑全部都推给PM我个人认为也是不公平的，PM往往在很多项目中充当“背锅侠”，人要相互理解)人非圣贤孰能无过，任何线上的代码都不可能永远是不出错的.PM对于一个之前敲定好的需求的修改，确实有可能是出于他本人工作上的疏忽，但是这不代表你的工作就不会出错，如果人之间没有“良好的信任关系”，问题就会被相互放大，像手电筒一样给别人挑错很简单，难的是互相的弥补对方的失误从而建立一种长久的友好合作关系，而能做到这一点也正是所谓情商的体现。

情商不是叫你如何精明的算计对方，那叫“别有用心的智商”，情商是包容与理解。有了人情作为基础，我觉得没有哪个PM会和你在一两天的deadline问题上面扯皮。

即使利益之间的冲突真的无法解决，也没有任何折中方案，你至少可以把问题记录下来，拿到leader们那里交给他们去做决定，而没必要当面撕破脸伤及双方的感情，毕竟产品是公司的，人际关系是自己的。

如何看待加班?

加班就像借钱，原则上必然是救急不救穷.然而并不是说对于一个“穷”的部门程序员就一定要选择离开，这既不是负责任的表现，又错过了一个成为部门核心骨干力量的机会.很多公司里的leader都是在危难关头扛下了部门的人手不足的压力，leader的职位也就顺理成章.除非部门真的气数已尽。

ruby on rails的作者曾说过，熬夜加班相当于借高利贷，偶尔一次可能是难免的，但如果你的工作长期需要你熬夜加班(IT运维岗除外)，你可能确实该考虑换一份工作。

最后祝愿各位未来的程序员在校招的潮流中能够成为offer收割机，并且得到自己真正心仪公司的offer!

如果觉得本文中说的确有些干货，欢迎各位同学点击文章底部的打赏按钮为我的博客募捐.捐款不在多少，却是一个能够让我坚持精品原创博客的动力.对web方面感兴趣的同学，可以关注下我最近在搞的一个开源项目veneno，项目主张以Node.js来进行web安全方面自动化攻击、防御的一些实践。