1、计算北京到天津一年的铁路客流量。使用两种方法。
方法1：通过车次数量估算
根据12306数据，北京到天津每天的车次在150-160之间，取中位数即155。
其中高铁+城际数量在120-130之间，取中位数125。
根据铁路列车运载数量，高铁+城际座位数约为500，常规列车运载数为1200。
由于高铁列车+城际闲置率较高，因此假设为50%。由于天津距离北京较近，普通列车上座率不高，并且卧铺一般闲置，因此按照闲置率30%计算。
高铁+城际日运载量计：125*500*0.5=31250
常规列车运载量：30*1200*0.7=25200
两者相加：31250+25200=56450
尽管存在春运等高峰时期，但这些时期都是小概率事件，并且高峰期也仅仅是增大满载率而不是加设列车，因此不计。
得出一年运输人数：56450*365=20604250
方法2：通过车站客流量计算
北京有三个车站：北京站、北京西站、北京南站
其中，北京站和北京西站主要是常规列车站。他们的日均客流量分别是76000个120000。尽管北京天津距离较近，车次较多，但作为常规列车站外地列车也很多，因此按照10%计算。即归属于北京-天津的日均客流量为（760000+120000）*10%=19600
北京南站是高铁+城际列车站，主要有京津城际快车和其他高铁列车，其日均客流量为70000。
其中城际铁路约占50%。因此北京-天津的城际客流量计35000。
因此，北京-天津的日均总旅客数：35000+19600=54600
一年的铁路运输人数为：54600*365=19929000
2、如果微信当中让你砍掉一个功能，你砍掉哪一个，为什么？
如果需要考虑砍掉功能，那么首先应该考虑的是砍掉它会影响到什么。
因此，首先筛选掉使用频率高的功能，砍掉他们影响巨大，造成用户各种问题。然而由于用户针对于某项功能的使用频率统计不足，因此只能换一种方式进行甄别。
1. 小功能。不能是大的功能模块，例如朋友圈、群，这个涉及到众多的协同模块，朋友圈涉及社交、流量、广告等，群涉及到红包等核心功能。
2. 使用频率低。考虑范围为低频操作，例如添加、删除好友，群等。
3. 功能重复。
综上考虑，可以筛选出一个功能范围。
添加好友->好友分类添加->搜索、雷达、扫一扫、QQ/手机、公众号
结果显然，公众号！
为什么？
l 搜索是所有的入口，不能砍。
l 雷达、扫一扫、QQ/手机 面向的是多个入口方式，例如扫一扫是通过二维码，QQ/手机是通过遍历。
l 重复的只有——公众号。
因为它的使用入口是搜索。
我们知道，搜索栏能够搜索包括公众号所有的账号，而搜索一般采用的方式：
微信号、二维码、名字
三种频率依次下降，名字搜索是最低频的，前两者没有任何重复的可能，而公众号重名的多，使用公众号搜索名字和使用大搜索栏搜索结果相差不大，并且由于使用大搜索栏更为方便，因此无论是使用频率还是使用结果上，公众号搜索都没有任何优势可言。
因此，它是多余的！
