相信大家在参加一些企业面试的时候应该发现了,有时候我们会遇到一些不容易回答的问题,下面我们就一起来了解一下在遇到这些情况之下我们应该怎么办。
1、坦诚相对,说明你的擅长点,让面试官给次机会
我遇到过个别候选人,他技术点知道一点,并非什么都不知道,属于可上可下的。比如项目是要SSM框架,但他在这方面只有学习经验,没商用项目经验,但他JDK,数据库可以,他就直说,SSM不行,但亮出他的长处,比如举例说明他学习能力很强,或者很能吃苦,沟通能力可以,然后表达出强烈想入职的愿望,我一般都会给出“技术可以(或技术勉强可以),能参加后继面试”的评语。
大家在面试的时候,回答问题好坏自己能估计出来,如果太差,属于一问三不知的,即使说这种话也没用,但如果你感觉回答的时候并非一无是处,就可以找机会说出这种话。
2、通过展示你以前的亮点,让面试官相信你的潜力和能力
如果你属于工作经验少于3年的,面试官其实对你不会要求太苛刻,其实更会关心你的学习能力,工作责任心,承受压力的情况,责任心,稳定性,刚才提到的补救措施你一定要有证据说明,你得用事实讲话,毕竟空口无凭。
下面java课程举出一些我面试过程中听到的别人说出的一些亮点,大家可以举一反三灵活掌握。
1我虽然对您刚才说到的SSM技术了解不深入(事实上他是还是会在项目经理搭建好框架的基础上开发,还能知道一点,如果一点也不知道,说了也没用),但我对MVC框架了解过,我以前做过的项目是用Jsp+Servlet30+JDBC实现的,也单独用过Spring的框架,所以我很快能上手。(我会适当问他JSP+servlet+JDBC里MVC的流程,如果他能说上来,我就会在评语上写“了解基本的SSM,了解MVC框架,知道MVC的开发方式”,但如果他不额外说明,或许我就会写,“只会在项目经理搭建好的基础上了解SSM,不了解框架细节”,这样即使他通过我的技术面试,后继的项目经理看到评语也不会对他有太多的好感)
面试的话就先介绍自己的具体情况,比如名字,有什么特长,学习和社会经历,取得过什么成就,对本工作有什么心得体会,对未来有什么计划,对本公司有什么看法等等。最重要的是自我介绍时要自信,说话清晰,有条理,别紧张。先写个草稿,自己多练习一下。工作主要还是看能力,介绍尽量精炼,不啰嗦。
很快,大概1-2天就能收到第一轮面试的安排。
微软的社会招聘面试总共是1轮电话面试+5轮线上面试(疫情原因)。候选人以内推为主,微软暂时未与猎头公司合作。简历筛选通过后,先约电话面试时间,电话面试和每轮线上面试时间都在1小时左右。电话面试通过后,大约一周以后会约线上面试时间,线上面试用的是MicrosoftTeams,5轮线上面试一天完成,效率杠杠滴~。线上面试大约一周后会告知结果,通过之后就是offer、背调等流程。
不同部门和不同面试官的面试风格、侧重点可能差别很大,但主要考察点应该没有太大出入。网上也有很多人写微软的面经,也可以多搜一些作为参考,但是他们列出的面试题在你面试的时候可能一个也不会遇到。
程序员面试一直是社区乐于讨论的热门话题。我自己从06年实习以来,先后经历了4家软件公司,全部是外企,其中有世界500强的通信企业,有从事期权期货交易的欧洲中等规模的金融公司,也有为大型汽车制造商开发Android智能汽车的新兴公司。跨入IT行业以来,我在求职过程中经历过多次面试,最近两年也有过多次面试别人的经验。我感觉现在到了对这个问题发表自己看法的时候,这篇文章是我站在面试官角度对于程序员面试问题的一个阶段性反思和经验总结。
目标
相信和不少朋友一样,有了几年工作经验成为Senior后就开始了面试别人的经历。我在最初这个阶段只是按照自己的想象把”找到基础好的程序员“,”找到算法能力优秀的程序员“,”找到有Android开发经验的程序员“等作为面试的目标。但是,实际的经历告诉我,尤其是按“基础好”,“算法好”这些目标招到的人最终效果并不好。比如,有的面试者基础知识和算法掌握情况不错,进程、线程、内存等概念清晰,基本的Hash,二叉树,快速排序等数据结构和算法也比较熟悉,但是进公司后在实际工作中表现得很糟糕。后来,我才发现原来是我的面试目标出了问题,我原先的面试方法更像是大学的算法或 *** 作系统期末考试,按照这种方法让许多并不合适的人通过了面试,同时也可能错过了许多合适的人。
后来,我的反思是,从公司的角度讲,面试的根本目的是找到“能够干好工作”的人,而“高学历”,“算法好”,“基础好”,“有经验”这些都是表象而不是根本,它们并不能直接和“工作好”划等号。
方法
目标明确了,但接下来的问题是假设面试者是一个黑盒系统,“工作好”不是直接可观测变量,你所能直接观测的变量是基础、算法、经验、学历、性格、谈吐、年龄等等。所以,实际上,你只能从“基础好”,“算法好”等可以直接观测的量去推测“工作好”的概率,这就是一个在“X好“条件下”工作好“的条件概率问题:P(工作好 | X好)。
根据这个模型,面试所应该考察哪些方面就很明显了,那就是选择那种最具有区分性的方面来考察。比如,考察面试者的体型特征没有太大意义,因为P(工作好|高),P(工作好|矮),P(工作好|胖),P(工作好|瘦)的概率都差不多;所以,体型特征不具有区分性,这不是面试所应该关注的内容。
面试官应当结合职位的要求明确哪些因素具有比较好的区分性。比如,如果要招一名技术门槛比较高的3D游戏引擎开发工程师,面试者A具有3D游戏引擎开发的经验,但是在基础知识和算法面试方面表现一般;面试者B相反,基础知识和算法面试表现很好,但没有游戏开发经验,而你只能选择其一。你选谁呢?其实,这就是两个条件概率问题P(工作好|经验好,基础一般,算法一般)和P(工作好|没经验,基础好,算法好)。这个问题就留给面试官来判断了,就我个人而言,对于技术门槛较高需要技术积累的职位,经验更加说明问题,因此,我更倾向于面试者A。
下面,我再结合自己的经验谈谈对面试中常见方面的看法。
算法
算法是Google和MS等大公司面试所重点考察的内容。我个人很喜欢算法,曾经参加ACM/ICPC拿过北京赛区的13名。但是,就个人经验来看,我所接触过的绝大多数开发职位而言,算法都不适合作为考察面试者优劣的主要因素。对于普通的非算法性开发职位,考察面试者的算法就相当于考察他打乒乓球好不好一样,与目标“工作好”的相关性太低。就我个人的经验来看,差不多P(工作好|算法好)=50%,也就是算法面试没有太大的区分性。
甚至,还有一种很不好的情况特别多地出现在算法好的面试者身上,我称之为“只磨刀,不砍柴”。什么意思呢?有类人只对什么A算法,异步编程,JVM类加载机制这种纯技术问题感兴趣,对实现用户需求毫无兴趣。这类人看起来有一定的技术能力,但是对公司来讲贡献十分有限,甚至不如技术一般但认真负责的人。所以,一旦遇到面试者算法好,我就特别留意考察会不会是这种“只磨刀,不砍柴”的人。
另外,虽然我个人不了解Google和MS,但我对于其特别重视考察算法能力的面试策略是持怀疑态度的。即使在这样的世界级大公司,算法虽然重要,但可以想象在项目实施过程所遇到的各种各样问题中,算法问题绝大多数时候不会是主要瓶颈,没有到那种需要每个人都是算法高手的情况。实际上,绝大多数项目真正难点并不是一两个算法瓶颈,甚至也不是单点的技术瓶颈,而是系统性的组织、协调、设计、开发问题,有大量的看起来不是那么有技术含量的脏活累活,也有许多问题是由于信息不足,并不是技术能力强就能克服这些困难。一个团队最好优势互补,有人算法强,有人业务分析能力强,有人擅长后端服务,有人擅长前端界面,有人聪明,有人踏实,这是最好的。如果按照“算法好”的单一标准选材,必定会把许多优秀的人才拒之门外。
基础
基础面试是指考察诸如指针使用、进程线程概念等基础知识的面试,十分类似于大学期末考试题。我曾经以为基础面试十分重要,但是现在不这么看了。在工作中基础的确是重要的,但是在面试过程中,它必须具有区分性才有意义,也就是说P(工作好|基础好)的概率要高,那么考察指针使用,进程线程区别这样的基础题目才有它的意义。我的实际经验是,基础面试并不具有很好的区分性,和算法一样, 差不多P(工作好|基础好) = 50%。同时,基础面试是最容易准备的,中国人有长期的应试教育经验,要准备几个把玩指针题目太容易了。
我曾经遇到过这样的面试者,他的C语言基础和编译、链接等原理掌握得非常好,给我留下了深刻的印象,我给的面试结论是:知识面不宽,只会C语言,但基础很扎实,建议录用。后来的事情证明了那个结论的前半部分是对的,但是”建议录用“错了。他在实际工作中表现得一塌糊涂,不理解需求,不理解整体架构;同时,上班时间不是花在项目上,而是花在阅读诸如《程序员的自我修养》之类的书籍上。最后,这位同事由于长期“不出活”离开了公司。
基础不是不重要,而是“基础好”不足以说明面试者能干好工作,因为基础是属于局部性知识,而实际工作需要综合性能力,二者有天壤之别。C语言、 *** 作系统能考高分,但是不会写程序的人在大学我们还见得少吗? 软件开发就像盖房子,综合能力是设计和搭骨架,基础知识是码砖。张小龙原先Foxmail是Delphi开发的,他它不懂C#,你如果要招聘一个开发NET Email客户端的人,你考察他对CLR掌握得好不好有意义吗? 让张小龙来开发一个C#版的Foxmail真的会有困难吗? 你招一个精通C#但没有Email客户端开发经验的人来真的比张小龙靠谱吗?
我说基础知识不重要,和古人说的“不积洼步无以至千里”是不是矛盾呢?不矛盾!“洼步”与“千里”是一种可累加关系,但再多的“基础知识”都累加不成“综合能力”。学习软件开发要像持续集成一样,一开始就是一个完整的系统,虽然规模不大,问题很多,但它麻雀虽小五脏俱全,从小系统到大系统,从简单系统到复杂系统逐步演化。
所以,基础好本身不足以说明太多的问题,必须进一步考察综合能力。对于基础面试表现不好的面试者,如果时间允许也要进一步考察,有的面试者其实是有能力的,只是没有进行充分的准备。最理想的状态当然是基础和综合能力俱佳,若不能兼顾,应当综合能力优先。
经验
这里所说的经验不是通过工作了多少年来衡量的,而主要是指面试者的经历,比如,是否完整地实现过一个软件,或作为主要开发者完成过一个项目。经验的重要性在于它能说明一个人的综合能力。从项目的性质、规模和难度,面试官就可以大致判断出面试者的综合能力。如果一个面试者一直在大公司负责一个小模块的开发维护,那么基本可以判断他不具备独立或作为主要开发者承担一个项目的能力,只适合在另一家大公司做类似的事情。对于门槛较高需要长期技术积累的职位,相关经验更显得尤为重要,比如,Linux内核开发,JVM开发,游戏引擎开发,数据库实现,高级UX等。对于这类职位,没有经验的面试者即使综合素质不错也是需要长时间的学习和积累才能胜任。所以,基本上如果确定了你的职位属于此类,那么相关经验毫无疑问应该成为首选因素,换句话说,P(工作好 | 相关经验好)的概率是非常高的。
通过项目经验判断面试者的优劣比通过基础和算法测试更加靠谱,所以,面试过程中面试官应该花比较多的时间听面试者介绍项目经验,并进行深入地探讨交流,了解面试者的知识面、思维能力、表达能力等。同时,可以结合项目提一些基础知识和算法的问题,比如,如果面试者做过C++相关的项目,那就可以问他如何进行内存管理?是否熟悉智能指针?如果面试者的回答不能令人满意,那么就基本上可以判断他的项目做得不是很好。
要注意的是,经验也是一个多维度的事物。比如,C++股票交易中间件系统,这就涉及(C++,中间件,股票) 3个维度。假如面试者A做过C++股票交易客户端,面试者B做过C的股票交易中间件。从语言角度看,A最匹配,从项目性质看,B最匹配,你如何选择?这就是在多个维度中,哪个维度更重要的问题,就这个例子而言,我个人更倾向于B,因为我认为中间件开发经验是主要矛盾,而从C切换到C++并不是问题。所以,面试官需要判断哪一种经验是主要的,而哪一种经验是次要的。比如,我们招聘Android应用开发,这个职位的Android技术门槛并不高,它的真正难点在于做出好的用户体验(UX)。所以,如果一个面试者没有Android的经验我们是可以接受的,但是我希望他在UX方面有经验,至少做过其他平台的移动应用开发。
性格
现在,我来谈我认为最重要的因素:性格。这可能是许多初为面试官的朋友所难以想象的,怎么会是性格最重要呢?说实话,当我意识到这一点时,我自己也很惊讶!说白了,还是 P(工作好|性格好)的概率最高啊。我的实际经验是,如果一个人的性格好,他能把工作做好的可能性是最高的,性格好远比基础好、算法好要靠谱。
一个人如果技术上有缺陷,经验上有不足,但性格好,在团队中是很容易由其他人来补位的,他自己也很容易逐渐补起来;相反,如果一个人的性格不好,所有的技术优势经验优势都发挥不出来,甚至还会起到负作用,而且性格缺点很难改变。我一直谈到实际工作所需要的是综合性的能力,这种综合能力的发挥中性格是至关重要的。项目中不止会遇到技术问题,要涉及沟通、协调,不同的人不同的部门既有合作又有磨擦,如何处理这些事情都需要一个良好的性格。可以说,在开发团队里让你与众不同的不是你从哪个学校毕业,也不是你过去的经验,而是你的性格。
当然,性格是一个复杂的东西,它包含了很多的方面,并非所有方面都是程序员面试所需要关注的。我的经验是可以重点考察这些方面:
1) 态度积极还是消极。有的面试者在谈吐中就会自然给你一种积极上进的感觉,或者你可以在他的经历中发现他积极的因素,这些都不是太难看出来的。相反,有的面试者你能明显感觉到他的消极情绪。积极性在工作中是十分重要的,积极的人能给团队带来朝气,也更易于合作。基本上,如果确定面试者属于态度积极的,他通过我这一关的可能性就会大大增加;相反,如果确定属于态度消极的,即使技术能力不错我也会十分谨慎。
2) IQ。我的经验是,总体来看,聪明的人在工作中的表现更为优秀。在面试中要考察一个人是否聪明并不一定要像Google和MS那样找些专门测试IQ的智力题,其实,你只需要看他讨论问题是不是很有逻辑性,思考和说话是不是反应敏捷就可以做出大致的判断。另外,眼睛是人心灵的窗户,一个人聪明与否,眼睛是会说话的。不过,聪明也不完全是优点,比如,当公司或项目遇到困难时,往往是聪明人先跑掉了,坚守的往往是IQ一般的人。
3) 语言表达能力。语言表达能力也是程序员十分重要的一项素质,它关系到项目中的沟通是否顺畅。面试官可以看看面试者能否用简明的语言介绍清楚曾经做过的项目,能否抓住要点,能否考虑到听者的相关背景。一般来讲,语言表达能力强的人综合能力都不会太差。
4) 是否具有用户意识。有人说程序员是做研发的,哪来什么用户?只有销售、市场人员才会和用户打交道。其实,这是完完全全的错误认识。你写一个模块,甚至一个API,只要有别人用,他就是你的用户。有的程序员设计一个模块或是一个软件总是习惯于从使用者的角度来考虑,尽量地方便使用者,这就是一种良好的用户意识。具有良好的用户意识的人更能考虑别人的感受和整体的需要,而不是单纯地从自己和局部来思考问题。当面试者谈及过去的项目经验时,面试官可以常常站在用户的角度对其进行提问,从这个过程中观察其是否具有良好的用户意识。
5) 如何应对质疑和压力。面试官应该对面试者的回答以及以往项目进行合理的质疑,看看他如何应对。曾经有一位面试者谈到做游戏登录服务器的经历,我就问:“如果登录服务器挂了,怎么办呢”?他说原先虽然没有考虑这个问题,但是可以怎么怎么改进。其实,大家都理解项目中有各种不完美,这里面原因很多,只要面对质疑和压力能从容应对努力往好的方向思考解决就可以了,不需要掩饰缺陷,更不应该有情绪。我遇到过有的面试者,一旦你对其项目提出质疑,他马上产生反抗情绪,或不高兴,或不承认有问题,这很容易一下子看出来他在工作中容不得质疑和批评,这种人要想合作就很困难。
6) 个性特点。许多面试者喜欢在简历上写“精通C++/Linux“,这些字眼看得人麻木,如果有人写”喜欢C++/Linux“,我就会有一种眼前一亮的感觉。“精通”是没有感情色彩的叙述,而“喜欢”包含了面试者的个性,我更愿意看到面试者的个性。我相信对某样东西真正的热情远比你当前对它的掌握程度更为重要。其实,N年的经历告诉我们,同一个班的同学,同一个项目组的同事,虽然每天所学的知识,所接触的工作都是相同的,但其实每个人的成绩和表现差异是十分明显的。那么,到底本质的差异是什么呢?其实,就是每个人的个性。是个性使得有的人业余时间去打球,有的人业余时间去看书,有的人喜欢Linux,有的人喜欢Mac。一个人在团队中扮演的角色也和他的个性有很大的关系。面试官应该引导面试者展现自己的个性,并判断其是否有益于团队。
总结
最后总结起来,我的经验是: 1) 面试官的目标是找到”工作好“的人,一定要围绕这个目标来进行面试,如果把面试当成了算法或 *** 作系统期末考试这就走入了误区;2) 面试过程是通过学历、性格、基础、经验、算法等可以测试的因素去综合判断面试者“工作好”的概率;3) 在各种因素中,性格 > 经验 > 基础 > 算法。性格是最重要的,如果性格不好,所有技术能力都会大打折扣,而且技术缺陷容易弥补,性格缺陷很难改变;经验体现了一个人的综合能力,你可以从面试者过去的经历中判断他能从事哪种工作,不能从事哪种工作;基础和算法则主要起到辅助参考的作用,基础好的程序员一般适应性比较强,学新技术更快,但是切忌单纯从基础来判断一个人的能力。
随着互联网的不断发展,java开发成为了众多开发工程师使用的主流编程开发语言。今天,java课程培训机构就一起来了解一下,在java程序员面试过程中,有哪些比较常见的技术面试问题需要我们了解。
1、什么是线程
线程是 *** 作系统能够进行运算调度的小单位,它被包含在进程之中,是进程中的实际运作单位。程序员可以通过它进行多处理器编程,你可以使用多线程对运算密集型任务提速。比如,如果一个线程完成一个任务要100毫秒,那么用十个线程完成改任务只需10毫秒。
2、线程和进程有什么区别
线程是进程的子集,一个进程可以有很多线程,每条线程并行执行不同的任务。不同的进程使用不同的内存空间,而所有的线程共享一片相同的内存空间。每个线程都拥有单独的栈内存用来存储本地数据。
3、如何在Java中实现线程
两种方式:javalangThread类的实例就是一个线程但是它需要调用javalangRunnable接口来执行,由于线程类本身就是调用的Runnable接口所以你可以继承javalangThread类或者直接调用Runnable接口来重写run()方法实现线程。
4、有哪些不同的线程生命周期
当我们在Java程序中新建一个线程时,它的状态是New。当我们调用线程的start()方法时,状态被改变为Runnable。线程调度器会为Runnable线程池中的线程分配CPU时间并且讲它们的状态改变为Running。其他的线程状态还有Waiting,Blocked和Dead。
5、你对线程优先级的理解是什么
每一个线程都是有优先级的,一般来说,高优先级的线程在运行时会具有优先权,但这依赖于线程调度的实现,这个实现是和 *** 作系统相关的(OSdependent)。我们可以定义线程的优先级,但是这并不能保证高优先级的线程会在低优先级的线程前执行。线程优先级是一个int变量(从1-10),1代表低优先级,10代表高优先级。
6、什么是死锁(Deadlock)如何分析和避免死锁
死锁是指两个以上的线程永远阻塞的情况,这种情况产生至少需要两个以上的线程和两个以上的资源。
分析死锁,我们需要查看Java应用程序的线程转储。我们需要找出那些状态为BLOCKED的线程和他们等待的资源。每个资源都有一个唯一的id,用这个id我们可以找出哪些线程已经拥有了它的对象锁。
1 说得太少
尤其是那些开放式的问题,如“请介绍下你自己”或“请讲一下你曾经解决过的复杂问题”。面试官会通过你对这些技术和非技术问题的回答来评估你的经验和能力。
所以,仅仅只用两三句话来回答不但不能显示出你对这个专业的兴趣,还会让整个面试过程显得非常无聊。如果你不能很好地说明你的经验、成就和技能给企业带来的价值,那么你的竞争力毫无疑问就高不起来。所以,你需要对一些最常见的开放式问答作充分的准备,学会推销自己。
2 说得太多
不断地说,不断地说,却并没有什么实质性的内容。换句话说,就是废话连篇,言之无物。如果你不能简洁的解释问题,那么面试官就会怀疑你在工作时的表现是不是也会像你的谈话一样拖泥带水?可以先问问面试官,确定是否真的需要详细解释。
解释也是一门艺术,关键是确定重点,如果需要的话再深入到细节。当聊到业务的时候,就应该从业务的角度看问题,不要涉及任何技术术语。学会用简洁明了的方式解释问题。如果你能时刻把握主旨,那么这一点也不是问题。
3 回答不出一些必知的基本技术问题
面试不是技术竞赛,不是看谁答对的问题多,但是有一些“必须知道”的核心Java和Web基础知识,你不能不知。例如,对于Java开发人员
1)不知道“==”和equals之间的区别。
2)不知道equals和hashCode方法被隐式调用时的约定。
3)不能解释曾投入精力过的应用程序的高层体系结构。
4)不知道OO的概念和设计原则。
5)不能很好地处理多线程。
6)不知道如何在>
从事软件开发多年,上机写代码这种考查模式在国外用的比较多,很多国内的公司也在学习这种方式,这种方式能直接看出写代码的能力,但对上机做编程题目这种事情很多成熟的程序员觉得是一种侮辱,有一些程序员看到有笔试直接就选择走人了,这些东西在面试之前应该有沟通,事情不会变得这么被动,因为对于很多有能力的程序员,能够请到面试已经非常不容易了,能力越强脾气越大。
直接上机做编程测试能力的公司不是很多,从事软件开发十几年主要经历了四家公司,面试的时候主要靠面谈为主,因为编程行业能力的高低通过交谈就能了解差不多,只需要根据简历上写的项目进行细节沟通,如果真的做过几句话就能看出大概的水平,所以很多公司压根不搞什么笔试或者上机写代码的事情,编程这个职业主要靠时间的积累,并且在积累中不断完善自己的知识体系,慢慢提高自己的认知。
一个程序员如何提升自己的能力水平,对于初学者来讲首先是学习好一门编程语言,开始学习阶段觉得编程语言就是天了,好像是学会了编程语言就能做任何的东西了,随着编程语法的学习完毕就开始尝试做一些题目,结果发现距离语法真的非常遥远,所以有很多的初学者有一种感概明明在课堂什么都明白了,结果到真正自己实践的时候什么都想不起来,这是初学者必然的经历,编程本身就是一种不断磨练编程思想的过程,编程语言属于在辅助类基础技能,没有辅助就不会写代码,编程设计思想再牛也不可能实现,两者是相辅相成的作用,编程思想里面包含着仙姑经验的积累。
很多人觉得很奇怪有些公司也不进行面试也不让上机写代码,就是通过不到一个小时的闲聊就能把一个人的水平能力和工资水平给定位下来,通过面试就能检测出编程思想以及编程基础,编程基础类的考察只需要问几个简单的语法问题就能做个大概的检测,编程思想就是完全的编程意识以及编程经验的积累,所以一些企业在招聘的时候明确写着就相关开发经验的人优先,企业招聘的目的就是希望要的人在短时间内能够上岗直接切入到项目开发中去,整体来看是不是需要上机写代码测试完全看每个公司的技术文化了。
有些技术类的公司对于程序员的基本功要求特别严格,有个同事在第一家技术公司的时候,部门技术经理特别关注程序员的基本语法,只要是简单的代码语法错误,就能到部门的黑板通报,开始实施阶段很多人上了黑板,后来随着时间的推移上去的人越来越少了,同事说到自己上了两次黑板都是因为在使用指针的时候没有初始化导致,到今天还是记忆尤新,如果在技术生涯的初期能够经历过这种企业是一个技术人的幸运了,越是严格要求的领导或者公司越是有利于技术人员 的成长,至于在面试的时候要不要上机这个就看每个公司的技术文化了,一般注重代码基础的领导会引领这个事情,希望能帮到你。
笔试的我见过,但是上机的没有过。
1笔试可以有
这么说嘛,其实简单的笔试的话肯定是可以的。因为笔试的话可以让招聘者知道你大概的能力定位在什么位置?一些逻辑编程可以测试你的逻辑能力。尤其是在it这个行业,逻辑能力是非常重要的。
如果说你是一个已经有工作经验的人。其实笔试就没有那么重要了。这时候看中的一般差不多就是你曾经的项目经历。
如果说让你做一些项目上的,比如说项目架构了这种的,你可以拒绝回答。因为我之前就有听到过说招聘产品经理,让他去设计一个产品的。结果这个公司就是通过一直招聘产品经理。然后让产品经理去设计产品相关的功能,最后再把这些所有求职者的产品相关的思维组合到一起。
虽然说这总公司是很少的,但是也不排除是有只通过这种方式来满足产品需要的。
所以解释的时候可以大概的写一个思路代码的流程,但是可以不用全部都写。
2上机测试
我觉得这个确切的来说是有一点过分的。像这种上机考试的话,肯定他是需要一个比较完整的项目。但是这种项目谁都不知道是他们公司需要,还是让他仅仅是为了做测试。所以像这种事情完全可以直接拒绝。
在这里大概说明一下。 找工作是一个双向的过程 ,如果说是你无法接受这个公司相关的制度,或者说是相关的流程。其实你可以趁早放弃这种公司的,不然的话即使是你笔试面试都过啦,你到公司之后也会因为你自己的价值观跟企业的文化匹配不到一起。迟早还是要辞职的,所以你要慎重考虑。
其实面试的时候笔试和机试都是it的正常流程,但是在国内被玩烂了,面试和机试过程中,会有公司内遇到的问题做为面试内容的,也许是个人也许是公司,让你解决这样那样的问题,这样子的都是垃圾
作为一个老程序员,关于程序员面试的话题,非常有意思,特别有的聊。其实在 IT 界面,有两个不算公开的秘密,也就是两个不成文的习惯或者规定吧,关于面试的。
让老程序员做笔试题是一种侮辱
很多程序员,尤其是有经验的程序员,去面试的时候,尤其是去小公司面试的时候,如果对方给你出了一套笔试题,很多程序员会说: 我转头就走,这是对我经验水平的侮辱 。
你们是不是感觉很吃惊,还有这种道理?确实是,我有一次去一个创业公司面试,对方给我出了一套笔试题,我做完了,面试完回去跟一些同事聊笔试题的事,他们会惊讶的说:你竟然把笔试题做了?你是有经验的程序员,不应该经过笔试的,直接面试就行,笔试是一种侮辱。那是我才发现,好多程序员都这么认为的。
但是,我感觉这是一种病态思维,你既然去面试,其实笔试也是面试的一种,你去大公司比如 BAT 这样的公司的时候,也会有笔试,而且层层面试好几轮,你都能忍,一些小公司给你出笔试题,你竟然受不了?公司用什么方式来面试你,是公司的选择和考量,当然了,面试是一种双向选择,如果你感觉是侮辱,当然可以选择不面了,这是双方面试的权利。
但是,我感觉笔试是一种正常的流程,跟有没有经验没有关系。有经验了,你笔试你确定能过么?
很多程序员都不会选择上机测试
还有一种就是面对上机做题的面试,很多程序员都不喜欢,其实我也不喜欢的,大部分程序员好像遇到上机面试的情况,也是选择扭头就走。
其实,我感觉上机测试是可以接受的,但是是有条件的,那就是上机做题,可以做算法题,这种方式我能接受。
有一次我去面试,他让我上机做题,竟然跟我说用 Android 写个什么功能,什么模块,简直了,这种题怎么做?直接去实现功能模块,写其中的一个点,我都不熟悉需求,也不熟悉功能模块,上来就写,怎么做?没法弄。我直接就走了。
算法题属于比较明确的东西,上机做两道应该是可以接受的。
你问上机做题的这样面试的公司多吗?可以明确地告诉你,不多,我工作这么多年,面试了很多公司,只遇到过两家。
我是负责我们公司技术面试的,机试环节必不可少。题目不会很难主要是考核程序员的感觉,只有有感觉的程序员才能写好大程序,这很关键。
很正常,程序员都会有面试和笔试。如果只出一些纸上的笔试题,还不如看你直接动手 *** 作能力来的快
这主要看做什么了,我最头疼的是拿一个构架来靠你函数命令。我都是自己写数学模型和函数。我哪知道这个构架的函数名?
务实啊,说明人要的是能实干的程序猿,没什么奇怪。面试需求很明确,要会干的。找领导才找会说的。刚毕业面试的时候遇见过这种机试,程序猿这行算是工科,靠技术吃饭,面试动手实战是正常的。
这样的公司会存在
基于以下4个原因:
1 面试的人很多,不想花过多的时间去筛选。这样做题,可以快速过滤一些滥竽充数的人
2 通过合理的上机 *** 作,有针对性地找合适的人,匹配的人也能快速完成上机 *** 作
3 标准,对面试者统一对待,以免主观原因造成误判
4 面试者的配合度,一般看到机试,有人就会直接退出。(我遇到这种情况,就会直接走)
以上4个原因,都是较为正式的原因,还有一个主要原因就是能力不行,面试官无法正确筛选简历,面试官无法从面试中获取想要的信息并加以判断。
基于最后一个原因就是我会选择直接走的原因,面试官能力不行,表示公司对此招聘的用功不足,该公司没有能力或没有意愿重视此次招聘。即使入职,收到的待遇不会重视,没有必要把自己的前景压在一个不会重视你成果的公司上。
支持,不然很多水逼,划水货太多了
以上就是关于程序员面试应该如何发挥自己的优势全部的内容,包括:程序员面试应该如何发挥自己的优势、程序员面试的时候自我介绍怎么说、微软程序员面试时间等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)