Archive for February, 2008

Lifestream/social aggregator带来了什么?

Thursday, February 28th, 2008

image image image

Life stream / social aggregator

我认为这类life stream服务应该属于一种类型的social aggregator, 也就是和RSS aggregator有相当多的类似之处.

friendfeed终于开放注册了,而且还拿到了不大不小的一笔投资,看到webleon点评其高明之处, 我却有一些不以为“然”。

friendfeed开始封闭测试比较早,但soup.io一推出就吸引了不少人尝鲜,刚开始的时候我也和合很多人一样觉得这部就是一个所谓“统一而开放的sns雏形吗”?但自己用一用,发现其实并不是那么回事。

我的感觉lifestream之类的服务,应该称之为一类social network application, 其最早的雏形是friendster里的消息板,本来被认为是个没有太大用处甚至啰里啰唆的东西,没想到,在facebook中这些有用没用的log被显示出来后,大家竟觉得非常有趣。 Twitter类的流行也对这个趋势起了推波助澜的作用,然后一些人觉得这个功能可以单独拉出来做,于是friendfeed, soup.io等就出现了。

有一个open source项目Noserub其实就是这样的一个类似的系统,区别就是他是个开源的项目,软件的性能可能不适合大量用户使用,但自己安装在自己的server上聚合有限的一些数据源应该是可以的。 还有一个值得看看的是http://lifestrea.ms/,支持open ID, microformats等,功能很强大,不过使用起来觉得有些太复杂, UI设计我觉得有些太啰嗦。

统一而分布的的SNS吗???

和不少人一样,我开始也觉得这样一来似乎就“统一”了(对我自己统一了),而且“分布”了(对别人而言,随便他们用什么服务),但实际上使用下来,我觉得并不能真正的统一什么,这类服务基本都是中心化的服务(以提高feed抓取利用率)。

统一而分布的sns是个很遥远的理想,但是也很容易让人拍脑袋觉得仿佛立刻就被解决了。过去一个常常让人以为可行的解决方案就是Open ID,Open ID是分布的,各种服务都支持了Open ID不就自然分布了?而且统一在个人的Open ID下了?! 听上去有道理,实际上不太管用。(因为仅仅identity的统一只是第一步!)

Social aggregator其实属于一个很高层的应用,因此并不能拔高成统一sns, 不过他的出现自有其道理和意义。 

Social aggregator的作用

一个服务能流行必须要有用,social aggregator的作用是明显的,而且social aggregator常常在两类主要使用目的驱使之下:

  - 用户希望能聚合他人的各种信息来源

  - 用户希望把自己处于不同信息来源上的内容统一呈现给他人

前者,过去的rss aggregator就是一种典型应用; 后者,可能是现阶段最能吸引用户的地方。 

social aggregator的误区

Social aggregator类的流行带来的一个可能的副作用就是信息大量冗余,可能造成冗余的信息垃圾纵横的局面。 而且如果设计不够好,可能导致不同的服务互相聚合处理过的内容,造成更多的冗余信息。设想friendfeed聚合了soup.io的feed, 而soupio又聚合了这个 friendfeed的feed.

中文网络世界里,由于剽窃现象严重,rss和在线rss聚合的出现使得剽窃者们更是如虎添翼,过去还需要人工copy+paste, 现在全自动了。这种情况导致的严重后果在中文搜索引擎内随便搜索就可以看到。不知道这类social aggregator的流行是否会导致search engine最终屏蔽或者过滤掉他们来阻止冗余信息的泛滥。

前途?

这两种需求可能始终是存在的:

  - 用户希望能聚合他人的各种信息来源

  - 用户希望把自己处于不同信息来源上的内容统一呈现给他人

所以说,这类lifestream还只是一个起点,不过是个不错的开始,前路漫漫兮,需上下而求索。

我认为理想之中的social aggregator应该作为一个标准的组件或者服务功能模块而存在,而不是这样的单独服务。

Social network全球分布图

Wednesday, February 27th, 2008

image

source: http://www.lemonde.fr/web/infog/0,47-0@2-651865,54-999097@51-999297,0.html

微软Interview的秘密

Tuesday, February 26th, 2008

本文是“跟我一起来加入微软欧洲开发中心”的后续文章之一,如果您是一位优秀而富有经验的软件人才,能讲流利的英语,并且愿意暂时离开中国来参加我们欧洲的开发中心,那么我们最近正好有一些职位空缺,这对热爱软件技术的开发者来说可能是一个不错的机会。

当然本文并不可能透露真正的秘密,只是考虑到国内很多朋友对我们招聘、面试的过程不太了解而写一篇文章介绍一下。其实,这里所写的招聘过程并非微软独有,在国外很多软件企业都是类似的。相对而言,中国的大多数公司在招聘软件人才的时候,实在太太太不够严格了(当然可能存在客观困难),希望这篇文章不但能对应聘者有帮助,也能对招聘者有帮助。

面试游击战

Joe on software的Guerrilla Guide to Interviewing是我非常推崇的一篇关于面试的文章,可惜我读的时候已经有些太晚了。 :)  不过亡羊补牢,为时不晚。如果您有机会读到这里,我强烈建议您立刻先放下本文,去读Joe的文章先。

这篇文章我没有找到中文版,也不知道是这些方法在中国不太适用(你很可能用这个方法结果一个人也招不到,不过这比找到不合适的人要强很多),还是没有足够多人认同其价值。

微软Interview基本过程

微软developer的Interview基本包括这些部分:

  • Coding test / 编码测试
  • Phone screen /电话面试
  • Onsite interview /面试

Microsoft 内不同的group可能有不同的面试过程,但基本上是大同小异的,在微软作为SDE, 参加interview和编程序一样是一项基本工作,谁都得干,我们内部有专门的培训以便让大家能有效地参加招聘的活动。

Coding test

Coding test是参加我们group的必由之路,如果你不能编写正确有效的代码,我想微软不会适合您的事业发展。对我们team而言,即使非常senior的position, 甚至今后未必以coding作为日常工作的position也必须通过coding test.

Coding test的题目不难(至少我觉得不难 :P), 我认为只要读好大学一年级,或者真正喜写程序并且有实际经验就能通过。不过实际情况是,coding test放倒了惊人比例的人。 在来microsoft之前,我过去招聘人的时候也一定要考coding test, 我经典的题目是写一个wc(words count), 过去n年里这个简单的题目淘汰了98%的人,节省了大量的时间和精力。一般投递Microsoft职位的人已经在HR那里经过了一次screen, 所以coding test 通过率不会像我过去的经历那么夸张,但也绝对是令人惊讶的比例。

coding test不能通过,一定就over了。因为后续interview要花费大量人力物力,所以coding test是一个重要的把关手段。

我建议每个来面试我们的人花适当的时间复习一些基本的数据结构和算法,并不需要很复杂的,只是让自己恢复到一个状态。 

Phone screen

通过了coding test, 通常会被安排电话面试,往往会有多轮电话面试,但根据各人情况而可能很不相同。 Phone screen的面试内容比较广泛,可能包括对相关经历和技术的核实,但基本上可以肯定是,你会被考coding question 和design question.

电话里怎么考coding? 当然借助IM工具这要容易一些,不过如果没有这样的经历,并且不是真正的hard core coder, 这恐怕有些困难。 

回忆我的phone interview, 我以为就是有人和我随便聊聊,准备了一肚子的英文腹稿准备大坎特坎一番,结果对方第一句话就是“Hey, are you ready to write some code over the phone?”, 我几乎晕倒… 好在coding恐怕是我最擅长的事情,所以一阵短暂的慌乱过后对我并没有构成问题。

说实话phone interview中不会出什么难题,只是如果不习惯,加上语言沟通会对面试者构成比较大的压力。我有这些建议:

  • 如果没有理解问题,请interviewer重复直到你理解。要知道interview的时候,如果被interview的人没有听懂我的问题,我会更着急,一定希望尽量让对方理解问题本身。 因此,一定不要稀里糊涂地回答问题,勇于开口提问;
  • 如果你自己认为理解了问题,复述问题,请interviewer确认你的理解和他的理解是一致的; 这我相信是一个技巧,复述问题加深了你的理解,给你争取了更多时间;
  • 尽快反馈,你有了多少想法就尽快告诉interviewer, 你有了部分代码,就给部分代码。 原因很简单,interviewer被长时间晾在电话那头是很难受的,而且你不断反馈其实就能获得更多interviewer的提示,对正确解答有帮助;
  • 如果你在interview的时候可以有internet, 在预约前就安装并给出你的IM,这样可以在IM帮助下让沟通更容易。

Onsite

看到一些海外求职的BBS上很多人都比较担心onsite interview, 不过我觉得onsite其实是最容易的,因为onsite interview您有机会得到更多的信息,从而获得更多提示,而且onsite interview过程互动性更好。

不过我们team的一些onsite interview是远程通过IM, Video conference来进行的,来自中国的candidate, 由于visa的原因很可能是video conference为主,这将是一个比较严峻的挑战。 一般情况下,onsite interview会有连续的多轮,一个接着一个进行,对candidate来说一般是一整天时间。

onsite interview基本上主要内容还是coding和design, 由于microsoft的interview一般都没有题库,因此每个人有自己的问题。靠在网络上搜索”Microsoft interview questions”的结果除了有练习作用外基本上没有任何帮助, 不过如果您在interview之后发布这些问题到网络上,除了可能让你失去可能的offer外,对自己和别人都没有太大帮助。

Onsite interview肯定会有一些紧张的,我有一些建议:

  • 同上,总是首先澄清问题和复述问题
  • 充分聆听interviewer给的提示,onsite interview往往是个互动过程,interviewer往往愿意参与和你讨论(如同一起工作一样),讨论而得出最终的结论是很好的interview表现,因此并不需要苛求自己在听完问题就直接搞定。
  • 遇到困难可以请求提示和帮助,不要愣在那里,或者自己乱写东西浪费时间;
  • 每行你写出来的代码都反映了你的编码水平、习惯、风格,因此不要在白板上写很糟糕的代码,即使是你的草稿;

Offer?

一般来说,Microsoft会比较快给出offer,不会让人等得花儿也谢了,但我们不会当场给offer, 每个interviewer都有自己对interview的独立评价,在结论出来之前,没有人知道结果。 

如果您进入了onsite这轮,那么您已经离offer很近了,毕竟大多数人都在coding test, phone screen中被淘汰了,所以一定要在onsite中尽量发挥好,完成漂亮的最后一击。一般情况下Microsoft并非采用传说中的一票否决(要所有人都给hire recommendation), 但毫无疑问,你要尽量让大多数人给你hire 的评价才可能最终获得offer.

Reference check

这个专门针对中国的朋友而写,因为reference check在中国从来不备重视,但我们的每个hire在interview通过后都必须有reference check。reference check 需要若干个您过去的直接经理对你给出评价(一般是电话),注意必须是你的直接经理,您的同事、朋友不能给你提供reference, 如果过去你是freelancer或者没有经理,那么你的直接客户、大学导师可能是reference check的对象。 

Reference check体系在西方公司是非常普遍采用的,这确保了每个人事业发展的连贯性,也让人对自己职业生涯中每个过程都变得有其历史意义,很可惜这套体系在中国一直没有能发展起来。

希望上面的介绍让您对如何应聘我们的职位有一个基本的了解,如果看完后觉得这不过是小菜一碟可以自信应付,那么赶紧来这里看看有没有适合您的职位吧:

http://joinmicrosofteurope.com

我相信本文对正在招聘的人也许也会有一些意义,然而由于目前中国的实际情况,我不知道对于startup而言采用类似的方法是否导致一个人也找不到,不过无数的血泪教训告诉我们,招不恰当的人带来的损失是巨大的,对一些追求质量、技术、创新软件团体而言,宁可招不到人也比招凑合着用的人要强N倍,中国传统的“人多力量大”的说法在软件工程中是个荒谬的神话。

* 本文版权没有,欢迎转载,请连同招聘广告一起转载。

GTD 1个月多小结:效果很明显,工具很缺乏

Tuesday, February 26th, 2008

据说30天可以养成一个好习惯,使用GTD来管理我的时间已经超过1个月的时间了,好的习惯是否就此养成了,我不知道,但这段时间使用GTD获得效率的提升的效果是很明显的:

- 这个sprint的工作比较繁琐,而且中途休假,一些自己其他项目(OPSN等)有deadline需要赶工,但总体上工作有条不紊

- OPSN的第一个prototype 单枪匹马开发完成(优化一些代码后发布,呵呵,现在有不少丑陋的地方还不好意思见人),虽然还很原始,但已经能说明一些问题也从中发现了一些问题;

- OPSN的presentation准备完了(开完会后公布),这个周末就去cork参加blog talk了,作为热身上周给同事们作了一个brown bag session, 虽然投影机不争气我自己也讲得有些节节巴巴但总体反映还不错。:)  本周还要再准备和演练一下,并且准备做个screen cast的demo. (目前幼稚的prototype对不是死硬派的sns fans还属于天书型不知所云的东西,因此screen case是必要的)

- 第一次在Toast master club当Word master角色,我介绍了”blogosphere” 这个单词,呵呵居然还被别人引用了2次。

- 每个周末都陪女儿去上了中文课,还和LP在女儿上课之余去喝咖啡、品正宗的Guinness, 来欧洲生活这么久,一起坐在街头悠闲地喝咖啡还是头次 … :)

- 晚上的Body pump基本没有缺席(呵呵,上周除外,当然多亏教练都是身材特好的PLMM, 才能让参加者这么投入),目前身体状态已经进入前所未有“健美”状态,呵呵。:) 

总之,采用GTD以来,work life balance 自我感觉做得不错,基本上在很忙的节奏中,工作、生活、爱好、家庭都兼顾了。 这在过去那么多年来,从来没有能做到。(当然这部完全是GTD功劳,欧洲生活的大环境也是一个重要因素)

另外一个感受就是GTD工具的缺乏,我一直用Google DOC来管理GTD items, 当item多了(我不喜欢删除完成的item, 希望留下纪录)就有些混乱。 看了其他一些GTD的工具,觉得没有满意的,要么是基于client软件的,要么就有些太死板,为GTD而GTD的感觉。 希望有经验的朋友能推荐一些真正好用的工具。

写有效简历的十条建议:五要五不要

Saturday, February 23rd, 2008

自从London归来忙得要命,正好国内是春节假期,因此也就偷懒没有怎么写blog。

最近这段时间仅写的一篇就是“跟我一起来加入微软欧洲开发中心 :) ”, 为我所在的team招兵买马. 发表这篇文章的时候有两个矛盾的担忧,一来担心没有什么人投简历 (没有足够符合要求的人, 身处机遇重重的有志之士对安逸且乏味的欧洲没有足够兴趣),二来又担心被太多简历淹没没有足够时间筛选。 现在看来,两个担忧都没有出现。

收到了不少来信,但有效的简历并不多,所谓有效的简历就是:1、它读起来的确是个简历;2、英文写的,因为我没有精力去帮忙翻译; 3、简历不是(至少一眼看上去不是)直接copy/paste来的模板什么都精通却看不出什么具体说明。 

统计了一下,所有有效简历都来自两类朋友:1. 在外企中国公司工作的;2. 现在或者曾经在国外读书的。最多信的来自国内的朋友,有希望约时间和我谈谈的,有询问具体工资待遇的,有对欧洲表示向往和询问的,有对M$表示鄙视的,… 可惜这些信里大多数都没有简历。回忆过去在国内招聘,很多年来遭遇的情况其实是类似的,求职简历五花八门,但有效的凤毛麟角,最头疼的是从51jobs等站点上自动生成的,当年我基本上直接过滤掉所有这些自动生成的简历。 其实总结下来,很多国内的朋友不擅长写自己的简历,不会写自己的简历是一件很吃亏的事情,因此我写些自己的建议,希望对谁有些帮助。 凑了10条,5条不要,5条要。

1. 不要抄袭别人的简历,不要使用简历生成器生成简历

不需要多说,如果一个人的简历都要抄,要靠程序来自动生成,那么基本上可以直接byebye了。 接受,review简历的同学们要看无数的简历,早对各种简历模板产生了强烈的厌倦情绪,因此千万不要自投罗网,让自己输在起点。

2. 不要罗列对自己价值没有实际提升的内容

一些简历喜欢罗列各种其实对自己价值没有实际提升的内容,比如各种语言,比如各种目前流行的框架、库、技术等等,刚刚毕业的同学还喜欢罗列自己的课程等。 往往这些罗列的内容对你的价值没有任何实际的提升,反而可能产生很多负面影响: (1) 你的真正优点被这些罗列内容冲淡了 (2) 让人怀疑你夸夸其谈、广而不精;(3) 很容易露出破绽,万一某个你罗列的东西让别人考倒了,基本就否定了你罗列的全部。

3. 不要用“精通”之类的言过其实的词汇

过去看建立最烦的就是“精通”这个词,我至今都不敢说自己精通这精通那,但过去常常看到写着这个也“精通”那个也“精通”的人被简单的问题放倒。 

当然由于精通被滥用了,真正精通什么的反而吃亏了,怎么办?我建议用X年经验来说明,例如“用C语言开发已经有15年经验了,用Ruby On Rail有2年经验了”。

不要言过其实的同时,要注意简历要最大化自己的优势,不言过其实的基础上对自己的经历和能力但绝对要足够“Aggressive”,参考第8条。

4. 不要写太长的简历,重点突出才是关键

Cover letter(求职信)要不要?我的观点是坚决不要。在IT行业,没有人因为你有没有写cover letter而对招聘决定产生任何影响。除了cover letter, 我建议去处掉简历中所有没有用的部分和描写。把任何简历缩短在3页以内,对于经验特别丰富的,建议只列举代表性的内容。

5. 不要写太抽象简短的简历

除非你是大牛或者业内名流,否则太简单太抽象的简历绝对是不利的。不幸的是我常常看到一些很“简练”的简历,除了能看出他读过哪些大学在哪些公司干过,对其本人的能耐一无所知。 

6. 要重点突出,对症下药

突出你最强的闪光点,针对你希望征求的职位。有效的简历应该能在第一页就能抓住review者的眼睛,让人对你的才能,经历有一个好的第一印象。

我强烈建议不要用通用的一个版本简历一网打尽,而针对你寻求的工作机会优化一个专门的版本

7. 要说明清楚自己的个人能力和经验而不是所在团队的

这是你的简历,不是你所在公司、项目、团队的简历。即使你是这些公司团队中举重轻重的成员,也要注重说清楚哪些是你自己的成就。 某些简历,常常可以看到对其项目、产品的重量级描写,但这个人是项目中的顶梁柱,还只是混混或者拉后腿的呢?

8. Be aggressive enough 但不要吹牛

Aggressive是个老外眼里非常动听的词汇,这些年来我觉得be aggressive的确是非常好的品质甚至是优势。 我们中国的传统教育往往是让人过于谦虚,这是非常不利的。 

Aggressive的基础是不要吹牛,你应该把你的芝麻大的优势用西瓜大的文笔和热情来表达,但说清楚你只是在热情地说芝麻而不是西瓜。 

我自己常说我已经有20多年编程经验,如何如何,其实我把高中玩Apple的时间也算进来了。:) 但我吹牛了吗?没有,这是事实,这就是一种aggressive。

9. 恰当地描写你过去的项目内容

某些简历中求职者把项目经历描写的过于详细,有泄漏公司商业机密的嫌疑,而有些则每个项目都写成buzz words似的不知所云,这些都是不利的。

我建议项目的描写要尽量简单,但采用让人能明白的通用词汇描述。例如 “我参与开发了结合了Voice Over IP和Instant message技术的新个人通讯软件项目”,而不要说“我参加研发了一个新一代的革命性个人通讯系统”。

项目本身简单,但如7所述,要更多说明“我”在项目里主要做了什么,而不完全是项目如何如何。

10. 采用常用的简历格式

在简历格式上,我建议采用常用的格式,而不要太创新。尤其英文的简历基本上有一个套路了。

要理解您的简历review者需要review很多简历,在格式上太创新,可能会把您的优势由于习惯原因而被忽视了,得不偿失。 

对英文简历格式不熟悉的自己去search一些学习吧。

最后,一个常见的问题是:我没有那么多骄人的经历怎么办?我认为答案唯有一个,就是花时间去创造出这些经历, 好好做好手头的工作,做出成绩来才去考虑下面的动作;不要好高骛远,要步步为营;在学校读书或者你所在的地方实在没有什么让你觉得能提神的项目?参加或者自己创建一些开源项目…

总之把写简历是对自己职业人生的一次review, 找到自己的不足取弥补和加强,终究有一天你会有令自己满意的简历。

最后继续做一下广告:并且希望能收到一些“好”的简历。

微软欧洲开发中心正在招聘!

我们的详细介绍和职位空缺请您移步到http://joinmicrosofteurope.com去进一步了解。

我们目前所有空缺的职位都是Senior position, 这意味着我们对您目前的技术水平和经验有着较高的期望值

关于工作和职位的申请,请您我们的网站上查看,您可以直接在那里提交简历,如果您有一些问题也可以把您的简历和疑问发送给我,我帮您转发(我的email: zhihong.mao@gmail.com)。

请您提交英文简历,您需要有熟练口头和文字的英文能力才能胜任这些职位。

本文欢迎转载,希望转载同时保留这个广告。 :)

Close
E-mail It