- 论坛徽章:
- 0
|
谈点个人的看法
"最基本的是基本功扎实，编程能力强，解决问题的能力强"。有感于楼主这句话，写点自己的看法，还请牛人指教
在上海呆了段时间，感觉很多公司(包括很多大公司)并不懂的如何招人。
孔老夫子有这么句话“应才施教”，我的看法则是“应人而用”。
一个睿智的leader应该是能发现队员的不足与长处，扬长避短，优势互补，好钢用在刀刃上，而不是按统一的标准一刀切。
1.现在很多公司都喜欢考些奇怪的问题，比如int多少位，我们平时做项目基本上都习惯用linux/type.h,即使没有也喜欢自己写个include一下
typedef unsigned short int u16
.................................. s16
..........................
这样的好处，一是方便，而且程序的可读性也高，二是为今后的跨平台留有铺垫。真正做项目的人谁还在扣大学课本呢？
"有一百种方法可以杀死一个人，我只需要知道最有效的一种"
还有很多公司都喜欢考ARM有几级流水线，说实在的几级流水线跟上面写程序到底有啥关系阿？(这种面试官连专科生的水准都达不到，流水线的概念都搞不清楚)
还有ARM几种工作模式，除了你是在arm上纯写汇编的，不然常见的也就两种情况能用到汇编，一是loader,二是c与汇编混合编程，通过汇编优化效率，真正做过这些的人应该知道所谓几种工作模式到底有多大意义。
类似的列子太多了。。。。
倒是有些题目很好是该考考，比如如何用C编程判断机器的大小端，直接指针操作内存是char *还是unsigned char * 等等
2.数据结构与算法
相信很多编程高手喜欢这句话“编程才是硬道理，算法才是编程的灵魂”，同样也有很多人无所谓算法。
其实这是要看情况的，要根据公司相应职位决定应聘者的算法素养。比如做driver，能有多少跟算法（指的是书本上狭义的算法）扯的上边？至于数据结构，一般也就多数用用链表而已。倒是对硬件的知识要求颇高，对系统的相应接口有要求。
曾在某视频类公司做过项目，当时进了个新人（富士通前雇员），算法是挺溜的，可实际操作中寸步难行，为什么？1个多G的SDK包，涉及的都是课本找不到的东西，代码根本连看都看不懂，你让他怎么做事呢？路都走不好，就想飞了，不切实际。再说了，整个产品做下来，最多也就用到冒泡，二份法之类低级算法。
还比如曾有某公司想招个嵌入式人员做公司旧有产品的ARM平台移植，笔试题满幅的算法，这种公司根本就没做过平台移植，连移植需要怎样的技能都不知道。
一句话，算法很重要，但要看场合。
3.代码阅读能力
极为重要
4.编程能力
极为重要，但现在很多公司走入误区，多数都以为考些AI类的算法能说明问题，其实怎么样的代码才是可重入的，怎样的代码才是将来易于移植的，怎样的模块才是高内聚低耦合的，一个任务如何合理分解成若干模块这些才是最重要的。真正用到算法的是很少的
5.解决问题的能力
极为重要，但其实与基本功并无决定性关系，曾有某公司一项目遇到问题，名牌硕士外加一帮工程师前后拖了半年没搞定，我过去几分钟解决问题，用的是高中物理选修本的知识。
同样这家公司遇到另一个技术问题，工程师全部阵亡，最终搞定问题的是老总，一个做工程出身完全不懂技术的人。你说这算什么事？
发散性思维与知识面的开阔才是关键。
6.很多公司喜欢考某些命令的熟练度
例如gdb,其实真正做下来，你就会发现printf,printk,led灯之类的才是最好用的，实在要用gdb了，也是找些类似insight这样的图形化前端来应付，gdb在易用性上实在该跟softice学学(不过也不能怪gdb,毕竟功能太强大了)。真正的功力不是靠死记硬背些书本的知识。
最后重申一点，并不是基本功不重要，而是要本着做项目的精神（给定的时间，给定的资源，作出预定的产品，而不是搞科学研究），从实际出发，应人而用。
毕竟不是是每家公司都在搞编译器开发，不是每家公司都在写操作系统。试问一句，一个科学家做的菜好吃，还是厨师做的菜好吃？作出好的产品，赚钱才是硬道理！
认识有限，各位牛人见笑了，欢迎拍砖
[ 本帖最后由 owen000 于 2009-4-9 13:13 编辑 ] |
|
免费注册
楼主: huanggao
发表于 2009-03-25 15:24
