惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

aimingoo的专栏
aimingoo的专栏
S
Securelist
博客园 - Franky
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
IT之家
IT之家
GbyAI
GbyAI
Microsoft Azure Blog
Microsoft Azure Blog
The Cloudflare Blog
云风的 BLOG
云风的 BLOG
N
News and Events Feed by Topic
AI
AI
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Schneier on Security
Schneier on Security
Attack and Defense Labs
Attack and Defense Labs
Vercel News
Vercel News
腾讯CDC
Google DeepMind News
Google DeepMind News
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
M
MIT News - Artificial intelligence
WordPress大学
WordPress大学
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
N
Netflix TechBlog - Medium
量子位
S
Schneier on Security
Hacker News: Ask HN
Hacker News: Ask HN
Cyberwarzone
Cyberwarzone
S
Security Affairs
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
N
News and Events Feed by Topic
T
Tenable Blog
PCI Perspectives
PCI Perspectives
MyScale Blog
MyScale Blog
L
Lohrmann on Cybersecurity
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
Cyber Attacks, Cyber Crime and Cyber Security
W
WeLiveSecurity
N
News | PayPal Newsroom
P
Proofpoint News Feed
O
OpenAI News
C
CERT Recently Published Vulnerability Notes
B
Blog
Cisco Talos Blog
Cisco Talos Blog
Microsoft Security Blog
Microsoft Security Blog
V
Visual Studio Blog
MongoDB | Blog
MongoDB | Blog
大猫的无限游戏
大猫的无限游戏
A
Arctic Wolf
Y
Y Combinator Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Spread Privacy
Spread Privacy

博客园 - 秋实

爱恨之数据 舍得之项目经理 绩效 遇上离职潮 系统性思考 半路接活 说说我最近比较迷的Criminal Minds 我们需要什么样的故事 好不好真的只有用了才知道 看板还是Scrum 敏捷的生产--丰田模式之减少浪费 敏捷的生产--丰田模式之精益生产 牢骚篇 -- 南京的雨污分流 警惕那些懂技术的PO 让敏捷的回顾会议变得有趣而高效 扫清被遗忘的角落--可怜的印度文档MM 敏捷的基本关注点- 记录我与公司内敏捷推广者的一次交流 敏捷还得要专业--记我的一次丢人事迹 KFC如何拒绝自带食物呢?
面试摘录
秋实 · 2011-03-08 · via 博客园 - 秋实

  今天下午有幸借助面试的机会和一位青年才俊做了较为广泛和深入的探讨。在南京面试了不下几百个.net开发人员,能在这个年纪有如此追求和理解的人还是头一回见到,说实话,越聊我自己反而越激动,先在这里祝福一下后面的谈判进行的顺利吧。毕竟有个急缺的位置空了很久,难得碰到如此好的人才,希望不要错过。

  在和他聊天的过程中,我感觉他是一个被外包项目运作模式“伤害”过的孩子。以下是几点我和他问答的摘录。问的是他,答的是我。

  问:你们公司有bug管理工具吗,有没有什么千行代码bug率....

  答: 我们公司主要用的是QC。不存在bug率的说法。对于一个产品的质量来说,用bug率来衡量一个开发人员的绩效是不合理的。如果一个开发人员整天面对的是无休止的变更,不稳定的底层框架,怎么可能有高效而稳定的代码呢?一个产品的质量必须由整个团队来承受,我们可以统计bug率,但是这个是给团队看的,团队必须认真分析bug的root cause,它的由来是什么,团队如何改进。如果是需求的不稳定,那么团队需要在进入分析设计前需要更严格的把关,对需求需要加深理解,建立快速迭代来解决不确定的地方。。。所以,任何情况下,单纯的依靠bug率的数据来评价一个开发是不公平的。

  问:你们的进度安排会不会很紧。。。需要加班吗

  答:起码我们团队的被动加班次数为零吧,或者少到我已经记不清楚了。应该来说,对于个产品型的公司,进度的安排会松到让你一开始不适应。。。。

  问:那多出来的时间,是给你们作重构的吧?

  答:不,多出来的时间是思考的时间。为什么项目还没做完就想好了要重构?为什么不在开始前就想清楚呢?我们不需要重复的体力劳动者,我们需要的是一个不断思考自我改进的研发人员,对产品和过程能够提出自己独立见解并能够付之行动的人。我们不希望把更多的事情依赖于后期的重构,能做好的事情为什么不一次性做好呢?写代码的时候应该是整个思路已经比较清楚了,我们不能指望边写边想,那样的代码是无法让人放心的。技术的负债会越背越重,重到有一天你不再想去看它想它。

  问:你们的技术方面与别的公司比有什么优势吗?遇到什么困难吗?

  答:其实我对其他公司的技术细节不可能了解太多。作软件尤其是企业软件,很少到最后是拼技术的,大部分还是市场能力和定位。作为我们来说,我们责无旁贷的要按时提供高质量的产品。现在的技术资料在网上可以很方便的得到,应该是没有什么秘密可言的。难就难在你是否能找到一个最合理的解决方案。net平台下那么多的集合类型在那种场景下用哪种在每次“落笔”前是否反复推敲过?这是一个不断改进的过程,我们允许犯错误,但是不能看不到自己在犯错误,满足于能跑能用就行了,这是对自己的不负责任对产品对团队的不负责任。

  问:你们公司有什么学习,培训之类的?

  答:我们不可能指望每个人都能每天都学习新东西。这个必须结合他的个人能力以及当前的工作之间的能力匹配度。只有在工作有余力的情况下,我们才会鼓励去看一些与工作有关的更前沿的技术和知识。如果愿意分享,那就更加完美了。而且这种分享,是一种自我实现,自我能力的展现,不能总是让人感觉到你很棒,但是拿出来确实棒槌。只有展现出来,得到大家的认可,才能为以后的提升提供证明。