开发人员面试_开发人员面试指南-优快云博客

开发人员面试

by Dave Smith

戴夫·史密斯(Dave Smith)

开发人员面试指南 (A developer’s guide to interviewing)

备用标题：如何面试公司 (Alternate title: How to interview a company)

Have you ever been in a job interview, and the interviewer looks across the table and says, “do you have any questions?”, and you just stare back and say, “umm, I don’t think so”. If this has happened to you, there’s a good chance you took a pretty one-sided view of the interview experience.

您是否曾经参加过工作面试，面试官看着桌子对面说：“您有任何问题吗？”，您只是回头说，“嗯，我不这么认为”。如果这发生在您身上，那么您很有可能对面试体验有了一个相当侧面的看法。

As a candidate, you are understandably focused on one outcome: getting the job offer. But don’t forget that job interviews are not one-way. You should be just as focused on interviewing the company as they are focused on interviewing you.

作为候选人，可以理解的是，您专注于一个结果：获得工作机会。但是，不要忘记面试不是单向的。您应该专注于采访公司，就像他们专注于采访您一样。

But what should you ask them?

但是你应该问他们什么？

Lots of job seeking developers have asked me this question. Over the past 15 years, I’ve worked for 7 companies (counting 2 internships and a 6-month stint at a startup), and I’ve interviewed at a dozen others. I’ve finally decided to write down all the questions I ask during these interviews in hopes others find them helpful.

很多求职的开发人员都问过我这个问题。在过去的15年中，我曾为7家公司工作(计算过2次实习和在一家初创公司工作了6个月的时间)，并与其他十几家公司进行了面试。我最终决定写下我在这些采访中提出的所有问题，希望其他人能对他们有所帮助。

Side note: We cover this topic and many others in our weekly developer advice podcast Soft Skills Engineering. Subscribe!

旁注：我们在每周的开发人员建议播客“ 软技能工程”中介绍了此主题以及其他主题。订阅！

My goal is for this to be a living document. If you have suggestions, please let me know via Twitter, and I’ll incorporate them for everyone to benefit.

我的目标是要成为一个活生生的文件。如果您有任何建议，请通过Twitter告诉我，我将其合并为所有人使用。

你会和谁说话？ (Who will you talk to?)

While interviewing, you’ll usually get to meet three personas. Depending on the size of the company, these might be one human being or multiple:

面试时，您通常会遇到三个角色。根据公司的规模，这些人可能是一个人或多个人：

Software Engineers
软件工程师
Engineering Managers (technical lead, middle manager, director)
工程经理(技术主管，中层经理，主管)
Company Leadership (VP, CTO, CEO, department manager)
公司领导(副总裁，首席技术官，首席执行官，部门经理)

I have different questions for each of these personas, which I will list below. Note that I sometimes repeat the same question to multiple personas to see how their answers compare.

对于这些角色，我有不同的问题，我将在下面列出。请注意，有时我会向多个角色重复同一问题，以查看他们的答案如何比较。

This is a pretty long article, and it’s meant more as a reference than a read-through piece. If I were interviewing today, I would bring this with me and (discreetly) refer to it during my interview.

这是一篇很长的文章，它的目的更多是作为参考，而不是通读的文章。如果我今天要面试，我会随身携带，并在面试时(谨慎地)提及。

Most of these questions do not have a “right” or “wrong” answer. They are designed to help you learn about the company, its culture, processes, and organization. They also serve as conversation starters, which can be quite helpful during an interview when your brain has shut down.

这些问题大多数都没有“正确”或“错误”的答案。它们旨在帮助您了解公司，公司的文化，流程和组织。它们还可以作为对话的开始者，这在您的大脑关闭时的采访中会很有帮助。

As a matter of courtesy, I usually tell interviewers at the beginning of the interview that I would like to have some time to ask questions. This will help them plan accordingly. Usually, they let me ask questions at the end of the interview, so be sensitive to the interviews’ schedule, and make them aware of your intentions early in the process. After each question, pause to ask if it’s ok for you to continue asking questions, and how much time the interviewers have.

出于礼貌，我通常在面试开始时告诉面试官我想花一些时间问问题。这将帮助他们做出相应的计划。通常，他们让我在面试结束时问一些问题，因此要对面试的时间表保持敏感，并在此过程的早期使他们知道您的意图。回答每个问题后，请暂停询问是否可以继续提问以及面试官有多少时间。

给软件工程师的问题 (Questions for Software Engineers)

1.您如何知道每天要做什么？ (1. How do you know what to work on each day?)

The purpose of this question is to identify dysfunction. I want to get answers from 2 or 3 engineers. If company leadership says they follow a certain process, but the engineers don’t talk about the process, that’s a sign of dysfunction. If you get different answers from different engineers, that’s another sign of dysfunction.

这个问题的目的是确定功能障碍。我想从2或3位工程师那里获得答案。如果公司领导层说他们遵循某个过程，但是工程师们没有谈论这个过程，那就是功能失调的迹象。如果您从不同的工程师那里得到不同的答案，那就是功能障碍的另一个迹象。

In a high quality team, I get consistent answers to this question. Every developer knows the process, and the process is light weight enough to be supportive of the engineers rather than oppressive to them.

在一支高素质的团队中，我对这个问题有一致的答案。每个开发人员都知道该过程，并且过程轻巧，足以支持工程师，而不是压迫他们。

Example of a good answer (there are many others): “We do N-week sprints wherein each engineer commits to a set of features and bug fixes to deliver. Each day we report progress on our commitments to each other. We have an amazing product manager who interfaces with customers to help us prioritize features and bug fixes.”

一个很好的答案的例子(还有很多其他答案)：“我们进行N周冲刺，每个工程师都致力于提供一系列功能和错误修复。每天我们都会报告彼此的承诺进展情况。我们有一位了不起的产品经理，他与客户互动，以帮助我们确定功能和错误修复的优先级。”

Example of a bad answer (there are many others): “I come into the office and see what fires are burning. Most days, I get interrupted with an emergency.”

一个错误答案的例子(还有很多其他答案)：“我走进办公室，看看有什么大火在燃烧。大多数时候，我会因紧急情况而打断。”

Notice I don’t mention “Scrum” or any other specific methodology. I’m much less interested in the labels the company uses for their engineering process than the actual day-to-day “how stuff gets done”.

注意，我没有提到“ Scrum”或任何其他特定方法。我对公司用于其工程流程的标签的兴趣远不如实际的日常“工作完成方式”。

2.您将什么用于版本控制？ (2. What do you use for revision control?)

Good tooling is a strong indicator of a good team. If a team is using an ancient revision control system, they are probably using a bunch of other outdated tools. Furthermore, they probably don’t value the efficiency gains that can be achieved by investing in good tooling.

好的工具是好的团队的有力指标。如果团队使用的是古老的版本控制系统，那么他们可能会使用其他许多过时的工具。此外，他们可能不重视通过投资优质工具而获得的效率提高。

A good follow-up question is to ask about workflows. Do you use branches? Do you prefer rebasing or merging (git terms)? These questions will tell you how expert they are with their chosen tools, which will tell you a lot about their level of proficiency, which will in turn tell you what to expect if you take the job. For example, will you be the “local git expert” or will you be learning from a veritable Linus Torvalds?

一个很好的后续问题是询问工作流程。你使用分支吗？您喜欢重新定级还是合并(git术语)？这些问题将告诉您使用所选工具的熟练程度，这将告诉您很多有关其熟练程度的信息，进而可以告诉您如果接受这份工作会带来什么期望。例如，您将成为“本地git专家”，还是向名副其实的Linus Torvalds学习？

This question can start a discussion about tools in general, which will often give you some good insight.

这个问题可以引发有关工具的一般讨论，这通常会给您一些很好的见解。

3.您喜欢在这里工作吗？ (3. What do you like about working here?)

Strong answer: I get a lot of satisfaction from the work I do.Strong answer: We have a lot of fun at work.Strong answer: I love working with really smart, friendly co-workers.Strong answer: Management respects engineering.

有力的回答：我对自己的工作感到非常满意。有力的回答：我们在工作中有很多乐趣。有力的回答：我喜欢和真正聪明，友好的同事一起工作。有力的回答：管理层尊重工程学。

The more good answers the better. I don’t have to get all the answers above to give high marks to the company. Keep in mind that some people are not naturally “gushy”, so you may not get stellar responses here, and that might be just fine.

答案越好越好。我不必获得上述所有答案即可给公司打分。请记住，有些人不是天生的“狡猾”，所以您在这里可能不会得到出色的回应，这可能就好了。

But if I hear the following kinds of answers, and very few from the strong answer list, I get nervous:

但是，如果我听到以下几种答案，而从强力答案列表中却很少听到，我会感到紧张：

Weak answer: It pays the bills.Weak answer: I don’t have to work very hard.Weak answer: There is not a lot of pressure to deliver.Weak answer: It doesn’t matter if I make big mistakes.Weak answer: (silence)

弱答案：付账单弱答案：我不必努力工作弱答案：交付压力不大弱答案：犯大错都没关系弱答案： (安静)

Don’t think I am making those answers up. I’ve actually heard those in real interviews.

不要以为我在回答这些问题。我实际上是在真实采访中听到的。

I don’t automatically consider it a bad company if I hear those weak answers, but if those are the only answers, I usually look elsewhere.

如果我听见那些较弱的答案，我不会自动认为这是一个糟糕的公司，但如果只有这些答案，我通常会去找别的地方。

4.您编写单元测试吗？ (4. Do you write unit tests?)

Be careful when making conclusions about an engineering team based on their unit testing practices. If a team gets excited when I ask about unit testing, it’s generally a good sign. Though on the other hand, if they can’t explain why they unit test, or the drawbacks of unit testing, this can be an indication of blind sheep dogma. If they provide bad excuses for why they don’t write tests, especially excuses like “we don’t have time”, that is a bad sign for me.

根据单元测试实践得出有关工程团队的结论时要小心。如果当我询问单元测试时，一个团队感到兴奋，那通常是一个好兆头。但是，另一方面，如果他们无法解释为什么进行单元测试或单元测试的弊端，则可能是盲羊教条的征兆。如果他们为为什么不编写测试提供了不好的借口，特别是诸如“我们没有时间”之类的借口，那对我来说是一个不好的信号。

If the engineers tell me they write unit tests, and they are able to tell me metrics about their tests, such as how long they take to run, how many tests they have, and their code coverage, that is pretty attractive to me. It tells me that they have good tools, and they know how to use them. On the other hand, if they believe that 100% code coverage ensures a bug-free code base, I am leery.

如果工程师告诉我他们编写单元测试，并且能够告诉我有关测试的度量标准，例如运行时间，测试数量和代码覆盖范围，那么这对我来说很有吸引力。它告诉我他们有很好的工具，而且他们知道如何使用它们。另一方面，如果他们相信100％的代码覆盖率可以确保没有错误的代码库，那么我会持怀疑态度。

I want to know beforehand if I will be working on a large, old, untested codebase at this company. This will help me manage my own expectations and decide if that’s something I want to do.

我想事先知道我是否将在这家公司上使用大型的，未经测试的旧代码库。这将帮助我管理自己的期望并决定是否要这样做。

Follow-up questions:

后续问题：

Do you prefer unit tests or integration tests?
您喜欢单元测试还是集成测试？
Do you have acceptance tests?
你有验收测试吗？
What testing framework(s) do you use? Do you like it?
您使用什么测试框架？你喜欢它吗？
How long do your unit tests take to run?
您的单元测试需要运行多长时间？

5.您是否有持续的整合？ (5. Do you have continuous integration?)

The best software development teams I know use tools like Jenkins, Travis, and Buildbot. If the team has no continuous integration, I try to gauge whether they are familiar with the concept. If they aren’t, this is a bad sign in my experience. Having a continuous integration system means that the team probably believes in automation, which is usually a very good sign in my experience.

我认识的最好的软件开发团队使用的工具包括Jenkins，Travis和Buildbot。如果团队没有持续的整合，我将尝试评估他们是否熟悉该概念。如果不是，这对我的经验来说是一个不好的信号。拥有一个持续集成系统意味着团队可能会相信自动化，这通常是我经验的一个很好的信号。

For some teams, this naturally leads to a discussion about continuous delivery, which is a related but different concept from continuous integration. If it’s a web developer position, I expect the team to at least have heard about CD, and strong teams tend to put it in place, at least in part.

对于某些团队而言，这自然引发了有关持续交付的讨论，这是与持续集成相关但又不同的概念。如果这是Web开发人员的职位，我希望团队至少听说过CD，而强大的团队则倾向于将其至少部分应用到位。

Follow-up questions:

后续问题：

When CI reports a failure, how long does your team take to get it fixed?
当CI报告失败时，您的团队需要多长时间才能解决该问题？
What do you like/dislike about your CI system?
您对您的CI系统有何喜好？
How long do your CI runs take? Are you making them faster?
您的CI运行需要多长时间？您要使它们更快吗？

6.您测量什么？ (6. What do you measure?)

This is an open-ended question meant to find out if the team has put effort into measuring their software. For web development teams, the answers tend to focus on performance metrics like server response times, request throughput, number of users, client-side responsiveness, etc. But the discussion can go to things like number of users who speak different languages, browser breakdown, cache hit/miss rates, and myriad other topics. If the team hasn’t taken the time to measure, it can be an indicator that they don’t use real data to inform their decisions. They may be premature optimizers. I value a team that uses real, measured data to make decisions, especially about performance, but it applies to so many other things.

这是一个开放式问题，旨在了解团队是否已在评估软件方面做出了努力。对于Web开发团队，答案往往集中在性能指标上，例如服务器响应时间，请求吞吐量，用户数量，客户端响应能力等。但是讨论可以涉及诸如讲不同语言的用户数量，浏览器故障等问题。，缓存的命中率/未命中率，以及其他许多主题。如果团队没有花时间进行评估，则可能表明他们没有使用真实数据来指导决策。他们可能是过早的优化器。我重视使用实际的，可测量的数据来做出决策(尤其是关于绩效)的团队，但它也适用于许多其他方面。

If the interviewer knows answers to many of these questions, it’s a good sign that the team is high quality. If they have no idea why they would even care about any of these measurements, it could be a negative indicator.

如果面试官知道许多这些问题的答案，则说明团队素质很高。如果他们不知道为什么他们甚至会关心这些测量中的任何一个，那么它可能是一个负面指标。

Again, the rule about dogma applies here. If the team seems to have latched onto a metric that doesn’t necessarily yield valuable, actionable information, and they can’t explain this to your satisfaction, this may be a warning sign.

同样，关于教条的规则在这里适用。如果团队似乎采用了不一定能产生有价值的可操作信息的度量标准，并且他们无法满意地解释这一点，那么这可能是一个警告信号。

Follow-up questions:

后续问题：

What are your most important product metrics?
您最重要的产品指标是什么？
What measurement systems do you use? (e.g., MixPanel, statsd, etc.)
您使用什么测量系统？ (例如MixPanel ， statsd等)

7.您如何查找和修复错误？ (7. How do you find and fix bugs?)

A strong team usually has dedicated testers, and the team’s developers focus on quality. A really strong team has impressive test automation. Some teams are too small for dedicated testers or test automation, but that doesn’t necessarily mean they are a bad team. When I ask this question, I’m trying to get a feel for their process. Is their hair always on fire? Do they have a sane process for finding and prioritizing bugs? Do they rely on users to find bugs?

一个强大的团队通常拥有专门的测试人员，而团队的开发人员则注重质量。一个真正强大的团队拥有令人印象深刻的测试自动化。对于专业的测试人员或测试自动化而言，有些团队规模太小，但这并不一定意味着他们是一个糟糕的团队。当我问这个问题时，我试图了解他们的过程。他们的头发总是着火吗？他们是否有合理的流程来查找错误并对其进行优先排序？他们是否依靠用户来发现错误？

Follow-up questions:

后续问题：

How do you prioritize bugs?
您如何确定错误的优先级？
What bug tracker do you use? (and what do you hate about it)
您使用什么错误追踪器？ (以及您对此有何讨厌)
Do you use Excel to track bugs? (nooo!)
您是否使用Excel来跟踪错误？ (不！)
How many bugs do you have in your bug tracker?
您的错误跟踪器中有多少个错误？
How long do your bugs take to fix (min/max/typical)?
您的错误修复需要多长时间(最小/最大/典型)？

8.您使用什么协作工具？ (8. What collaboration tools do you use?)

In my experience, high functioning teams use lots of collaboration tools. They often use chat services (Slack, IRC, HipChat, Jabber), code review services (Gerrit, GitHub, GitLab, Review Board), and of course, the venerable-but-showing-its-age Email. I am looking for indicators that each developer knows what the other developers are doing. I’m not looking for insane levels of detail, but more for a general awareness. Also, I like to see integrations with collaboration tools. The simplest example is an automatic email sent any time there’s an automated build failure. Another example for web-dev teams is automated error logging services that notify the team’s chat room when serious errors occur, or when key metrics cross a certain threshold.

以我的经验，功能强大的团队会使用许多协作工具。他们经常使用聊天服务(Slack，IRC，HipChat，Jabber)，代码审阅服务(Gerrit，GitHub，GitLab，审阅委员会)，当然，还有古老但显示年龄的电子邮件。我正在寻找每个开发人员都知道其他开发人员正在做什么的指标。我不是在寻找疯狂的细节，而是在寻求一般的了解。另外，我希望看到与协作工具的集成。最简单的示例是在自动构建失败时发送的自动电子邮件。 Web开发团队的另一个示例是自动错误日志记录服务，当发生严重错误或关键指标超过特定阈值时，该服务会通知团队的聊天室。

9.您使用什么框架？ (9. What frameworks do you use?)

My personal preference with frameworks is two fold:

我个人对框架的偏爱有两个：

I like modern stuff.
我喜欢现代的东西。
I like new-to-me stuff.
我喜欢新手入门。

So if a team is building an AIX desktop application in Motif, I am probably not interested. But maybe you are. This is a deeply personal topic, and you should approach it with a solid understanding of your own preferences.

因此，如果一个团队正在Motif中构建AIX桌面应用程序，那么我可能不感兴趣。但是也许你是。这是一个非常个人化的话题，您应该对自己的喜好有深刻的了解。

Regardless of your framework preferences, it’s important to understand why the team has chosen their framework(s). Are they hype-driven? Do they change frameworks like their underwear? Is their codebase littered with shrapnel from framework-of-the-month churn? Are they stuck on an ancient version?

无论您对框架的偏好如何，了解团队为何选择他们的框架都是很重要的。他们是炒作吗？他们会像内衣一样改变框架吗？他们的代码库是否充满了月度框架混乱的碎片？他们停留在古老的版本上吗？

On the topic of why, I like to understand how much latitude developers have in choosing technologies. Does management mandate technology choice? Does management defer to developers? To get to the bottom of these questions, I usually ask, “How did you come to use framework X in your project?”. If developers don’t know the answer, that might be a bad sign, or it may mean they are just new enough to the company that they weren’t around for the decision.

关于为什么的主题，我想了解开发人员在选择技术时有多少自由度。管理是否要求技术选择？管理是否服从于开发人员？为了深入探究这些问题，我通常会问：“您是如何在项目中使用框架X的？”。如果开发人员不知道答案，那可能是一个不好的信号，或者可能意味着他们对公司来说还很陌生，以至于无法做出决定。

I like to see teams make contributions to open source projects they use. This tells me they are not only able to use open source code, but they are proficient enough to contribute to it as well. These are the kinds of developers I like to work with. If the company is willing to pay them to do this, even better. That tells me the company understands what it means to be an open source citizen.

我喜欢看到团队为他们使用的开源项目做出贡献。这告诉我他们不仅能够使用开源代码，而且他们也足够熟练地对此做出贡献。这些是我喜欢与之合作的开发人员。如果公司愿意付钱给他们，那就更好了。这告诉我公司了解成为开源公民的意义。

If the team is reinventing the wheel rather than using readily available tools to help them build their product, I get nervous. There are exceptions to this rule. For example, when Facebook was working on their own framework, I wouldn’t have held it against them (or would I).

如果团队重新设计轮子而不是使用现成的工具来帮助他们构建产品，我会感到紧张。此规则有例外。例如，当Facebook 在他们自己的框架上工作时，我不会反对它(或者我会反对)。

10.我们什么时候可以配对？ (10. When can we pair?)

If you want to get a really clear picture of what it’s like to work with this team, then try actually working with them. I’ve never personally done this, but I have a friend who has (a likely story, right). I think it’s a fantastic idea. If you want to learn almost anything about the team, go work with them for a half day. It might require you to sign an NDA. If the team is even willing to consider this idea, I think it’s a very good sign.

如果您想清楚了解与该团队合作的感觉，请尝试与他们实际合作。我从来没有亲自做过，但是我有一个朋友(有可能是这样)。我认为这是一个很棒的主意。如果您想了解有关团队的几乎所有知识，请与他们一起工作半天。可能需要您签署保密协议。如果团队甚至愿意考虑这个想法，我认为这是一个很好的信号。

You will probably have to arrange this with someone from management, so this question is more designed to get a reaction from the developers. They may be so appalled by the idea that it’s not worth bringing up with management.

您可能需要与管理层中的某人安排此问题，因此，该问题的设计目的是使开发人员做出React。他们可能对这样的想法感到震惊，以至于不值得与管理团队讨论。

11.下一个截止日期是什么时候？ (11. When is your next deadline?)

(contributed by Evan Farrer)

(由Evan Farrer提供 )

This question is designed to tell you more about the development process the company actually follows. This question, alone, is not very informative, but when you add these questions, things get much more interesting:

该问题旨在告诉您有关公司实际遵循的开发过程的更多信息。这个问题本身并不能提供很多信息，但是当您添加这些问题时，事情会变得更加有趣：

Who set this deadline?
谁设定这个截止日期？
Did you meet your last deadline? If not, why not?
你到最后期限了吗？如果没有，为什么不呢？

High quality teams agree on and commit to deadlines together. Deadlines that are handed down arbitrarily can be a sign of dysfunction, or at least that engineers don’t have a seat at the table when determining schedule.

高素质的团队同意并共同承诺最后期限。随意交出的最后期限可能是功能失调的迹象，或者至少是工程师在确定时间表时没有席位。

12.建立新的开发环境需要多长时间？ (12. How long does it take to set up a new development environment?)

(Contribute by Evan Farrer)

(由Evan Farrer提供 )

This question serves to help gauge how much effort the company has put into developer experience. Does it take hours, days, or weeks for new developers to have their computer set up and ready to start coding? Is it automated or manual? This will tell you how proficient the team is at “supporting activities” that aren’t directly related to writing software, but that help support it. Does the team take this seriously?

这个问题有助于评估公司在开发人员体验方面付出了多少努力。新开发人员是否需要花费数小时，数天或数周的时间来设置计算机并准备开始编码？是自动还是手动？这将告诉您团队在“支持活动”方面的熟练程度，这些活动与编写软件没有直接关系，但却可以为软件提供支持。团队会认真对待吗？

Some companies pride themselves on having a dev setup process that is so fast that new developers can put code into production on day 1. This shows that the company takes providing a frictionless experience for developers pretty serious.

一些公司以开发设置过程如此之快而自豪，以至于新开发人员可以在第一天就将代码投入生产。这表明该公司为认真的开发人员提供了无摩擦的体验。

给工程经理的问题 (Questions for Engineering Managers)

1.您上一次编写代码是什么时候？ (1. When was the last time you wrote code?)

I like managers with a strong technical background. No offense to my MBA friends, but I’ve found the managers I really like are those who have done what I do.

我喜欢具有强大技术背景的经理。对我的MBA朋友们没有冒犯，但我发现我真正喜欢的管理人员是那些干我干的人。

2.您是如何成为经理的？ (2. How did you become a manager?)

I like managers who chose to become a manager because they truly enjoy it and have a knack for it, rather than being forced into it. I also like it when managers seem to be focused on serving their team. My favorite managers are those who focus on making life better for their team, rather than “managing up”. They see themselves as a helper and protector for their team. They have an attitude of service, and they consider their most important job to make their team members’ work lives better.

我喜欢那些选择成为经理的经理，因为他们真正喜欢它并有一个诀窍，而不是被迫加入其中。当经理似乎专注于为团队服务时，我也喜欢它。我最喜欢的经理是那些致力于为团队改善生活而不是“精打细算”的经理。他们将自己视为团队的帮助者和保护者。他们有服务态度，并且认为他们最重要的工作是使团队成员的工作生活更好。

3.您的工程师如何知道每天要做什么？ (3. How do your engineers know what to work on each day?)

Since I ask the engineers this same question, I like to compare the manager’s answer to see if they match. If they don’t match, it can mean there’s dysfunction. The worst kind of dysfunction is unrecognized dysfunction. I believe it’s the manager’s job to identify disparity like this and fix it.

由于我向工程师提出了同样的问题，因此我想比较经理的答案以查看它们是否匹配。如果它们不匹配，则意味着存在功能障碍。最严重的功能障碍是无法识别的功能障碍。我认为识别并解决这种差异是经理的工作。

4.您的团队目前最大的挑战是什么？ (4. What is your team’s biggest challenge right now?)

They usually answer that it’s a shortage of staff. Because this is a common and obvious answer (they are hiring after all), I like to ask for their second biggest challenge. I’m looking for red flags like slipping schedules, product quality problems, and interpersonal drama. You’ll know the red flags when you see them. Every team has problems, so the answers you get will depend on several factors:

他们通常回答这是人员短缺。因为这是一个常见且显而易见的答案(毕竟他们正在招聘)，所以我想提出他们的第二大挑战。我正在寻找延误时间表，产品质量问题和人际交往的危险信号。看到红色标记后，您就会知道它们。每个团队都有问题，因此您获得的答案将取决于几个因素：

The manager’s awareness of problems
经理对问题的认识
The manager’s willingness to be honest with you
经理愿意与您诚实
The seriousness of the problems on the team
团队中问题的严重性

5.您如何衡量个人表现？ (5. How do you measure individual performance?)

A skilled manager will have a good technique for doing this. The best managers will carefully gather feedback from the whole team when assessing an individual team member’s performance. A bad manager will make a call based on their own observations, without consulting the team.

熟练的经理将具有执行此任务的良好技术。最好的管理人员在评估单个团队成员的绩效时会仔细收集整个团队的反馈。糟糕的经理将根据自己的观察结果打电话，而不咨询团队。

6.您是否进行正式的绩效评估？ (6. Do you do formal performance reviews?)

I like to work for managers who value giving feedback and helping their team members improve. Performance reviews can be painful or positive experiences. Based on my own observations, I think most people consider them painful. A really great manager will know this, and will have taken measures to make performance reviews great in some way that leaves you impressed and want to work for them.

我喜欢为重视反馈和帮助团队成员进步的经理工作。绩效评估可以是痛苦的，也可以是积极的经历。根据我自己的观察，我认为大多数人都认为它们很痛苦。一位真正出色的经理会知道这一点，并将采取措施使绩效评估达到某种程度，从而给您留下深刻的印象，并希望为他们工作。

Follow-up questions:

后续问题：

Can you tell me about a time you helped someone improve their performance?
您能告诉我您帮助某人改善绩效的时间吗？
How do you coach people during these reviews?
您如何在这些评论中指导人们？

7.您是否增加年薪？ (7. Do you do annual salary increases?)

I like to know that my compensation will be adjusted to match my contribution to the company, and that we’ll take an official look at it at least once a year. For companies where it applies, I like to ask about equity. Will you give me stock options? Will you give me more stock options every year?

我想知道我的薪酬将根据我对公司的贡献进行调整，并且我们每年至少会正式审查一次。对于适用的公司，我想问一下股权。你能给我股票期权吗？每年您会给我更多的股票期权吗？

Some engineers are uncomfortable asking financial questions like this. Don’t be. Engineers generally spend a very small percentage of their time thinking about these topics, but managers have these conversations all the time. These questions should not be uncomfortable for a manager:

一些工程师不喜欢这样的财务问题。不用了工程师通常花费约这些话题他们的时间去思考的一个很小的比例，但经理们这些谈话所有的时间 。这些问题对于经理人来说应该不会感到不舒服：

How do you budget for raises?
您如何预算加薪？
What was last year’s median raise on your team (in percent)?
去年您的团队的平均加薪幅度(百分比)是多少？
How much salary increase could I expect one year from now? Best case, worst case?
我希望从现在开始一年后可以增加多少薪水？最好的情况，最坏的情况？

I don’t ask these questions as a signed-in-blood contract or guarantee of future raises. Instead, I want to understand how the company operates. Will I have to go out of my way to ask for raises, or is there a standard process already in place?

我不会以签定合同或保证未来加薪的方式提出这些问题。相反，我想了解公司的运作方式。我是否必须全力以赴要求加薪，还是已经建立了标准流程？

8.我可以获得一些描述公司收益的实物资料吗？ (8. Can I get some take-home material describing company benefits?)

(Contributed by Evan Farrer)

(由Evan Farrer提供 )

I figure most people already know to ask this, but it’s worth mentioning for the sake of completeness. Most companies are prepared to give you a bunch of paper, or a web site, that describes the company benefits. It’s important to know, because it’s often a pretty big part of your compensation. This might only apply in the USA. I’m not certain how company-provided medical insurance incentives work in other countries.

我认为大多数人已经知道要问这个问题，但是出于完整性考虑，值得一提。大多数公司都准备为您提供一堆描述公司收益的文件或网站。重要的是要知道，因为这通常是您薪酬的很大一部分。这可能仅适用于美国。我不确定公司提供的医疗保险激励措施在其他国家/地区如何运作。

9.您是否将员工排名相对？ (9. Do you rank employees against one another?)

(Contributed by Matt Ryan )

(由Matt Ryan贡献)

Some companies determine raises and bonuses (I’m not making this up) by ranking every employee in a big sorted list, from best to worst, and then forcing a certain percentage of employees into “good”, “average”, and “bad” sub-lists.

一些公司通过按从大到小的顺序对每位员工进行排名来确定加薪和奖金(我没有做)，然后将一定比例的员工强迫为“好”，“平均”和“差” ”子列表。

I’ve never met an engineer who likes this. This is particularly common among big companies. It can influence how you interact with your peers, because you know that one day you will have to compete with them for money.

我从未见过像这样的工程师。这在大公司中尤为常见。它会影响您与同行的互动方式，因为您知道有一天您将不得不与他们竞争金钱。

When I encounter this, it might not immediately mean the company is a terrible place to work. There are often small pockets of awesomeness flying under the radar” in companies like this. Ask the interviewers how they like the system. Some managers will be quite candid about their dislike for the system, and some will even tell you about strategies they use to “game” the system for the benefit of their team. If you find this kind of manager, you might be able to overlook the ranking system.

当我遇到这个问题时，这可能并不立即意味着该公司是一个糟糕的工作场所。在像这样的公司中，常常有很多很棒的东西在雷达下飞扬。询问面试官他们对系统的喜欢程度。有些经理对他们对系统的不满意会坦诚相告，有些经理甚至会告诉您他们为了团队利益而“游戏”系统的策略。如果您找到这类经理，则可能会忽略排名系统。

Keep in mind, also, that not everyone hates this system. Just because I haven’t met someone who likes it doesn’t mean they don’t exist.

同样要记住，并非每个人都讨厌这个系统。仅仅因为我没有遇到喜欢的人，并不意味着他们不存在。

Follow up questions:

后续问题：

Do you really think X % of your employees are “bad”? What does that say about your hiring process? (this is a bold question — tread cautiously)
您是否真的认为X％的员工是“坏人”？那对您的录用过程有何影响？ (这是一个大胆的问题，请谨慎行事)
Do you apply some kind of curve to determine top performers?
您是否采用某种曲线来确定表现最好的人？
What metrics do you use to rank the employees?
您使用什么指标对员工进行排名？
How do you know these metrics are collected accurately?
您如何知道这些指标是准确收集的？
How do you know these metrics actually identify top performers?
您如何知道这些指标实际上可以识别出表现最佳的人？

For more info, here is a good analysis of this from Matt Ryan.

有关更多信息，这是Matt Ryan对此的很好分析。

10.您是否定期进行团队回顾？ (10. Do you do regular team retrospectives?)

(Contributed by Aric Parkinson)

(由Aric Parkinson提供 )

If so, what are they like? How often do you receive feedback from members of your team? When was the last time you changed something about the way you run your team based on feedback you received?

如果是这样，他们是什么样的人？您多久收到一次团队成员的反馈？您上次基于收到的反馈更改团队运行方式的时间是什么时候？

These questions will give you a feel for how responsive you can expect management to be, and whether the team contributes much feedback to management.

这些问题会让您感觉到您对管理层的期望有多高，以及团队是否对管理层做出了很多反馈。

If retrospectives aren’t happening, it’s difficult for a team to identify problems, let alone shift gears to correct for them. And if a manager doesn’t feel like they receive feedback for how the team could be going better, then they are probably either tone deaf to the issues of the team, or building an atmosphere where people don’t feel safe to speak up with problems.

如果没有进行回顾，那么团队很难发现问题，更不用说换档了。而且，如果经理不希望他们收到有关团队如何做得更好的反馈，那么他们要么对团队的问题充耳不闻，要么营造一种人们不敢与他们交谈的氛围问题。

领导力问题 (Questions for Leadership)

I don’t always get to talk to the company’s senior leadership, especially for larger companies, but when I do, I take it as an opportunity to assess the company’s financial viability. I’m not really qualified to do this, but there are some obvious problems that I can sometimes discover in an interview. Also, I like to know what the top-down culture is like, because this information can tell me how the company values its engineers, both positively and negatively.

我并非总是与公司的高层领导交谈，特别是对于大型公司，但是当我这样做时，我将其作为评估公司财务生存能力的机会。我没有资格这样做，但是有时候我会在采访中发现一些明显的问题。另外，我想知道自上而下的文化是什么样的，因为这些信息可以告诉我公司对工程师的正面和负面评价。

1.您如何获得资金？ (1. How are you funded?)

I’m trying to gain insight into the money behind the company. If they are funded by venture capital, private equity, public stock, or self funded via revenue, I want to know it. Often I can figure this out before the interview pretty easily, but company leadership will often add insights that I can’t find via Google or CrunchBase.

我试图了解公司背后的资金。如果它们是由风险资本，私募股权，公开股票或通过收入自筹资金来资助的，我想知道。通常，我可以在面试之前很容易地弄清楚这一点，但是公司领导层通常会添加一些我无法通过Google或CrunchBase找到的见解。

2.您盈利吗？ (2. Are you profitable?)

If profitable, great! If not profitable, what’s your plan for becoming profitable? Some startups have a plan for this, while others are looking for an exit via acquisition or IPO.

如果盈利，那就太好了！如果无法盈利，您打算如何盈利？一些初创公司对此有一个计划，而另一些则通过收购或IPO寻求退出。

Follow-up topics:

后续主题：

Historical revenue for the past few quarters/years. Is it trending upward?
过去几个季度/年的历史收入。它有上升趋势吗？
Risks to profitability like competition, surprise expenses, and surprise revenue shortfalls.
盈利风险，例如竞争，意外支出和意外收入不足。
Runway: How long could the company operate before raising more capital.
跑道：公司可以筹集多长时间才能筹集更多资金。

3.您对外包有何看法？ (3. What is your opinion on outsourcing?)

I want to know if the job I’m applying for is likely to get outsourced in the future, or if the job could turn into a position managing outsourced engineers.

我想知道我申请的工作将来是否有可能被外包，或者该工作是否可以转为管理外包工程师的职位。

I’m not just talking about offshore outsourcing here. This includes contractors as well.

我在这里不仅仅是在谈论离岸外包。这也包括承包商。

4.告诉我有关公司文化的信息。 (4. Tell me about the company culture.)

This is another question I use to reconcile the engineers’ perspective against leadership’s perspective. I’m looking for discrepancies as a sign of dysfunction. If leadership and engineering are on the same page, that indicates good top-to-bottom communication. I want to know if senior leadership is out of touch with the in-the-trenches employees. I also want to see if the leadership has solid vision that is well communicated. My favorite companies to work for have a strong, shared vision.

这是我用来调和工程师的观点和领导者的观点的另一个问题。我正在寻找功能障碍的迹象。如果领导力和工程技术在同一个页面上，则表明自上而下的良好沟通。我想知道高级领导层是否与在职员工保持联系。我还想看看领导层是否有良好的愿景，可以很好地沟通。我最喜欢工作的公司有着强烈的共同愿景。

Some companies take culture very seriously, and this can be a good thing. At least you’ll be clear on what the company values. For other companies, you’ll have to suss it out through implicit, sometimes unspoken nuances. Culture can be very important. Is there political infighting? Is professionalism valued? Is honesty valued? Is overtime valued?

一些公司非常重视文化，这可能是一件好事。至少您会清楚公司的价值。对于其他公司，您将不得不通过隐含的，有时是不言而喻的细微差别来解决它。文化可能非常重要。有政治上的内斗吗？专业精神受到重视吗？诚实受到重视吗？加班是否有价值？

5.您对这家公司成功有什么保证？ (5. What assurance do you have that this company will be successful?)

With this question I’m looking for real evidence, not just marketing hype. If senior leadership gives me actual numbers, like revenue, market size, and capitalization, that is a good sign. Also, if I can verify this information from other sources, that is an even better sign. On the other hand, the numbers may indicate something very bad, like a one-month runway with no funding on the horizon.

带着这个问题，我正在寻找真正的证据，而不仅仅是营销炒作。如果高层领导给我真实的数字，例如收入，市场规模和资本总额，那是一个好兆头。另外，如果我可以从其他来源验证此信息，那就更好了。另一方面，这些数字可能表明情况非常糟糕，例如一个月的跑道，没有资金投入。

6.告诉我您的报告结构。 (6. Tell me about your reporting structure.)

For me, the best answer to this question is a simple one. If the person can draw a simple org chart that explains the reporting structure, I am satisfied. My personal preference is to work for small, nimble companies with minimal organizational and communication overhead. Your preference may differ, and that’s ok. No matter your preference, this question is designed to give you the information you need to make an informed decision about the company.

对我来说，对这个问题的最佳答案是一个简单的答案。如果该人可以绘制一个简单的组织结构图来解释报告结构，我会感到满意。我个人的喜好是为组织灵活，通讯开销最小的小型敏捷公司工作。您的偏好可能有所不同，没关系。无论您的偏好如何，此问题旨在为您提供做出有关公司的明智决定所需的信息。

结论 (Conclusion)

Interviews are bidirectional. Make sure you get everything out of the experience you need to make an informed decision if you are fortunate enough to get an offer. Good luck!

采访是双向的。如果您足够幸运地获得报价，请确保您从需要做出明智决定的经验中获得一切。祝好运！