1. the most difficult bug u fixed and how u solved this problem..
解决过很多疑难bug。最困难的分为两类。一类是并发、多线程类的，因为bug的出现依赖于一定的时序，难以复现；看到的是被破坏的现场。线程安全类问题很多发。
另一类是对外部系统有依赖的，很多错误出在依赖的框架或者库里面，而这时候需要根据框架和库报出来的log来分析问题，很多时候报出来的不一定准确，搜索引擎也找不到解决方案。要去读一读源码。
还有一种是缓存类的bug。这个缓存可能是字符串中残余的内容，也可能是Redis中的数据没有刷新。
另有一些具体的，比如开始用稳定排序，工作正常；依赖库或者函数变成不稳定排序后，就会出现问题。
还有一类bug是字符编码问题，比如有的中文编码始终是有问题的。
很多bug，解决了之后，都发现，其实很简单。但是当时，却真的要查很久。
今天有一个实际的bug，就是关于指针指向的处理。有一个问题现象很诡异，查了一个晚上，原来在回收资源的时候，一定情况下有一个指针的指向没有置为NULL，而这个资源并没有完全废弃，下次会被重复利用，然后这个原始的错误的指向就可能带来问题。
还有一个bug，定时到12点就发生返回的结果有问题，开始以为某些跟时间相关的函数造成的，日志打的也不错，也不core，后来加了日志，看了发现原来是依赖的上游文件，12点推送过来，开始是空的，而处理这个文件的逻辑有问题，全空的时候，结果就会有问题，但是如果不是全空的话，就能够正常处理。所以还是依赖于外部的一个bug和fix。
补充问题：调试方法？
这篇文章有一些关于gdb, 多线程以及pstack, gcore, strace等命令的使用调试方法：
http://www.cnblogs.com/charlesblc/p/6256912.html
2. describe a group project u worked on and your contribution.
I lead a team. 广告、电商、百度购物、百度返利，夺宝。
1：虚函数原理？有何用？（辅助实现设计模式）
虚表，编译器绑定到虚表中的指定项。
同样虚函数也如此，编译器已经算好了虚函数在虚表中的位置。只是由于只是由于每个类的指向虚表的指针不一样，才产生了多态的行为。
2. 调试内存泄露的方法：
3. 为什么哈希桶一般是质数：
其实是为了避免不好的哈希算法导致的桶分配不均，变成质数，稍微好一些。比如按照最后取余来哈希的，如果是一个合数，桶的分配容易形成规律。
但是一般都用好的哈希算法。常见的哈希算法见这篇文章：http://www.cnblogs.com/charlesblc/p/6130141.html 其中加法哈希就需要桶数为质数。
质数并不是唯一的准则，具体可以参考以下网站。
good hash table primes
epoll与select/poll的区别：