写在前面

其实关于面试一直是一个老生常谈的话题，尤其是前端岗位的面试。个人自己的面试和被面试经验来说，大部分情况下的面试者都喜欢问一些知识收集型的问题，比如：

• 浏览器差异与检测
• CSS hack
• 如何解决跨域

当然不是说这类问题不应该问，如果候选人的项目背景有写解决过类似的问题时；

适当追问有多少种不同的解决方案，为什么选择其中某种——能很好的考察候选人在积累知识过程中的深度、广度还有思维模式~

但是对于一些初级岗位的候选人或者毕业不久的校招生，问这类问题无非是增加尴尬。

那么要怎么做

如果非要问初级职位候选人一些知识收集型的题目，推荐问一些比较基础的，比如：

• HTML5新增了哪些tag，和input类型
• CSS选择器有多少种，优先级排序
• JS闭包，浏览器的事件模型

这些问题的最大价值在于考察候选人对这个职位的重视程度。

更好的方式

比起知识收集型问题，推荐问开放式的问题，比如：

• 大家都熟知的，一个页面从输入 URL 到页面加载完的过程中都发生了什么事情？
• 谈一下你所知道的（页面）性能优化方法？

关于手写代码

当然相对推崇的方式是考察候选人手写代码的能力，比如：

• 前段时间很火的，翻转二叉树，https://leetcode.com/problems/invert-binary-tree/
  alt

不过说实话，手写代码个人认为是挺变态的，如果不是当时这道题火了我也不会去做。

如果临场再让我手写，未必能一次性跑过，所以实现一些简单的冒泡排序个人认为会是一个不错的方式~

小妙招

有些情况下，由于初级岗位往往需要先经过一轮电话面试做初筛，没法考察候选人的手写代码能力。

而且对于一些准备充分的题霸，知识收集型问题和开放式问题都不太适用，我会选择问数学题。

举个很简单的例子：x ^ 3 = 3，估算x的值，精确到小数点第1位(^是次方)；

其实这是一道非常非常简单的题目，但在实际的面试过程中，不到20%的人能在不提示的状态下快速估算出答案，这个通过率对于初筛还是比较合适的；

先卖个关子，你算出来了吗?

为什么要问这种题目

1. 能在网上搜到的答案或方案的问题都不能算是好问题，实际工作中我们常常会遇到一些没有现成解决方案的问题，或者说国外有解决方案但是自己水平不够，不能通过快速阅读英文，比如去：google、quora、stackoverflow来找答案解决的问题
2. 我们都学过根号2 ≈ 1.414，根号3 ≈ 1.732，所以对于这种变种题，往往可以快速判断候选人的应变能力~
3. 数学是一切学科的根本，尤其是计算机

解法

• 二分逼近法，很明显我们知道，1 < x < 2，然后可以提示候选人计算一下1.5 ^ 3 = 3.375 > 3；

一般的候选人会顺着你的思路去计算 1.25 ^ 3 ……

聪明的会快速算一下 1.4 ^ 3 = 2.744 < 3（其实这牵涉到逼近法怎么优化的问题或者候选人对数字的敏感程度）

• 快速解法，根号2 < 1.5，1.5 ^ 2 > 2；

延伸

上面这道题其实太简单了，觉得没有难度的同学可以算一下类似的一道题：2 ^ x = 10，估算x的值，精确到小数点第1位~

• 提示思路1：

  1. 3 < x < 4
  2. 2^3.5 ≈ 8*1.414 > 10

• 提示思路2：

  3. 题目转换为估算 2^x=1.25
  4. 能否估算 2^(1/4) 和 2^(1/3)
  5. 2^(1/4) < 1.25 < 2^(1/3)

• 答案：3.25 < x < 3.3333

友情链接

常见面试题；

• Front-end-Developer-Questions
• Front-end-Developer-Interview-Questions
• node-interview

顺便安利一下leetcode，不忙的时候解解各类经典题目

支持多种语言包括js，当场跑case，难易可选，能看通过率、耗时还有解法讨论~

补充

最近学到另外一种面试技巧，就是不设具体的问题，从对所需候选人能力的一些范畴上定义出，需要一个啥样人的大概框架~
PS:常见的范畴

• 代码掌控力
• 工程化能力
• 解决问题能力
• 技术影响力
• 技术敏锐度
• 技术深广度

把这个框架的目标同步给候选人，让候选人自己往框架上套_{让候选人来说服面试官雇佣自己}