一个简单的方法是让他们从头开始编写对树的广度优先搜索。是的,如果你知道你在做什么,那是微不足道的。但是很多程序员不知道如何解决它。
我觉得更有用的一个如下。我已经用多种语言给出了这个,这是一个 Perl 版本。首先,我给他们以下代码示例:
# @a and @b are two arrays which are already populated.
my @int;
OUTER: for my $x (@a) {
for my $y (@b) {
if ($x eq $y) {
push @int, $x;
next OUTER;
}
}
}
然后我问他们以下问题。我慢慢地问他们,给人们思考的时间,并愿意给他们轻推:
- 这段代码完成后,@int 中的内容是什么?
- 这段代码投入生产,有性能问题追溯到这段代码。解释潜在的性能问题。(如果他们在苦苦挣扎,我会问如果@a 和@b 各有 100,000 个元素,需要进行多少次比较。我不是在寻找具体的术语,只是粗略估计。)
- 没有代码,建议加快速度。(如果他们提出了一个易于编码的方向,我会要求他们编码。如果他们想到一个解决方案会导致@int 以任何方式(例如,通常的顺序)被更改,我会推动查看他们是否意识到他们不应该在检查是否重要之前编写修复代码。)
如果他们提出了一个稍微(或非常)错误的解决方案,以下愚蠢的数据集将发现您遇到的大多数错误:
@a = qw(
hello
world
hello
goodbye
earthlings
);
@b = qw(
earthlings
say
hello
earthlings
);
我猜大约 2/3 的候选人没有通过这个问题。我还没有遇到过遇到问题的称职程序员。我发现具有良好常识和很少编程背景的人在这方面比具有几年经验的普通程序员做得更好。
我建议将这些问题用作过滤器。不要雇用某人,因为他们可以回答这些问题。但如果他们不能回答这些问题,那就不要雇用他们。