作者：Alistair Doulin

过去我参加过许多场编程测试。我喜欢参加这些活动，因为总是能够看到不同的程序员在设计时会遇到哪些挑战。但不幸的是，这些测试都不是非常棒。下文将列出某些有助于提高程序员测试质量的建议：

Programming passion(from techcareertips.com)

1、保持关联性

许多测试存在的问题是，内容与该职业并不相关。编程测试背后的想法是确保就职者拥有胜任职位的能力。所以，不应该询问你认为“优秀程序员”应该具备的主观问题。并不是说你不应该测试基础知识，因为程序员确实需要了解这些。重点在于，你不能只单纯为了某些概念来进行测试。

C++中的“friends”便是绝佳的例证。几乎每个我参加过的编程测试都会询问此类问题。到现在位置，我的编程经验已经有5年之多，但是我只用过它们两次。第一次是在大学的时候，第二次就是在参加编程测试的时候。我询问过其他一些高级程序员，他们也都没有用过。为什么要询问与他们所要开展的工作无关的问题呢？我知道肯定有些人使用过，但是如果你团队中的多数程序员都从未碰过，那么为什么新程序员需要掌握这些内容呢？如果新程序员确实会使用这些内容的话，有可能带来的好处是在解决相同的问题时提出不同的解决方案。

当然，理想状况是能够雇佣到知道所有编程相关内容的程序员。但是现实情况并非如此。因而，重点在于确保他们所掌握的知识与你所需要的相符。询问不相关的问题不会帮助你找到合适的程序员，只会帮你找到那些深知如何通过编程测试的人。

2、不要询问愚蠢的问题

为何要浪费时间去询问写在纸上的代码编译错误这些问题呢？现在，编译器挑出错误的速度要比人工快得多。测试程序员能够找到这些简单的错误就像是让一位英语教授去寻找拼写错误而不是矫正句子结构。应该让程序员去找出代码中的逻辑错误。让他们根据代码逻辑来寻找问题。

而且，不要向程序员提某些带有花招的问题。花招式的问题需要大量的时间才能找得出来，而当你已经见过这个问题时，你会很迅速地找出来。简单地说，花招式的问题测试的是程序员以前是否被提过这个问题，而不是这个程序员有多棒。

3、在询问优化问题时应当谨慎

编译器和平台的变化非常迅速，尤其是在数年时间内便会出现全新硬件的游戏行业。出于这些原因，你必须在让程序员优化代码时异常谨慎。即便是数年前堪称精湛的优化技术现在可能也已经落伍了。

比如，某些现代CPU（游戏邦注：尤其是主机上的CPU）在执行branches时非常缓慢。使用缓存的查找表格来作常规优化可能不一定是最快的优化方式。更为重要的是，询问优化的普遍概念。

如果他们能够解释出某些最佳的做法，那么这就是你要寻找的人。

如果你的工作并没有明确与优化相关，那么我会提出某些具体的问题。在游戏中，代码优化非常重要，所以这样做是很有必要的。但还是要提醒的是，询问某些更高层次的概念问题，而不是给出具体的代码然后让他们去编写出最快的代码。最棒的求职者可能会说，在未知具体硬件和简况的情况下，他们会选择编写相对简洁的代码而不是他们所认为的优化代码。

4、根据团队的编程来编写测试

如果你对需要在测试中提出的问题举棋不定，那么最实用的方法是冷静下来，查看或与团队成员交谈他们正在执行的任务。询问团队，他们将多数时间花在哪里。随后，你可以根据耗费时间最多的任务来编写测试。

这也能够保持测试的相关性，防止你提出不必要的优化问题。我发现80%的工作时间都在做相似的任务，所以掌握可用于这些任务技能的求职者正是你所需要的雇员。很显然，如果你正在寻找的是特别职位的人选，这种方法可能并不奏效，但是当你寻找的是普通程序员，这样做确实能够提供好处。

5、保持测试的简单化

我发现，许多测试中的问题都过于复杂。你完全能够明白他们要询问的问题，但是他们却使用了大量复杂的例子来提出这个问题，而不是简单地直接提出问题。为何不直接向参加测试的人直接提出问题，而要让他们花数分钟的时间去探索问题呢？

应该复杂的不是问题，而是答案。尽管你要的不只是教科书上的答案，但最好在面试前提供健全复杂的答案。

6、使用面试来判断思考过程

编程测试能够清除出那些根本无法编程的程序员，但是无法体现出程序员在解决问题时的思考过程。尝试通过书面测试来实现这个目标不太实际，应将这个过程留到面试中。

我喜欢询问简单的问题，程序员必须在白板上解决编程问题。这种做法的主要目的在于发现程序员在解决问题中的思考过程。作为程序员，你知道解决问题的正确方法，你会很快判断出该程序员是否明白他们要解决什么问题。而且，你也有可能因为他人提出你从未想到过的有趣解决方案而感到惊奇。无论出于何种情况，他们编写的代码都不重要，重要的是他们解决问题的方式。让他们在解决问题时大声说出他们的想法。你需要考虑的是，这些想法是否会令问题加剧，该程序员是否是团队所需的合适人选。

结论

这些是编写优秀编程测试的简单技巧。我希望能够看到更多能够找到优秀程序员的测试，而不是尝试去寻找某种特殊程序员（游戏邦注：无论该类程序员是好是坏）的常规问题列表。

游戏邦注：本文发稿于2007年8月11日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

How To Write A Good Programming Test

Alistair Doulin

I’ve taken and marked a lot of programming tests in the past. I love doing them as it’s always good to see what challenges different programmers have come up with when designing them. Unfortunately, however, most of them aren’t very good. Below is a list of general ideas to help increase the quality of programmer tests.

1. Keep it relevant

Too many of the tests have questions on content that simply isn’t relevant to the job. The whole idea behind a programming test is making sure the candidate is competent enough to fulfill the role. It shouldn’t be asking questions about arbitrary knowledge that you think ‘good programmers’ should have. That’s not to say that you shouldn’t be testing the basics, as your programmers will need to know these. The important thing is that you don’t test certain concepts just for the sake of it.

A good example of this is “friends” in C++. Nearly every programming test I’ve taken has asked a question about these. I’ve been programming for 5 years now, and I’ve only used them twice. Firstly at university and secondly when taking programming tests. I’ve asked a few other senior programmers and none of them have used them either. Why bother asking a question if it’s not relevant to the work they’ll be doing? I’m sure some people somewhere use them, and if that’s important, ask away, however if most programmers on your team have never touched them, why is it important that new programmers know them? Chances are, if the new programmer does use them, no one else on the team will understand them, or have a different solution to solving the same problem.

Of course, it would be ideal to hire programmers that just know everything there is to know about programming. In reality this isn’t going to be the case. It’s therefore important to make sure their knowledge domain includes exactly what you need. Asking irrelevant questions won’t help you find better programmers, it will help you find people who know how to pass programming tests.

2. Don’t ask stupid questions

Why bother asking questions about simple compile errors in code that is written on paper. These days, compilers will pick this up far quicker than a person can.

Seeing if a programmer can find these simple mistakes is like asking an English professor to find spelling mistakes rather than fixing your sentence structure. Ask programmers to figure out logic errors in code. Get them to follow code logic and determine problems or simple output.

Also, don’t ask programmers trick questions. A lot of the time with trick questions you’ll spend a long time figuring them out, and once you know them, you’ll know instantly. Trick questions generally test whether someone has been asked that question before rather than whether they are a good programmer.

3. Be careful when asking optimization questions

Compilers and platforms are changing extremely quickly. This is particularly true within the games industry where we have entirely new hardware every few years. For these reasons you must be very careful when asking programmers to optimize code. What used to be a smart optimization even a few years ago can often be the slower option now.

For example some modern CPU’s (particularly on consoles) are very slow at executing branches (eg if statements). The simple question of optimizing a routine by using a lookup table that is cached may not necessarily be the fastest optimization anymore. What’s more important is asking people the general concepts of optimization.

If they mention profiling with some explanation of best practices then you’re onto a winner.

If your work isn’t specifically about optimization then I would leave out any specific questions altogether. In games, optimized code is very important, so it’s necessary, but again, ask more high-level concepts rather than giving specific code blocks and asking them to write the fastest code. The best candidate would simply say that without knowing the exact hardware and without profiling they would rather write clean code than what they think would be optimized. Code Complete has an excellent section on optimizing code.

4. Watch your team coding, then write the test

If you’re stuck for questions then a practical hint is to simply sit for a little while and watch or talk to your team about what tasks they are performing. Ask the team what they spend most of their time on. You can then write your test around what they spend most of their time doing.

This will have the added bonus of keeping it relevant and stop you from asking optimization questions if they are not needed. I find that I spend 80% of my job doing fairly similar tasks and capturing what skills are used for these tasks and making sure new employee’s have them will almost guarantee you will find a good candidate. Obviously if you’re looking for a specific role to be filled this won’t work, but when looking for general programmers this will help.

5. KISS (Keep it simple stupid)

I’ve found that too many tests have the problem of being too complex. You know exactly what question they are asking, however they use a large convoluted example to ask the question, rather than simply asking the question itself. Rather than having a large “const” example and having the tester take minutes to figure things out, why not ask them specifically what “const” means.

The questions shouldn’t be complex, the answer should. While you don’t just want textbook answers, it’s better to keep anything complex to an interview. This leads to my final tip.

6. Use the interview for determining thought process

Programming tests are great for weeding out the programmers that just can’t program (and unfortunately there are a lot of them). They aren’t good at finding out the thought processes the programmer has when solving problems. Trying to find this out from a written test just won’t work, leave it for the interview.

I like to ask simple questions where the programmer has to solve a coding problem on a whiteboard. Rather than finding out whether they can write code on paper, give them something that doesn’t use complex code, but that requires a complex design. The main aim of this is to find out the thought processes when solving problems. As a programmer, you’ll know the “right” way to solving the problem and you’ll soon tell if the programmer has no idea what they are doing. You can also be surprised by an interesting solution that you may not have thought of. Either way, don’t be critical of the code they write, but rather of the way they go about solving it.

Tell them to say out loud what they are thinking as they solve the problem. Think about how those thought processes may extend to larger problems and whether you want that type of person on your team.

Conclusion

There are a few simple tips for writing a good programming test. I’d love to see more relevant tests that actually find good programmers rather than the cookie cut list of questions that try and find a specific type of programmer (whether good or not). (Source: Doolwind’s Game Coding Blog)