baidu面经
发信人: ayhon (Dylan), 信区: ParttimeJob
标 题: ~发baidu intern面经,商务搜索部~攒RP
发信站: 北邮人论坛 (Mon Jun 15 19:24:52 2009), 站内
走到普天大厦楼下,听到旁边一个男的...一边开自行车一边打电话
和别人说面试自己的人有多么多么机械化...多么冷...
我一想,Y绝对是面baidu的...我师兄就和我说过,百度面试官和机器似的...
提前了大概二十五分钟,到前台拿了个通行证,上了百度所在的7楼
进去以后百度的前台又联系了我的面试官
就在百度有个接待的地方(不是一般面试的小黑屋似的会议室...)
挺多个小圆桌,已经有很多人在面试了
那个面试官拉了两把椅子我们就坐那了
他说我给你倒点水吧,我假意推辞了一下说不用不用,然后说了句谢谢
后来证明没有这杯酸梅汤,面试完我估计嗓子就爆炸了...
一上来,还是,挑简历上面的一个项目
按照原来面别的时候说的,又来了一遍
然后就大部分是算法题,系统设计题了
按照记忆和大家分享一下吧
第一个,一共有N个数,问怎么找到这N个数字中出现次数最多的数
我没想到太好的方法,就说了下我的思路:读入每个数的时候建立张表,记录这个数字对应的出现次数
追求时间效率就哈希,追求空间效率就顺序存,折半查找
后来一直研究哈希表的设计,我说典型的哈希算法就是取余数
他问我那具体取什么数字作为除数,这个数变大或者变小对时间空间复杂度的影响,还有具体查找过程
提到查找过程我又开始想怎么设计冲突处理,像什么二次哈希啊或者拿出块空间再做折半
反正是东拉西扯一大堆,最后甚至忘记了最初的问题
这题扯完,又问了一道题
一段代码
char * buffer = "1.19";
double b = atof(buffer);
int a = (int)(100*b);
问这段代码有什么问题
我就说了一下我的想法
在他的提示下涉及到了浮点数的存储问题
浮点数的小数部分是以 2的负多少次方来模拟的,因此不是保证精确的
如果人家存的数模拟出来应该是1.189999999999999999
那么乘了一百以后的浮点数就是118.9999999999999999
再转型可能就会丢数据
看我说的还算靠谱,他具体解释了一下很多转型时候的问题
第三题,说,每天有大概一亿条url的记录,url长度不超过1024,这些url也各不相同
每个url来的时候带着他们的64位数字签名作为标识
问你在系统中如何存储,如何以数字签名为key进行检索
这题我回答的就很不靠谱了
开始说用树,后来一想用树的话索引太庞大了
被拍死
后来又说了一大堆,包括用哈希的方法
他说可行,但是依赖于这个64位的签名生成的时候是不是够分散
如果有规律的话,哈希的时间效率就很难保证,而且最差情况会让人难以接受
我说恩恩恩恩恩恩恩恩恩恩...................................................
他说用这个数字签名建立二级索引
一级索引对应的是一个数字签名段里面内容的所形成的文件
每个段最多包括一定量的数字签名(比如1024个,实际肯定不止了)
二级索引是数字签名,里面对应了其保存的url内容
大概就这意思
后来的问题,技术性就弱了一些
首先,关于团队合作上,要注意什么问题
我一开始以为是关于teamwork的问题,后来他说了一下
才明白,还是在编程上,如何和队友合作的问题
我就说了两点,一是接口定义明确,二是注意代码可读性,帮助别人理解自己的实现机制
他接着问了,那你自己实现模块内部的时候
如何注意代码复用的问题
我就对着一些成熟的框架,向他说了一下我对于分层和接口的理解
主要是代码复用上,上层调用底层的接口,不需要理解实现机制
只需要定义好参数和返回值
另外就是程序改动的时候,只需要修改底层接口的实现,不需要整个程序去修改语句
然后到我提问题,就是纯聊天
说了一下百度的中文检索多么多么NB
问了一下这个部门做什么
问了一下百度是不是工作压力和传说中一样大...
还有,这轮的结果大概一周以后通知,据说技术大概有两面