Yurii谈工作


因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少。很多候选人有多年的工作经验,常见的框架也玩得很溜。然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力。这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求。

软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论。正巧,最近我看完了新鲜出炉的《微服务设计》,所以大概可以谈谈自己的看法了。因为这类问题比较抽象,也没有统一答案,我努力尝试把思路整理清楚,把表达变得流畅。最终有没有讲清楚,说的对不对,欢迎大家给我留言。

(more…)

最近有好几个朋友同事问我,一直都在做软件开发,想做软件架构,要如何入门呢?我从一些提问里感觉到,架构有时会被一些人理解为《葵花宝典》、《九阴真经》一类的秘籍,功力不到绝不能碰,功力到了才能专门修行。

可惜这种认知是不对的。架构的工作虽然比开发复杂,但脱胎于开发,它与开发之间并没有绝对的界限。即便只是做开发,也不妨碍你积累架构经验,从架构方面理解和看待问题,而这些,都是未来成为专职“架构师”的必要积累。所以,我现在尝试回答“做软件架构该如何入门”的问题,为各位正在做开发,但未来希望从事架构的同学们提供几点参考意见。

(more…)

上海的很多朋友可能已经知道了,最近我们(沪江)正在大力招聘架构师和Java工程师。招人过程在紧锣密鼓进行的同时,我们内部也在不断总结数据,收集反馈,提高效率的同时尽力照顾候选人的感受。

我们也注意到,候选人的部分反馈是比较有共性的。经过仔细分析,我们确认这些反馈是可以理解的,但是我们更确认在技术招聘中必须有所坚持,最终才能得到好的技术团队和系统。所以今天我想“私器公用”一把,讲讲我对技术招聘和技术人员成长及评价的若干观点。

(more…)

之所以写这个话题,是因为最近见了不少的分享,觉得甚为惋惜。这些分享的演讲者往往有很多的积累,在某些领域确实掌握了非常多的知识,也非常真诚,希望把自己掌握的知识和盘托出。可惜的是,分享的效果往往不如人意,哪怕听众本来对这个话题有兴趣,真正聆听的时候也感到枯燥乏味,因而意兴阑珊,听完之后一头雾水。

问题出在哪里呢?在我看来,问题出在演讲者没有重视“演员的修养”。

什么是“演员的修养”?很多人听到这个词会有朴素的想法,觉得无非是虚头巴脑的伎俩,刻意把真实的自己藏起来,巧言令色,迎合其他人的喜好。这种作派对于分享和演讲,真的有什么帮助吗?

确实没有什么帮助。但是,这并不是演员的修养,因为演员的修养包括更重要的内容——移情,也就是放弃自我,进入另一个角色,用完全不同的方式来思考和行为的能力。

(more…)

之前的《创业不等于职业生涯加成》是我根据最近的面试经历,随手而作,没想到创下了近期阅读和传播的新高。随之也引起了不少讨论,某些反对意见认为“创业并非一无是处”,并列举了创业能给人带来的技能上、性格上、思维上的各种磨练和收益。这些论据当然有道理,但是和我说的观点并无矛盾——“不等于”的意思是,不要以为你创过业,你的职业生涯就自动升华了。

说得更直接点,“创业”绝不是职业生涯中的金字招牌,单纯“为创业而创业”,很可能结果是头撞南墙、遍体鳞伤,却无甚收获。这次我把话题说更详细点,希望理解的人更多,误解的人更少。

前段时间一个工作不久的朋友跟我说,离开了某创业公司,才觉得之前的同事都很苦。他们做的是大量重复性的劳动,却是公司业务发展不可或缺的支柱。但是,公司完全是出于“降低劳动力成本”的考虑在安排这些同事的工作,低廉的待遇,超长的加班时间,唯一能维系大家的,就是公司创始团队对牺牲精神的强调,以及不断吹嘘的愿景,当然那些诱人的长期回报从来都只是若隐若现,没有扎实的落地措施。

(more…)

面试,无论对哪家公司来说,都是件重要的事。

因此许多公司很重视面试,制定了面试规范,以及对面试官的一系列要求,网上关于面试礼仪的文章更是汗牛充栋。然而,很多面试的效果仍然不够满意。最显然的表现是迟迟没有找到合适的候选人——尽管他们本来合适的,更糟糕的是没有给候选人留下好印象。在这个“人人都有麦克风”的时代,这种印象很可能通过面试官和公司意料不到的渠道传播出去,造成一系列的麻烦。这种情况,相信是任何公司都不愿意看到的。

要如何避免这种问题?怎样才能真正把面试做好?在我看来,规范、技巧、礼仪都不是最重要的,最重要的是公司对待人才的态度,具体落实下来就是面试官的态度。如果面试官能做到“正心诚意”,面试的效果通常不会太差。

正心诚意,用直白的话说,就是两个词:尊重、诚恳。

(more…)

最近面试了很多技术人员,其中不少之前的工作履历还不错。但是,因为他们之前的创业经历,我并不能发offer。

看到这里先别着急下结论,让我仔细说说理由。

(more…)

技术领导要不要写代码?这是一个问题。

我刚工作的时候就听说,程序员(那时候还没有“码农”的说法)是吃青春饭的,到30岁就熬不了夜写不动代码了,所以要尽早转管理岗。相应的,如果你走上管理路线成了技术领导,自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多,技术能力增长很快,但总感觉有点别扭。那感觉就像,你能把车开得又快又熟练,最终只是为了能按时到达机场赶上飞机。然后,你就再也不用开车了。

不过无论如何,赶上飞机看来是更高级的选择,为了它,放弃苦心修炼的车技也可以接受罢。

但是等我真正走上管理岗位,才发现事实和我想的完全不一样。当时公司的业务增长飞快,支持业务的系统却是几年前“一锤子买卖”的外包项目,更要命的是技术团队的人员组成和工作习惯还处在作坊状态。从我的角度来看,四下里全是大坑,填坑的速度慢得让人着急,在此过程中还经常挖下新坑…… 在我的职业生涯中,我从没有在那么短的时间里写过那么多代码。几年后大家查提交排名,我的名字仍然第一。好在我的努力没有白费,系统终于没有垮掉,顺利回到正轨。

当时我身为技术领导,除去招人、定流程、做运维,还花了大量时间写代码,这样的做法是对的吗?如果是对的,后来我再没有写过那么多代码,好像也与“不称职的领导”无缘,甚至还被夸奖过“忍住放手让下属去做事,锻炼了组织”,这又是怎么回事呢?

(more…)

我有时会帮朋友们做些工作引荐,所以经常见到一种可惜的情况:有些人明明素质很好、专业很过硬、经验很丰富,偏偏简历做得太过敷衍潦草,一眼看去泯然众人、毫无亮点,甚至让希望引荐的我感到汗颜。看来,有必要认真谈谈简历这件事情。

要想找到好工作,简历是敲门砖,所以怎么重视都不为过,尤其是要提供“抓人”——也就是能给简历阅读者留下深刻印象——的简历。

(more…)

你知道GPS是怎么发明的吗?

马里兰州罗瑞尔市坐落着约翰·霍普金斯大学的应用物理实验室(APL)的自助餐厅,长期以来都是就职于实验室的物理学家、数学家、技术人员聚会的热门地点。在1957年10月7日的午餐时间,大家讨论得异常热烈,因为苏联刚刚发射了第一颗人造卫星。

两位年轻的物理学家威廉·吉尔和乔治·韦芬巴赫也参与了讨论。他们首先确认这不是苏联的把戏,因为确实收到了来自太空的音乐。继而他们忽然想到,可以利用多普勒效应来计算卫星的移动速度(简单说,多普勒效应就是指信号源或接收器在运动状态时,相对速度与波形频率的固定关系。如果你路过鸣笛的消防车或救护车,会觉得随着它们的远离,鸣笛的音调也下降了)。结果,吉尔和韦芬巴赫用了几个小时,就实现了收听、测量、跟踪的功能。

过了几周,一个无组织的科学家团队在此基础上补充细节,研究关于轨道卫星的理论,提出了改善建议。之后,APL负责人批准了款项。于是APL的科学家们有了一整套算法,能够精密地测算出卫星的运动轨迹。

到了1958年春天,APL的副主任弗兰克·麦克卢尔把两个家伙叫去办公室,神神秘秘地问:如果卫星运动时,可以用固定的地面接收器来计算卫星的方位,那么反过来,卫星固定,地面接收器运动,能够测算出接收器的位置吗?这个问题没有人想过,也没有人评估过。经过几天的紧张计算,吉尔和韦芬巴赫确认:“反向定位”是可行的。

2年后,美国实现了“反向定位”系统,最初用于为潜艇确认位置。1983年,大韩航空的班机因为导航故障误入苏联领空被击落之后,美国向民用领域开放了整套系统。这,就是今天我们熟悉的GPS。

(more…)

Next Page »