pmp访谈法和焦点小组区别_时间，空间和访谈

pmp访谈法和焦点小组区别

像大多数软件公司一样，Microsoft几乎所有的技术面试都涉及某种编码问题。 在那期间，我遇到了许多不同的问题。 它们通常都具有您可以很好地讨论一般问题空间，设计解决方案和权衡因素的特征，但是只需要编写少量代码，并且代码也不会过于棘手。

一些访调员喜欢深入研究特定技术的神秘细节，但我认为这些类型的问题不太有用。 尤其如此，因为我的面试绝大多数是大学应聘者，在这些人中很难指望特定技术的深厚背景。 这些面试的一种特殊形式是半小时的校园面试。 这些特别困难，因为面试的编码部分只有10到15分钟，而且您不想花很多时间与应聘者一起努力入门或理解问题。 您还希望它足够丰富，如果候选人很快就可以进行深入的讨论。

我想问的问题是“编写一个函数，以从未排序的整数数组中删除重复项”。 该问题易于陈述和理解，因此您不必花费大量时间进行设置。

在寻求可能的解决方案之前，我要问的第一个后续问题是该问题是否确实如我最初指出的那样明确。 关于该问题的特征及其运行环境，我想问什么问题来指导实施选择？ 在这里，您甚至可以在候选人尝试将任何一种算法融合在一起之前，就可以开始了解该候选人具有什么样的经验和背景。

整数有多大？ 对于8位整数和64位整数，我可能会使用非常不同的算法。 数组有多大？ 如果数组很大，使用辅助数据结构的方法可能会变得非常昂贵。 我对整数的分布一无所知吗？ 也就是说，即使将值存储在64位整数中，实际值是否也会在较小范围内聚集？ 我对唯一值的预期数量一无所知吗？ 即使原始数组很大，少数唯一值也可能会影响某些算法的选择和有效性。 我可以使用额外的存储空间吗？ 在使用其他存储（与输入成比例的存储）有问题的情况下，可以使用该功能。 我需要保持唯一值的原始顺序还是可以使用对它们进行重新排序的方法？

该功能将如何使用？ 它会成为函数库的一部分吗，因此我不能对它的使用方式做出很多假设？ 它只是应用程序中数百种小型算法中的一种，因此清晰和简单是最重要的吗？ 还是决定应用程序整体性能的核心算法（也许这是实时数据管道的一部分）？

给定的候选人可能仅会识别出其中一些因素，而随着我在此过程中给出一些提示，候选人在探索这些因素如何影响可能的解决方案方面会有很大差异。

当我们真正探索算法时，您会开始了解应聘者有多少实际编码经验。 有些人建议仔细检查并从数组中“删除”元素，而无需意识到他们刚刚描述了潜在的O（N²）算法。 其他人则谈论在数组中为已删除的元素放置“前哨”值（没有很好的意识，为什么这将是一个有用的中间步骤，或者该概念是否可能以他们选择的语言存在）。

多数体面的候选人最终将获得以下基本框架的解决方案（使用伪代码，就可以了）：

function RemoveDups(a: array of integer): integer
{
  integer unique_index = 0;
  integer current_index = 0;

  for (; current_index < a.length; current_index++)
    if ( is_unique (a[current_index]))
    {
      remember (a[current_index]);
      a[unique_index++] = a[current_index];
    }

  return unique_index;
}

也就是说，遍历数组并将唯一元素复制到数组的前面，返回找到的唯一元素的数量。

然后，技巧就变成了如何确定元素是否唯一。 在学校教授的几乎所有语言中，丰富的基础类库的兴起意味着许多候选人将跳到使用set类来记录和测试唯一整数。 对我而言，这很好，但是随后我尝试探究他们是否了解其含义，特别是在内存使用方面。 这就是大多数候选人确信的地方，因为他们已经编写了线性算法，无法对其进行改进，但是不幸的是，这表明对常量因子开销和大量内存使用的影响知之甚少。

我还会向他们询问不使用额外存储的方法。 一些候选人也会想出先对数组进行排序的想法，将问题简化为“更简单地从排序后的数组中删除重复项”，就像上面所说的那样，只有一些谨慎的结束条件。 另外，他们可以只使用在数组前面收集的一组唯一元素来测试唯一性（最坏情况为O（N²））。

我从一次校园旅行中回来，经历了大约30场访谈，并希望我有更多具体的数据可用于讨论中。 因此，我坐下来，决定编写几种不同的方法，然后逐步进行比较，并将运行时间和内存使用情况与许多不同的输入测试方案进行比较。

C ++代码位于github上 。 我测试了许多不同的实现。 第一个基准案例只是检查并触摸数组中的每个元素，以了解“ O（N）”的真正含义。 下一个版本首先对数组进行排序（使用标准的qsort实现），然后逐步压缩出重复的元素。 下一个版本是名义上的O（N²）算法，该算法通过遍历到目前为止已发现并移至数组开头的一组唯一条目来测试唯一性。 确实不是O（N²），而是O（N * U）。 下一个版本是我编写的trie实现，如果值是集群的，则提供了有效的set实现。 最终版本仅使用Visual Studio C ++附带的std::unordered_set实现。

我发现结果有趣而令人惊讶。 实际上，如何测试代码可能需要更详细地考虑实际的实现方式（实际上并不太常见）。 我的测试着眼于输入数组大小从2⁴到2²²的范围，然后考察相同范围内唯一值数量的分布。 然后，可以将唯一值聚类在一起，也可以将其随机分布在整个整数范围内。

• 排序结果确保输入大小看起来呈线性。
• 根据重复项的数量，排序速度可以改变4倍。 用大量重复项对数组进行排序要快得多（大概是因为可以省去排序过程的最后阶段）。
• 但是排序比基线线性游走慢25–90倍。 也就是说，排序方法的速度与输入大小成线性关系，但比简单的线性遍历数据要慢得多。
• 我朴素的trie实现在所有方面都击败了std::unordered_set实现，直到set中的唯一元素数量达到2或更大。 这让我有些惊讶。 对于群集值（即使具有大量唯一值），在内存大小和速度（显然相关的问题）方面， trie也比set实现好得多。
• Trie具有更好的内存性能比std::unordered_set的集群价值和仅约2更糟的非集群值的次数（例如trie马克塞斯在356MB，同时集马克塞斯在146MB的辅助数据结构）。
• 如果有16个或更少的唯一值（对于任何大小的输入数组），则O（N²）算法会击败所有其他算法，并且一路领先于多达256个唯一元素的排序方法。 借助L1缓存中的那些独特元素，线性游走仍然非常快。 然后，随着唯一元素数量的增加（如预期的那样），它比任何其他算法都要慢得多。

当存在大量唯一值时，很难真正理解由set和trie实现分配的大型辅助数据结构对整体性能的影响。 随着唯一元素的数量变得非常大（对于trie ，仅当它们随机分布而不是聚集时），结果变慢（在5-10倍之间），但是总时间可靠地保持了比所需的排序方法更快的速度没有其他分配。 众所周知，在由许多组件组成的任何真正复杂的软件中，很难理解系统中一个组件使用额外内存的总体影响。 这就是为什么只专注于特定性能场景的结果通常导致开发人员决定将一些额外的缓存层作为解决方案的原因之一，即使这总的来说会导致过大的内存使用，总体上有害无济于事。 对于标准库或中间件的开发人员而言，这尤其典型，而对于完整的端到端应用程序行为只有有限的可见性。

我还要指出的是，我什至没有考虑使这些算法并行化并利用用于运行这些测试的计算机上可用的多个内核的可能方法。 这将使实施，测试和分析更加复杂。

分析的确变得复杂而有趣，这使得这成为面试中一个有趣的问题。 它非常简单，可以使许多优秀的应聘者在解决问题上取得成功（无论他们采用哪种方法），同时为进行有趣的讨论提供了很多建议，讨论的方向可以有很多不同。

这也是关于复杂性如何在系统中扩展的一个很好的例子。 复杂的应用程序中散布着数百种算法。 它们从简单而天真开始，然后随着时间的推移（通常作为一些性能工作的一部分）进行调整，以利用操作环境和预期数据集的特定特征。 这些假设通常记录和验证不善，因此您以后常常会看到“烂”，因为针对一种情况进行的调整最终会随着时间的流逝而发生错误调整。 最严格的系统同时具有测试框架和操作遥测功能，以使这些假设有效，但是随着时间的推移，这不可避免地难以维护。

翻译自: https://hackernoon.com/time-space-and-interviews-70532a6e5c8

pmp访谈法和焦点小组区别