How to Conduct a Job Interview

https://mp.weixin.qq.com/s/lF6_0iIIVpfKgQdiAFdrGw

理解面试的双向性，你就应该理解面试的意义，一方面是筛选人才，另一方面也是拉拢人才，筛选不太合适的，拉拢优秀的。很多小公司一个很有意思的现象，越是大老板面试越客气，越会体现出友善的一面，他们知道吸引人才的不容易；而一些中层管理者面试往往毫无这方面的想法，甚至很容易体现出面试官的优越感。我自我刨析一下，不说别人，我自己入职场不久成为技术骨干的时候，也明显存在这方面的问题，但我岁数越大，越觉得年轻的时候那种心态和作风真傻逼。

以下几点，可能针对不同的目标人才，有不同的选择。

第一，要理解求职者的目标和未来的方向，这不是空话，这是你必须明确的，你能否满足对方的期待，以及能否让对方相信你确实能满足他的期待。

第二，试图证明，阐述他在这份工作中可以得到能力，素质，视野的提升。

这一条主要针对应届生，有潜质的年轻求职者。

第三，试图证明，企业的发展潜力可以满足他对职场地位，财富，社会资源的诉求，

这一条主要针对那些有一定基础和实力，需要一个平台跨越发展的人才，比如一些一线企业的技术经理，希望能找到一个快速发展的企业作为技术带头人给自己职场带来一个跨越。

第四，试图证明，他的能力和特长，在这个企业有足够的发展和发挥的空间。

这一条是针对高阶人才，很多高阶人才选择一些新兴企业会有一个担心，我的技术背景，我的知识背景，会不会无用武之地，一些高阶人才，除了待遇需求，也希望工作是可以持续稳定的发展，他们担心说来了发现不合适，可能短期就会离开，这样其实谈待遇条件意义都不大，或者因为自己的技能与诉求不符合，或者平台不足以发挥自己的全面能力，会导致自己名声受损或未来发展受限。

很多高阶人才真的是因为这个原因会拒掉一些非常有吸引力的offer。

为什么我之前说，以前技术面试我喜欢用场景题，而且场景题喜欢用一些有算法难度的，这代表两个意思，第一，简单的工作其实背后不简单，我们需要专业的技术人才。第二，我们的经验和技术处理能力，可以让面试者在未来的工作中得到提升。

随便说个以前说过的例子，每天网民发表大量文章，评论，每篇文章都要对大量屏蔽词做快速分析和过滤，我现在假设有100万文章，有1万屏蔽词，我想快速实现文章和屏蔽词的分析，如何实现快速的查询。如果每篇文章都要轮询1万个屏蔽词，这个系统开销肯定是不行的。

答案其实会者不难，AC自动机，一个上古时代的算法。但看这个案例，第一，是每个人都能理解的日常技术诉求，但当我们对性能提出要求时，技术难度就出来了。而这样的场景题目其实有很多。

再举个例子，搜索大翻页，按照一般的数据库查询，limit $start, $num 模式来查询，翻页数和系统开销基本上线性相关，也就是翻1000页会是翻第一页的1000倍开销，经典效率问题，也是旧时代一个搜索引擎蜘蛛能抓死社区论坛的常见问题。那么问题来了，第一，如何理解这里提到的线性相关，是否可以给出合理的解释。第二，如果要优化这个搜索翻页逻辑，如何设计数据结构和搜索语法。这个题这里不给答案，其实我旧文是有提的。

之前我们说招聘成本的优化，是不是只有裁剪面试时间，裁剪面试内容才叫做优化，不是，如果面试官通过更好面试过程能够提升优秀人才愿意一起发展的成功率，虽然单次面试成本可能增加，但转化率提升，特别是优秀人才的转化率提升，从统计来说，可能减少了更多无谓的面试，对面试本身也是一种效率优化。很多面试者都是撒网来的，特别是中小企业，面试官对这个要心里有数，千万别觉得自己高高在上。

当我们给心仪的人才发出了offer 而遭到对方拒绝的时候，我不知道有没有人认真对待过这个问题，到底是什么原因，对方最终去了哪里，对方为什么选择了那边。认真的站在旁观者角度，对方的选择对他来说是对还是错，如果我们可以给那边提供更好的空间和成长机会，如果我们可以给提供更多的回报预期，为什么对方选择了那边，这就必须要认真的反思。

http://katemats.com/views-from-the-top/

Lesson 3: Interviewing senior leaders is hard to do.

Another observation that I have seen play out is that it is very hard to hire senior leadership (and because of Lesson 2, it can take a while to know if you did it right or made a mistake).

There are plenty of fallacies with interviewing, but it becomes more challenging with executive leadership because there isn’t a set of skills that is easy to test. How do you test influence? Sure you can proxy it with a set of questions, but a few hours with someone doesn’t always indicate accurately if they will be successful in the role.

That is why many companies focus on the candidate’s experience and track record. Personal references and endorsements can also play a large part.

Perhaps the biggest reason that this is hard, though, is that leading a group of people effectively is dependent on so many factors: the team culture, the organizational goals, and of course, the individual personalities. What worked really well for one person in one environment doesn’t always translate to a new place. That is why adaptability and flexibility are important traits to look for in the hiring process, not just past successes.

https://yq.aliyun.com/articles/574226?spm=a2c4e.11153959.teamhomeleft.17.13771810iCjIVp

面试不要做的事

问一些知道性的问题比如问知不知道这个API干什么的，怎么调用，这个命令怎么用的，知道性的知识，google一下或者认真看下文档就应该知道。
问一些特别复杂的问题比如问一个特别复杂的算法，问一个很抽象的大问题，短时间内很难给予回答。
问一些假设性的问题假设你参与了这个项目，你觉得哪几个地方需要优化。

之所以说这些问题不应该问，我认为主要是因为这些很难考察到面试者的真实能力，45分钟的时间本来就很短，有些问题有可能比较偏，有些问题又过于庞大没法一下子描述特别清楚，还有一些问题缺乏上下文，让人摸不到头脑，所以尽量避免这么问问题，另外把握一个重要原则，不要在面试中试图证明别人不如自己，毫无意义，人无完人，总有覆盖不到的地方，按照这个规则招聘，会错过很多优秀的人才。

少问多听

一般刚开始做面试官的同学很喜欢以问为主，但因为大家的知识体系不太一样，成长环境也不同，直接这么问起来很难就找到面试者的优点，所以尽量让应试者自己陈述，然后以学习和交流的心态针对陈述中存疑的地方再进行发问，会更容易让应试者放松，也更容易让应试者更全面的表达自己。另外，问的差不多的时候，结尾的时候可以补充一句：您觉得刚才的面试中还有哪些我没问到的，您想再补充一下的内容？末了，再问下：我的问题问完了，您有什么想要问我的吗？

经验丰富，知识体系完整

经验能解决实际的问题，另外知识体系可以让你在遇到新的问题时举一反三，当然大公司和小公司要求的知识体系又不太一样，大公司更偏向一专多能的T型人才，小公司更喜欢全栈，所以到底要成为什么样的人，跟你的职业规划很有关系，是想在大公司成就一番事业，还是出去闯荡，那你点的技能树肯定是不一样的。到底应该怎么做，我自己的经验是，找到身边的标杆，向更优秀的同学学习，在阿里当然非常优秀的专业人才也好，架构师也好，都非常多，所以标杆应该也好找，业界当然也有很多成功的人，有了标杆，就努力向上吧。

保持良好的习惯，不忘总结和提升

http://firstround.com/review/The-anatomy-of-the-perfect-technical-interview-from-a-former-Amazon-VP/
You want to hire people who are smart, that get stuff done and have the functional set of skills you need for the role.
https://somedisagree.com/2016/03/11/conducting-technical-interviews-part-i/

Prepare a list of questions for yourself about the candidate. These aren’t questions you will be asking the candidate, but questions you hope to answer during the interview. Every question/problem/scenario you pose to the candidate should be about helping you answer these questions. For one of my programming questions, these questions are things like:

• Did she ask clarifying questions?
• Did he “define the contract” (API)?
• Did she get a valid solution? Naive, better, optimal?
• What was the time/space complexity of her solution(s)?
• Could he have a discussion about complexity?

https://somedisagree.com/2016/03/18/conducting-technical-interviews-part-ii-the-whiteboard/
If you are interacting with the candidate in any way, candidates who are confident and poised will tend to do better than other candidates. That has nothing to do with a whiteboard. Interviewers are prone to bias regardless of whether they are reading a resume, or reviewing an application, or having a one-on-one conversation, or conducting a whiteboard interview.

Imagine you are given some number of integer arrays, each with some number of integers in them. I need a function that will return all the integers, in order, that appear in one, and only one, of these arrays.

So, if you are thinking to yourself, “wait, wait, that’s not enough information” then you are exactly right. I have been deliberately vague in defining this problem because I want to get an answer to one of my questions about this candidate: “Did she ask clarifying questions?” There are several questions that could be asked about this problem as I have defined it. First, are the input arrays always sorted? (Yes.) Are there ever duplicate values in any of the input arrays? (Nope.) Are the sizes of the input arrays always the same? (No.) Can I modify the input arrays? (Hmm, let’s say no.) What language should I use? (Your choice.) How about Haskell? (Um… no.) So hopefully the candidate will ask at least one of these questions or possibly some other questions.

If the candidate asks one of those questions, I will respond with “good question!” and give them the answer. I really want to reward them for asking a good question and hope they will continue to do so. You’re doing great, keep it up. Also, I get to make a little plus in my notebook.

So if they don’t ask any of these questions and just start writing code I’ll observe for a bit to see if they are operating under the correct assumptions. If they are, then I’ll let them go, but if I think they might not be, I’ll interrupt and say, “oh, I should have said that the input arrays are sorted,” or whatever. I phrase that deliberately to make it my fault that I didn’t give them all the information. Hey, we’re all human here; relax, you’re doing fine.

So if they don’t ask a clarifying question is that a deal breaker? No, not even close. It’s definitely a plus if they do, but it’s just one piece of information, especially if the assumptions they have made all turn out to be correct. (The way I’ve written out the problem implies the answer to those questions, but it’s better to confirm them.)

As soon as they start writing code I get an opportunity to answer another one of my questions, “Did he ‘define the contract’ (API)”? Basically I’m looking for the function signature for the code about to be written. This is really important because it defines what the customer (in this case, me) wants from the program and what the engineer is promising to deliver. Nailing this down is really important. I’ve had candidates just start writing code with some variable definitions and a for loop. When this happens I will stop them and say, “let’s write the function declaration first.”

https://www.linkedin.com/pulse/7-steps-giving-successful-technical-interview-kevin-ferguson
Timeliness. Don't waste a candidate's time. A good candidate has other opportunities besides yours. Get them in, interview them, and get them a decision. It's the right thing to do and the candidate will appreciate the courtesy.
Know what you want. You must know exactly what you're looking for. If you don't, then don't start the interviewing process. You're wasting your time and more importantly the candidate's time. Define the job and the skills needed.
Don't have a checklist. You're not ordering parts to make something. You're interviewing.
Prepare for your interview. You must know what questions you are going to ask. Without a list of questions, you'll end up talking about the weather.
Train your interviewers. Don't let just anybody perform an interview. Train them to do it properly.
Remember the purpose of the interview. The purpose of the interview is to find and hire a candidate that's capable of doing the job to your satisfaction.
Make sure the candidate meets everybody. The candidate needs to meet the decision makers. Don't make him come back again.

For each topic, determine which questions you need to ask in order to be confident that the candidate knows it. You don't have time to ask every possible question per topic so pick questions carefully. For example, suppose I ask a candidate a SQL Server question such as, "What is the purpose of a Left Outer Join?" If he answers it quickly and correctly, then I don't need to ask him about inner joins because if he knows about outer joins he would most likely know inner joins. By picking the right questions, you eliminate a lot of others which saves you and the candidate time.
Make sure your questions are important to the job. Asking off the wall questions or questions which you know the candidate can't answer is a waste of time.
Be willing to improvise. Many times a candidate will say something that you want to dig deeper. This is an excellent opportunity to learn even more about his or her skills. The list of questions is just a guide.

The interviewer must be knowledgeable of the subject matter and be able to ask questions you've defined and know that the answer given is correct or incorrect and understand the variations of possible answers. In addition, a good interviewer will "go off script" based on answers and dig a little deeper into a person's skills. This is what you want.


Unless you're Google and you get 10,000 resumes a week, you don't need to ask the infamous two trains and a bird problem. Yes, maybe that does tell a lot about a person's thinking but you really just need to have somebody do the job, right?


Two trains leave from opposite ends heading towards each other for a collision.. The distance between the two trains is 300 miles. Each train travels at 20 miles/hour. As soon as the trains set off, a bird starts flying from train A towards train B at a speed of 60 miles/h. As soon as the bird reaches train B it changes direction and heads towards train A. The bird continues to fly back and forth between the two trains until the last when the two trains collide and the bird gets squashed. Find the total distance traveled by the bird?

Yes, it's an interesting question. I was actually asked this question once back in 199If you like the candidate, chances are another company does too. You are competing against other companies for candidates just like candidates are competing against other candidates for your job.
https://medium.com/@101/how-to-conduct-a-technical-interview-for-software-engineer-52648ce8b876
STAR Questions

Target: To understand person’s analytical & problem solving skills and to prove their potential value to a company.

What to ask: STAR format stands for Situation, Task, Action, Result. The STAR model is a framework for answering questions that start like this: “Describe the most difficult/interesting/rewarding…” or “Give me an example where you…” with a short story.
Don’t focus too much on puzzles, API quizzes, math riddles, or other parlor tricks

Unless you’re specifically hiring someone to design you the next sorting algorithm.
Don’t pay too much attention to APIs

People seem so proud they know a lot of APIs. But APIs were designed to be easy to learn. You should really rather hire a smart person that you know can learn most any API than one that brags about the few they already know. Knowing APIs it’s not bad. It’s just not the most interesting thing on the resume.
https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

The right way to do a phone screen is to do most of the talking, or at least the driving. You look for specific answers, and you guide the conversation along until you've got the answer or you've decided the candidate doesn't know it. Whenever I forget this, and get lazy and let the candidate drone on about their XML weasel-pin connector project, I wind up bringing in a dud.

The second pattern is that one-trick ponies only know one trick. Candidates who have programmed mostly in a single language (e.g. C/C++), platform (e.g. AIX) or framework (e.g. J2EE) usually have major, gaping holes in their skills lineup. These candidates will fail their interviews here because our interviews cover a broad range of skill areas.

These two phone screen (anti-)patterns are related: if you only ask the candidate about what they know, you've got a fairly narrow view of their abilities. And you're setting yourself up for a postmortem on your phone screen.

1) Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.

2) OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.

3) Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.

4) Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.

5) Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.

Area Number One: Coding

) OO Design

This is where most candidates fail with OO. They can recite the textbook definitions, and then go on to produce certifiably insane class designs for simple problems. For instance:

• They may have Person multiple-inherit from Head, Body, Arm, and Leg.
• They may have Car and Motorcycle inherit from Garage.
• They may produce an elaborate class tree for Animals, and then declare an enum ("Lion = 1, Bear = 2", etc.) to represent the type of each animal.
• They may have exactly one static instance of every class in their system.

For the OO-design weeder question, have them describe:

1. What classes they would define.
2. What methods go in each class (including signatures).
3. What the class constructors are responsible for.
4. What data structures the class will have to maintain.
5. Whether any Design Patterns are applicable to this problem.

Here are some examples:

1. Design a deck of cards that can be used for different card game applications.
   Likely classes: a Deck, a Card, a Hand, a Board, and possibly Rank and Suit. Drill down on who's responsible for creating new Decks, where they get shuffled, how you deal cards, etc. Do you need a different instance for every card in a casino in Vegas?
2. Model the Animal kingdom as a class system, for use in a Virtual Zoo program.
   Possible sub-issues: do they know the animal kingdom at all? (I.e. common sense.) What properties and methods do they immediately think are the most important? Do they use abstract classes and/or interfaces to represent shared stuff? How do they handle the multiple-inheritance problem posed by, say, a tomato (fruit or veggie?), a sponge (animal or plant?), or a mule (donkey or horse?)
3. Create a class design to represent a filesystem.
   Do they even know what a filesystem is, and what services it provides? Likely classes: Filesystem, Directory, File, Permission. What's their relationship? How do you differentiate between text and binary files, or do you need to? What about executable files? How do they model a Directory containing many files? Do they use a data structure for it? Which one, and what performance tradeoffs does it have?
4. Design an OO representation to model HTML.
   How do they represent tags and content? What about containment relationships? Bonus points if they know that this has already been done a bunch of times, e.g. with DOM. But they still have to describe it.

The following commonly-asked OO design interview questions are probably too involved to be good phone-screen weeders:

1. Design a parking garage.
2. Design a bank of elevators in a skyscraper.
3. Model the monorail system at Disney World.
4. Design a restaurant-reservation system.
5. Design a hotel room-reservation system.

A good OO design question can test coding, design, domain knowledge, OO principles, and so on. A good weeder question should probably just target whether they know when to use subtypes, attributes, and containment.

Area Number Three: Scripting and Regular Expressions

Last year my team had to remove all the phone numbers from 50,000 Amazon web page templates, since many of the numbers were no longer in service, and we also wanted to route all customer contacts through a single page.

Let's say you're on my team, and we have to identify the pages having probable U.S. phone numbers in them. To simplify the problem slightly, assume we have 50,000 HTML files in a Unix directory tree, under a directory called "/website". We have 2 days to get a list of file paths to the editorial staff. You need to give me a list of the .html files in this directory tree that appear to contain phone numbers in the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.

How would you solve this problem? Keep in mind our team is on a short (2-day) timeline.

For the record, I'm not being tricky here. Once candidates start down the wrong path (i.e. writing a gigantic C++ program to open every file and parse character by character, using a home-grown state machine), I stop them, tell them this will take too long, and ask if there are any other possibilities. I ask if there are any tools or utilities that might be of use. I give them plenty of hints, and ultimately I tell them the answer.

  grep -l -R --perl-regexp "\b(\(\d{3}\)\s*|\d{3}-)\d{3}-\d{4}\b" * > output.txt

But I don't even expect candidates to get that far, really. If they say, after hearing the question, "Um... grep?" then they're probably OK

They can also use find, or write a Perl script (or awk or bash or etc.). Anything that shows they have even the tiniest inkling of why Unix is Unix.

Let's say you're on my team, and I've decided I'm a real stickler for code formatting. But I've got peculiar tastes, and one day I decide I want to have all parentheses stand out very clearly in your code.

So let's say you've got a set of source files in C, C++, or Java. Your choice. And I want you to modify them so that in each source file, every open- and close-paren has exactly one space character before and after it. If there is any other whitespace around the paren, it's collapsed into a single space character.

For instance, this code:

foo (bar ( new Point(x, graph.getY()) ));

Would be modified to look like this:

foo ( bar ( new Point ( x, graph.getY ( ) ) ) ) ;

I tell you (as your manager) that I don't care how you solve this problem. You can take the code down to Kinko's Copies and manually cut and paste the characters with scissors if you like.

Same thing, more or less. You'd do it with a Unix command like sed (using a regular expression), or do it in your editor using a regex, or write a quick Ruby script, whatever. I'd even accept having them use a source-code formatter, provided they can tell me in detail how to use it, during the interview (to a level of detail that convinces me they've used it before.)

Area Number Four: Data Structures

Here's what they need to know about big-O. They need to know that algorithms usually fall into the following performance classes: constant-time, logarithmic, linear, polynomial, exponential, and factorial.

1) What are some really common data structures, e.g. in java.util?

2) When would you use a linked list vs. a vector?

3) Can you implement a Map with a tree? What about with a list?

4) How do you print out the nodes of a tree in level-order (i.e. first level, then 2nd level, then 3rd level, etc.)

5) What's the worst-case insertion performance of a hashtable? Of a binary tree?

6) What are some options for implementing a priority queue?

Area Number Five: Bits and Bytes

they should be able to tell you what 2^5 - 32 or 2^10 - 1024 is, in decimal. They shouldn't stare blankly at you when you ask with 2^16 65536 is. It's a special number. They should know it.

Candidates should know the probable sizes of the primitive data types for a standard 32-bit (e.g. Intel) architecture.

If they're a Java programmer, they should know exactly what the primitive types are (byte, short, int, long, float, double, char, boolean) and, except for boolean, exactly how much space is allocated for them per the Java Language specification.

Everyone should know the difference between signed and unsigned types, what it does to the range of representable values for that type, and whether their language supports signed vs. unsigned types.

Candidates should know the bitwise and logical operators for their language, and should be able to use them for simple things like setting or testing a specific bit, or set of bits.

Candidates should know about the bit-shift operators in their language, and should know why you would want to use them.

A good weeder question for this area is:

Tell me how to test whether the high-order bit is set in a byte.

Another, more involved one is:

Write a function to count all the bits in an int value; e.g. the function with the signature int countBits(int x)

Another good one is:

Describe a function that takes an int value, and returns true if the bit pattern of that int value is the same if you reverse it (i.e. it's a palindrome); i.e. boolean isPalindrome(int x)

They don't have to code the last two, just convince you they'd take the right approach. Although if you have them code it correctly, it can count for your Coding weeder question too.

C/C++ programmers should know about the sizeof operator and how (and why/when) to use it. Actually, come to think of it, everyone should know this.

All programmers should be able to count in hexadecimal, and should be able to convert between the binary, octal, and hex representations of a number.

Me:   So! What languages are you most familiar/proficient with? 

Me:   So! What data structures do we have available to us, as programmers? 

Me:   So! What the the primitive types in Java (or C++)?

Me:   So! What text-editor do you use?
Them: Visual Studio. 
Me:   OK. What about on Unix?
Them: On Unix I use vi. 

Me:   So! What did you study in your Operating Systems class?

Please cover all five areas if you're a phone screener. If you're the second screener, ask if you don't see evidence of them in the first screener's notes. (And then follow up and remind the first screener they should have asked these things.)

https://medium.com/freshbooks-product-development/the-one-question-i-ask-in-every-interview-66561f69c233
http://tech2ipo.com/10027954

Teach me something.

Anything. Something you think is interesting and relevant. Maybe something you’ve learned recently. You don’t have to be an expert on it, but you should know enough to explain it properly. Something you can teach in 10 minutes.

I want to know if I’m able to learn from you. I want to know if your team will be able to learn from you.

• I asked Tobi, a dev on my team: I see you’ve used ES6 generators in your code, how does that work exactly?
• I asked Marcus, an analyst on the Finance team: Explain to me how cohort analysis works. Should I apply it to measure the impact of this feature I’m adding?

Sometimes junior developers say to me “you probably already know …”.Teach me anyways — you’ll be surprised how little I know.

• Can you communicate the concept effectively?
• Do you have more than just a surface level understanding of it?
• Do you seem genuinely interested in explaining it or does it seem like a drag to you?

Ability to learn is good. Ability to teach what you’ve learned is great.

My team regularly has a “Teach me something” meeting, where anyone can share something they’ve learned during the last sprint. 
https://www.linkedin.com/pulse/interviews-exams-jacob-kessler
An interview is trying, within an hour, to evaluate a candidate's ability to be a useful and productive member of a team. They will be working on problems that require weeks to even determine how you are going to approach them, and even longer to implement, often with advice from their peers, not solving problems quickly 'without hints'

Interviews are predictive tools. What you (as an interviewer) have is an hour to evaluate "How much will this person contribute if we hire them?", and the interview questions are tools to that end. I think that part of the issue is that it's true that poor candidates (in general) will struggle with coding questions and require a lot of help, and that good candidates (in general) will be able to work through the questions quickly on their own. But these are side effects of what we're actually trying to measure, not the goals in and of themselves[4]. What we actually want to see is how the candidate thinks about and breaks down the problem, and then from there how well they can translate their ideas into an actual working solution.
Write a Sudoku solver. It takes a 2d array with some positions filled and returns a 2d array with all of the positions filled and conforming to the Sudoku constraints

What would a good answer to the question look like in a non-exam-world? There are three basic tasks (checking if the board is valid, choosing a next square to fill, and tracking choice state to recover from a bad guess), and a good answer will identify those tasks, propose a few ways to approach them, and comment on their relative merits. They will also comment on what properties they are looking for in their task solutions. For example, checking if the board is valid needs to be fast, since it will be done frequently, but having a complex square-choosing algorithm may be important because the impact of an incorrect guess is so significant. Having outlined a basic way to approach all three of those, a good candidate will be able to translate what they described into code fairly accurately, and then iterate on it (by pre-calculating and caching available numbers per square to make the validity check faster, for instance) either on their own or with some gentle hinting from the interviewer. They should be able to describe why they are doing each thing that they are doing, and be able to discuss the tradeoffs they are making (caching increases space consumption). While Candidate 2 above didn't get all of that, Candidate 1 skipped everything other than breaking down the tasks and providing a solution - there was no discussion or evaluation of tradeoffs or alternatives, which should be significant parts of the interview.

https://www.yejianye.com/2011/08/02/developer-interviews-at-startups/

• Only rank A people would hire people better than themselves. Rank B or rank C people could only hire people worse than them.
• If there’re any doubts, there’s no doubt.

So we should be extremely careful when hiring early employees. Otherwise, the company will be screwed.

The process of my interview is to measure the following 4 qualities of a candidate. The significances of those qualities are 1) > 2) > 3) > 4)

• Raw intelligence
• Fundamental knowledge on programming and compute science
• Coding styles
• Working experience

The process of my interview is to measure the following 4 qualities of a candidate. The significances of those qualities are 1) > 2) > 3) > 4)

• Raw intelligence
• Fundamental knowledge on programming and compute science
• Coding styles
• Working experience

All of them are important. But I will pick a smarter guy over a guy with more working experience, because working experience is something a person would gain over time, but smartness isn’t. Since smarter people learn things much faster, after 1 or 2 years, the smart guy would exceed the other candidate on domain knowledge. Same rule applies to 2) and 3), learning compute science is harder than learning good coding styles.

Working experience is easy. Just take a look at their resumes. It would better to ask some details on relavant projects they’ve been working on. The goal is to figure out what exactly they do in those projects.

Coding styles also could be easily tested. Ask whether they have any personal projects, take a look at some code snippets in the code base. The bonus for this question is that if the candidate doesn’t have any code to show, he probably isn’t passionate enough for a startup. A written test would also do, but I would prefer the candidate to write the code offline. Since we don’t have too much time on interview, and if the code is too short, we can’t really see his coding styles. And if we have to ask the candidate to write code during onsite interview, make sure they bring their laptop. Personally, I will feel much comfortable to write code on my favorite editor than a piece of paper or someone else’s computer.

Working experience is easy. Just take a look at their resumes. It would better to ask some details on relavant projects they’ve been working on. The goal is to figure out what exactly they do in those projects.

Coding styles also could be easily tested. Ask whether they have any personal projects, take a look at some code snippets in the code base. The bonus for this question is that if the candidate doesn’t have any code to show, he probably isn’t passionate enough for a startup. A written test would also do, but I would prefer the candidate to write the code offline. Since we don’t have too much time on interview, and if the code is too short, we can’t really see his coding styles. And if we have to ask the candidate to write code during onsite interview, make sure they bring their laptop. Personally, I will feel much comfortable to write code on my favorite editor than a piece of paper or someone else’s computer.

For fundamental programming skills, we could ask algorithm questions such as dynamic programming, recursive and binary search. The question shouldn’t be too hard, a variant of basic usage of the algorithm will do. Another good set of questions are asking candidates giving estimation on time complexity and space complexity of a function. Giving solutions on a simple problem with different scales is also a fine approach to test their knowledge on the whole compute system. Sorting in memory and Sorting in a distributed system will be very different.

For more senior job position, ask architecture design question would be more appropriate, but I also find designing such questions are very challenging as well. It would be best that the candidates have some personal projects, then we could ask them to explain the design of their software architecture.

Raw intelligence is a key factor, but is also very hard to measure. The common approach is asking puzzles. I would recommend to prepare at least 2 puzzles, so if the candidate fails the first one, we could use second one as backup. The time control is essential for puzzles, giving hints if the candidate isn’t able to come up with anything in 5 mins. Closing the question in 10 mins. It’s important to ask same set of puzzles to a group of candidates, so we could compare them side by side.

https://www.quora.com/topic/Job-Interviews

https://ericlippert.com/2015/06/08/interviewing-candidates

I have some primary goals:

• Prevent bad hires
• Make good hires
• Leave the candidate with a positive impression of the company

Of course preventing bad hires is of far higher priority than getting good hires. If we fail to get a good hire, that’s too bad, but if we make a bad hire, that can drag down the productivity of a team for years.

Then I pick something that looks vaguely interesting and fairly recent on the candidate’s resume, and ask them to give me first the “elevator pitch” — a few sentences describing the project and why it was important or interesting — and then to describe the problem they had to solve in more detail.

This is, again, to put the candidate at ease because they are talking about something they chose to put on their resume and are presumably an expert in. I want to find out first, can they communicate well? You’d be surprised at the number of people who put things on their resume that they cannot describe the purpose of in a sentence or two. Second, what actually did they do on this project? This may come as a shock to you, but people inflate their resumes all the time. By digging into the details of what exactly they did on the project, I get a sense of whether they really are “smart and gets stuff done” or not.

A good technical question has characteristics such as:

• can be stated and solved in a short amount of time with a short amount of code
• does not require an “aha!” insight that is difficult to come up with under stress
• is not a “stock” problem or “brain teaser”
• can be made arbitrarily harder or easier, to better gauge what level the candidate is really at
• is similar to the sorts of problems the candidate will have to solve on the job
• tests skills other than straight up coding, like ability to read existing code, or deal with an ambiguous specification

Next, I tell the candidate that they are tasked with code reviewing this code for any problems whatsoever. I see what sorts of general problem areas they look for when reviewing code they did not write. The code I give has design, robustness, security, testability and portability problems. I see which of those areas they dig into naturally, and if they miss some, I suggest “what if the client is deliberately attempting to damage the server; what can they do?” or “what if I recompiled this code to run on a 64 bit machine?” and see if they take the hint.

This is a real-world skill that I have to use every day — first, in reviewing my own code and that of my coworkers. And second, because I’m in the business of writing programs that look at buggy code and figure out that it’s buggy. If the candidate can’t review other people’s code then they’re unlikely to be successful anywhere. If they cannot find any of a dozen bugs in a program that has only six statements, they’re unlikely to be successful writing analyzers that find bugs.

Here I’m looking for comprehension, critical thinking and basic domain knowledge. Red flags often surface at this point. I’ve had candidates with PhDs in computer science, for instance, who did not know that on a 64 bit architecture, pointers are 64 bits wide. And why should they? As is often pointed out, astronomy is not the science of building telescopes. Knowing a lot about theoretical computer science does not necessarily entail knowing how wide the bus is between the processor and main memory. But a candidate who does not understand how pointers are implemented on typical machines is unlikely to be successful working on a team that designs analyzers that look for errors involving pointer size.

I also see a lot of candidates who know that code is wrong but cannot say what the consequences of it are. Undefined behavior is by definition undefined, but describing what might happen if a hostile client, say, forges a pointer to arbitrary memory and causes the server to execute a virtual method with that pointer as “this” demonstrates that the candidate understands how the compiler actually generates the code.

The next phase involves design, and maybe some small amount of coding. “You can change the implementation of these APIs but not change the method signatures; how would you fix each of the bugs you found?”

Again, this is a basic job skill that we have to exercise every day: fixing a bug in a callee without being able to change the behavior of the caller. Perhaps the calling code is owned by the customer, or another team, or has already shipped, or whatever.

At this point I am looking for things like:

• Are there any more red flags? Good heavens, the number of candidates I’ve seen who tried to fix the portability problem by compressing a 64 bit pointer into a 32 bit integer is enormous. There’s no clever trick here that I’m asking them to figure out. You can’t fit twenty pounds of flour into a ten pound sack, that should be obvious, so you need to find another way to solve the problem.
• What tools are in the candidate’s toolbox? All candidates eventually figure out that they will need to add an auxiliary data structure that maintains a map from a 32 bit integer to a 64 bit pointer, because of the aforementioned ten pound sack. Do they know that there are off-the-shelf map classes? If not, do they have confidence that they could write one?
• Does the candidate identify the actually hard part of the problem? The hard part of the problem is not realizing that you need a map, but rather ensuring that the keys are unique when a new key-value pair is added to the map. (As I alluded to in the previous episode.) Even when I repeatedly ask “in your sketch of the new code you never say how you compute the value of the key; how is that value generated?” some candidates just don’t follow up on it and keep on trying to tell me how the map works. Or they go back to the previous point and start trying to compress the 64 bit value into a unique 32 bit key, which is impossible, and is the reason why we have a map.
• How does the candidate deal with an ambiguous situation? The problem is deliberately vague, and the hard part involves generating unique values. If there are two clients each generating two jobs and then shutting down, generating unique 32 bit integer keys is not hard. If there are millions of clients generating millions of jobs then generating unique keys may be very difficult indeed. Many candidate never ask me how many clients and jobs there are in this system, and therefore some generate highly over-engineered solutions, and some generate solutions that do not scale at all.
• Can the candidate make the connection to an existing solved problem? This is hard to do under stress, but it is still interesting to see. Some candidates very quickly figure out that the problem “generate a unique 32 bit number and don’t re-use it until the client is done with it” must have been previously solved by whoever wrote the 32 bit version of their favorite memory allocator. After all, that’s what a memory manager is: a device which gives you a unique pointer when you ask for one, and does not give it out again until after you say you’re done with it. Therefore the problem I’m posing can be reduced to a previously solved problem. Some candidates exhibit magical thinking about memory allocators and the like, as I alluded to previously. I have had many candidates realize that the problem is analogous to a heap; I’ve only had one candidate say “I’ll solve the problem by having Windows make me a four billion byte heap, and then allocate single bytes out of it to generate unique 32 bit numbers”. That is really reducing the problem to a previously-solved problem!

If the candidate is doing very well then I can easily make the problem harder. Suppose the clients are calling on many threads; what locking strategy keeps throughput high? Suppose the jobs need to survive the computer being rebooted. Suppose the server is on a cluster and can offload work onto other servers. I want to find out just how deep their knowledge goes. Or I can make it easier; suppose there is never more than ten clients. Suppose that jobs starting and finishing are in some reasonable order, like, a job started later than another always finishes later as well. And so on. I want them to walk away feeling like they solved at least some version of the problem.

Finally, I try to save some time at the end for the candidate to ask me questions about the team, the position, the company, and so on

This is another chance for me to “sell” the company to the candidate, and also I get some insight into what is important to them from their questions.
https://ericlippert.com/2015/06/04/its-not-magic/

You can learn a lot about a candidate from their approach to this sub-problem. Candidates, sensibly enough, always try to solve the unique cookie problem by using an off-the-shelf tool that they are familiar with, like:

• a GUID
• a timestamp
• a global threadsafe counter
• a random number
• an auto-generated primary key field of a database table

Where I start to see magical thinking though is when I ask the candidate to assume that their chosen solution is simply not yet implemented on their platform. Rather, they are the developer who needs to implement the tool if they want to use it in the overall solution.

I fondly remember the moment of dawning comprehension when I asked a particular candidate “But suppose you had to write the code in the database implementation that auto-generates the primary key on the table you are using to solve this problem. How would that code work?”

https://ericlippert.com/2015/06/01/writing-code-on-whiteboards-is-hard/

Do you:

• rush right in and start coding without thinking the problem through first?
• find areas where the problem is ambiguous and clarify them, or do you make a bunch of assumptions?
• break the problem down into pieces?
• do the easy pieces, paint yourself into a corner, and attempt to handwave your way out of the situation, or work on the hard stuff first?
• have any confidence that your solution is correct?
• do anything to prove to yourself and me that it is correct?

It would be wise to make it easy for me to see that you’re a well-organized person with good problem solving skills. Leave lots of space — you might need to stick in some extra lines. Write slowly and clearly. Explain what you’re doing as you do it. If the code is clear, well-organized, legible, and at least vaguely syntactically correct, it will be a lot easier on both of us to tell whether the code is well designed and bug free. Walk through some simple test cases — don’t just dash down some code and say “yep, that’s correct!”

• how would a tester attack it? Is the design even testable?
• does it handle stuff that hostile/buggy callers are going to throw at it? null pointers, large denominators, huge arrays?
• does it work well with other technologies? that is, does it use the conventions of COM or ATL, or does it work against them?
• is it correct, robust, maintainable, debuggable, portable, extensible?
• how would you know whether this was the code the customer wanted or not?

https://jocelyngoldfein.com/screening-youre-doing-it-wrong-70de1f797c1c

In a hiring decision, the scariest mistake we can make is hiring the wrong person. In a screening decision, the scariest mistake we can make is passing up a potential hire. With hiring decisions, when we are in doubt, we default to “no” to avoid risk. When we’re screening, and we’re on the fence, the less risky answer is “yes.”

If you tell screeners to select only candidates sure to be hired, you will miss out on most great candidates, especially non-pedigree talent or anyone that seems at all risky

High onsite to offer ratios don’t maximize engineering productivity, they maximize interviewer morale. Bringing someone onsite who fails is embarrassing, and mediocre interviews feel like a waste of time no matter what the math says. But avoiding them is an awfully expensive perk.

Better to cultivate an interviewing team that understands the odds, believes it’s worth working hard to get high quality teammates, and doesn’t beat up screeners over the misfires. Then you gain a real hiring competitive advantage — in speed, throughput, and quality.

https://jocelyngoldfein.com/a-recipe-for-an-interview-e4af1211d590

Question #1: You’ve been doing <X> for a while. About how much of <X> have you personally done?

• Good/bad answer: This is just a ranging shot so you have context to gauge their answers. You’re looking for them to have done enough that it’s fair for you to evaluate their expertise. If they haven’t done much, maybe switch gears and ask about something else.

Question #2: What does it mean to do <X> well?

• Good answer: values that match yours! Bonus points for being opinionated about this (if you agree with their opinions), bonus points for demonstrating they’ve given this thought. I expect senior candidates to have a point of view, or even to have spent time teaching others how to do it.

Question #4: Have you made any <X> mistakes? Pick one and tell me the story.

• Good answer: I like it when people are judgmental. That suggests to me that they’ll learn from mistakes and move forward from them. I also like people who own their mistakes, don’t tell me “I was too trusting of other people who screwed up.” Great candidates relate their mistakes back to their answer to #2 (what is important). You’re looking for a real mistake, not a fake one, but not a mistake so glaring you can’t relate.

Question #5: How did you ultimately deal with the situation?

• Good answer: They took responsibility, identified the problem in a short period of time, took quick action, made thoughtful attempts to solve the problem, either those attempts worked, or they got help. Bonus points if they were mature about it, have solved similar problems more than once, and the fix went smoothly. Alternatively, bonus points if it was their first time and they can articulate what they learned from a rocky situation.

Question #6: Do you think you could have avoided the mistake?

• Good answer: “No, and here’s a good reason why.” Or, “Yes, and here’s a good reason why.” In other words, they’ve already thought about it and have a point of view that seems sane. It doesn’t have to be profound.

Question #7: Would you do anything differently in the way you do <X> to avoid that mistake?

• Note: Good candidates will have anticipated and already answered this in response to #6 or even #5.
• Good answer: “Here’s what I already changed/in process of changing, remember <specific detail from answer to #1/#2/#3>? That was because of this situation.” (No credit if you don’t think it’s a good change or wouldn’t have solved the problem.)
• OK answer: Some mistakes are not avoidable; it’s not a bad answer if the candidate thinks there was nothing to change and can give you a good explanation why.
• OK answer: “Oh, I didn’t tell you about this before, but <specific detail> is the change I made.” (This is surprisingly rare.)

When you’re done asking this question, you will have a strong read on how judgmental they are; how smart they are; what they value; how proactive they are; how they deal with tough situations; whether they can express vulnerability and admit weakness; how they introspect, take accountability, and improve from mistakes. You’ll even have a good idea how skilled and experienced they are at <X>.

How people handle mistakes (and reflect on and learn from them) is pretty telling for you as an interviewer. Operating in a startup environment, there is no textbook, no map, and there’s going to be lots of adversity as you go. So choose teammates who will have your back along the way.