微软采访 | 14
我的名字是拉维钱德拉。今天我在班加罗尔参加了微软的面试。我是由一位顾问推荐的。对海得拉巴开发中心各个团队的各个职位进行了采访。
我无法通过第一轮。但是，让我分享一下我面对 geeksforgeeks 的读者的问题。
问题：
所有手机都以某种方式存储联系人。原始手机内存较少，处理能力较差。所以设计一个存储联系人的数据结构。这应该使用尽可能少的内存并支持算法高效运行。对该数据结构的基本操作给出了一个数字，如何查找联系人姓名，反之亦然。
最初我给出了一个 hashmap 解决方案。但他说由于冲突等原因，hashmap 操作成本很高……并要求我提供更好的解决方案。我提出了线性搜索。但他想要一个更好的搜索算法。
不幸的是，当我走出面试室时，我得到了更好的答案。
该解决方案是这样的。假设每个联系人记录都有唯一的索引值。让我们维护两个排序的索引数组，一个基于电话号码，一个基于姓名。所以使用的空间更少，搜索运行在 O(log n) 中。
以下是版主的一些想法：
由于手机功能有限，因此联系人的数量也有限，通常为 500 到 1000 个联系人。并且联系长度会受到限制，假设它是 64 个字符。
手机至少包含两种类型的内存，闪存和 RAM。 Flash 存储软件和持久数据。 RAM 用于处理。
有多种数据结构可以实现高效搜索。在数量上，根据我们假设的 1000 个联系人的功能电话，每个联系人有 64 个字符长，我们需要 [1000 * 64 * Nodesize] 的 trie（近似值）。它是几千字节的数量级。我们通常有几兆字节的 RAM。
如果 trie 对计划的 RAM 来说似乎代价高昂，我们可以使用三元 trie 或压缩 trie。甚至我们可以像有人指出的那样使用基于基数的搜索。
由于 RAM 成本高昂，我们可以在闪存中分配固定大小（例如 1000 个）的连续块来存储这些联系人。我们只需要一个动态搜索功能来访问这些联系人。每当用户启动搜索功能时， Trie都可以内置在 RAM 中。甚至，由于数据是恒定的，因此 trie 可以静态存储在闪存本身中。在联系人更新期间，在调用搜索功能时将该尝试带到 RAM。
请注意，联系人意味着一组数据，而不仅仅是电话号码。它还包括人名、联系电话（一个或多个）、组、分配的快速拨号号码、图片等……在设计数据结构时以数据为中心。在当前情况下，搜索是包装在此数据结构上的简单功能。在我们的 trie 数据结构中成功搜索的每一端都将指向存储在闪存中的匹配联系人结构。
这纯粹是假设性的想法。根据所需的功能，实际实施将更加复杂。我希望这足以进行面试讨论。在回答之前从面试官那里获得足够的问题细节。如果你在正确的轨道上，面试官会提供一些提示。