面试中判断代码质量的标准
在涉及编码问题的技术面试中，人们使用什么标准来评估代码。假设有多种方法来编码同一问题，可以使用哪些指标来客观地评估和比较答案。 面试通常持续 1 小时，
我使用的一些内容是
- 正确性、
- 简洁性、简洁性、
- 干净设计/API
- 可测试性
- 量表、性能、并发性
，其他人使用什么。这份清单中我缺少什么吗？
During Technical interviews involving coding question what criteria do people use to evaluate code. Assuming there are multiple ways to code the same problem, what metrics can be used to evaluate and compare the answers objectively.
The Interview is typically 1 hour long
Some of the things I use are
- Correctness
- Brevity and Simplicity
- Clean Design / API
- Testability
- Scale, Perf, Concurrancy
What do other people use. Anything I am missing in this list ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于大多数程序员通常使用 IDE 和 API 文档来完成任务，因此我不喜欢专注于语法或实际方法名称的面试（除非它是常识）。
重点应该是了解受访者如何处理和解决问题。理想情况下，他们应该以这样的方式进行测试，以表明他们了解您正在测试他们的原则。
所以我会更多地关注他们正在编写的代码的精神，而不是字母:)（只是我的意见 - 我愿意听到反驳和反意见）。
编辑
要回答您的问题，这实际上取决于您的标准的含义：
正确性 - 这是什么意思？句法？我认为语法不应该是一个太大的问题（除非它看起来非常错误）。也许您可以将正确性限制为方法的正确性。例如，如果他们使用明显错误的算法或方法。
简洁明了 - 在什么情况下？一般的做法是？当然，您可以检查它们是否过于冗长（即解决方案有多优雅）。
干净的设计/API - 我不知道你对此的测试效果如何。在短短 1 小时内想出一个非常干净的设计和 API 太困难了。你可以寻找的是他们是否有正确的想法或者正在朝着正确的方向前进。
可测试性 - 这太宽泛了，你不应该对此太严格。您可以做的是询问他们在设计解决方案后将如何测试解决方案。允许他们做出改变，而不是让他们坚持自己的设计。看看他们如何完成测试或设计测试的任务。当您编写代码并设计某些东西时，这不是一次性的事情。你不断地完善它。
可扩展性、性能和并发性 - 当您谈论设计时不要指定这一点，就像我上面所说的那样，如果他们没有制定出性能不佳的解决方案，请不要惩罚他们或者乍一看规模很好。相反，如果您发现它不可扩展或不能很好地支持并发性（或者即使可以），请询问他们的解决方案将如何执行可扩展性和并发性是一个问题。
您的目标是了解他们如何思考以及如何寻求解决方案。重要的不是他们对 API 或定义的记忆程度。而且，如果仅仅按照自己的标准，很难找到候选人。正如我一开始提到的，程序员不会仅凭自己头脑中的东西孤立地工作。他们依靠多种来源来完成他们想要做的事情。
Since most programmers typically use an IDE and also API documentation to accomplish a task, I dislike interviews that focus on the syntax or the actual method name (unless it is something that is common knowledge).
The focus should be on seeing how the interviewee approaches and solves the problem. Ideally they should do it in such a way that demonstrates that they are knowledgeable about the principles that you are testing them on.
So I would focus more on the spirit of the code they're writing, rather than the letter :) (Just my opinion - I'm open to hearing counterarguments and counter-opinions).
EDIT
To answer your question, it really depends on what you mean by your criteria:
Correctness - What does this mean? Syntax? I don't think syntax should be too much of an issue (unless it appears terrible wrong). Perhaps you can limit correctness to the correctness of the approach. For example, if they use an algorithm or approach that is clearly wrong.
Brevity and Simplicity - In what context? The approach in general? Sure, you can check to see that they are not overly verbose (i.e., how elegant the solution is).
Clean Design/API - I don't know how well you can test this. It's too difficult to come up with a very clean design and API in just 1 hour. What you can look for is whether they have the right idea or are moving in the right direction.
Testability - This is too broad and you shouldn't be too strict about it. What you can do is ask them how they would test their solution after they have designed it. Allow them to make changes and don't hold them to their design. see how they approach the task of testing it or designing tests for it. When you write code and design something it's not a one-time deal. You're constantly refining it.
Scalability, Performance, and Concurrency - Don't specify this when you talk about the design and like I said above, don't penalize them if they don't make a solution that doesn't perform well or scale well at first glance. Instead, if you see that it is not scalable or doesn't support concurrency well (or even if it does) ask them how their solution will perform is scalability and concurrency is a concern.
Your aim is to see how they think and how they approach a solution. It's not how well they've memorized an API or memorized definitions. Also, if you simply went by your criteria alone, it would be very hard to find a candidate. Like I mentioned initially, programmers don't work in isolation only with the stuff they have in their head. They rely on multiple sources to accomplish what they are trying to do.
抱歉说得粗俗，但你的标准太肛门了。你面对的是人类，他们（希望）能够在团队中工作；不优化编译器。因此，Joe 编写了正确的代码，简洁、干净、可测试、可扩展性良好，等等。但是 Joe 是一个迂腐、永远的抱怨者，他每 3 个月洗一次澡，并通过不断地抱怨派生方法来破坏你组织的所有团队晚餐。
明白我的意思吗？
Sorry to be crude, but your criteria are far too anal. You're dealing with human beings, which are (hopefully) going to work in a team; not optimising compilers. So Joe writes correct code, that's brief, clean, testable, scales well, etc. But Joe is a pedantic, eternal whiner, who showers ever 3 months and destroys ever team dinner you organise by ranting incessantly about the derived methods.
See what I mean?