在一次采访中，我被要求编写代码/设计东西。有时甚至提供代码示例。非常合理和明智（当这种情况没有发生时总是感到惊讶）
大约一年前，我有一份工作，那里的代码太糟糕了，如果我看到了我必须提前处理的混乱，我就不会接受这份工作。我无法告诉你我不得不使用多少可怕的数据库。
我是否不可能要求他们提供代码示例并查看他们的数据库设计？假设我很乐意签署保密协议，我的一部分人觉得，如果不检查我将要使用的代码库或数据库就接受一份工作，那将是疯狂的。
有人做过这个吗？
更新
如果事情进展顺利，我觉得很快就会有报价，我会在面试过程中问这个问题。
这也适用于在小商店或小项目中工作的情况，因为我更喜欢避免在使用诸如"让开发人员离开地板"
之类短语的地方工作。答案可能是"不"，但任何人都不应该认为这是一个糟糕或不恰当的问题。
如果他们不给你看代码，你在决定是否接受报价时一定要考虑到这一点。我认为这是一个迹象，至少以下一件事是真的：
- 代码太可怕了，他们知道你会尖叫着逃跑
- 该公司有一种极端隐秘的无人信任文化（我讨厌这种文化）
- 该公司认为他们有如此惊人的代码，只要看一眼就会把你变成超级明星的竞争对手。（换句话说，他们是自欺欺人的白痴。）
- 他们有明显的安全漏洞，希望保守秘密
- 面试你的人自己不知道如何获得代码。（在这种情况下，你没有与合适的人交谈。）
我更感兴趣的是查看公司的系统，即测试框架、发布过程、自动构建。。。。这些代码的存在与否会告诉我比几百行代码多得多的信息。
我确实问过："我能看一些代码并与在这里工作的程序员交谈吗？"
雇主回答："当然！来吧，你可以直接和我们信息系统的首席程序员谈谈！"
多么荣幸！
- 他们给我看概念文件
- 我可以和首席程序员谈谈
- 他们给我看了一个非常新的项目的一小部分，告诉我："这只是一个原型，direct3d非常粗略，这就是为什么这个代码如此混乱的原因"
事实证明：
- 首席程序员在我到达的那天就离开了
- 他领导的软件一团糟
- 不知怎么的，我花了50%的时间与混乱作斗争
我们面试过的候选人都没有问过这个问题；然而，他们中的许多人都是公司的合作伙伴/实习生，所以他们熟悉我们的代码。。。
话虽如此，无论NDA如何，我们都不太可能向任何候选人展示我们的代码。我很乐意回答有关我们使用什么技术、使用什么系统进行修订、实践等问题。不过，实际代码是什么？编号
同样，在一个足够大的系统中（就像我们的系统一样），有人可以向你展示"最好的"代码……你就会从那里开始：）至于数据库设计。。。我工作过的两家公司都有庞大的数据库（大学、公司）。。。所以这也不起作用。
我在接受Xerox PARC（一家初创公司）和雅虎的采访时问过这个问题。
在PARC，他们让我坐在一个工作站上，拿着如果被雇佣我会接手的代码，非常简短地查看了代码库的结构，并让我单独呆了大约20分钟。这足以让我知道我是否能忍受这样的工作，尽管我希望有更多的时间，比如总共一个小时。之后，我问了一个看起来可疑的设计决定，我们聊了聊设计和总体风格。这不仅告诉了我更多关于这份工作的信息，还告诉了他们更多关于我的信息：我是自上而下还是自下而上地探索他们的代码，我学到了什么或问了什么，等等。
在初创公司，他们在另一天单独召开了一次会议，请来了代码的作者（他不是员工）；我们坐在笔记本电脑前，一起看了看东西。这对他们来说是一个不同寻常的要求，我想我必须签署一份新的保密协议。这再次是值得的：我之前的采访并没有真正弄清楚这种奇特的人工智能语言是什么，也没有真正弄明白他们希望我用它做什么，坐下来处理一些具体的代码消除了很多迷雾。
在雅虎，我什么都没看到；我不记得他们的反应了。如果我看到了我最终处理的代码，我可能会重新考虑（尽管最终一切顺利）。（我看到的上述两个代码库似乎总体上都更好；PARC代码库后来是开源的。）
在所有这些情况下，我都与他们共享了一些自己的代码。
如果你要这样做，我认为你需要给他们一个小小的警告，这样他们就可以准备一个NDA，并设置一个合适的环境，你可以在其中看到它。还要准备花一点时间来理解代码为什么会是这样。
如果你在第一次面试时出现，说，对吧，我能看到代码吗？除了极少数人之外，其他人都会说不。这不一定是因为他们很邪恶，不想给你看，而是因为这并不像说"是"那么简单。
根据我作为一家大型软件公司招聘人员的经验，我们需要花费相当长的时间来披露足够详细的代码和内部开发的框架，让任何候选人——无论多么聪明——能够对其利弊做出有意义的判断。只有当我们认真考虑雇佣他们时，我们才会考虑这样做。
如果有人问我这个问题，我会答应的，改天再来，我们会安排的。我会让一个值得信赖的开发人员离开现场，让他们带上笔记本电脑参加下一次面试，并展示一些代码。
事实上，任何一个规模合理、已经存在了不止一个版本的软件项目都会有一些可怕的垃圾。
与其他一些回应类似，我从未有候选人要求查看我们的代码。即使他们这样做了，我也非常小心，很可能不会。正如Swati所提到的，几乎任何非平凡的系统都会有看起来不错的部分，所以即使看到代码也没有多大帮助。
比查看实际代码更好的是Joel测试。基本上，你可以向雇主提出12个是或否的问题。答案越多，工作环境就越好。这显然不是一条硬性的"规则"，但它似乎表明那些认真对待代码（以及程序员）的公司。
我想不出有什么理由不显示某些类或谈论它们正在使用的架构。在我看来，这就像是让他们带你去哪里工作（房间、桌子、椅子、队友…）。无论如何，要求这样做会向他们表明你对最佳实践感兴趣，也表明你并不急于以任何代价找到工作，也不知道这会带来什么伤害。
转到开源项目。在那里，您不必请求许可即可查看代码。
问也无妨，这是一个非常好的主意，我将把它添加到我向雇主提出的问题清单中。
这是一个有趣的想法，但我不知道有多少公司会支持它。我知道我们在我现在工作的地方做不到。
我认为你会遇到的最大问题是，我发现很多人会对不喜欢他们代码的人感到愤怒。这就像批评别人的治疗师，做一个局外人并不是一个好主意。看到代码却不接受这份工作可能会给你留下傲慢或不够好的名声，让你无法完成代码，这就是为什么你没有接受这份工作。这可能会让你免于得到你不想要的工作，但也可能会给你带来负面名声。我住在一个相当大的城市，但IT人员仍然相互了解，消息传开了。我们这个领域的人都很自负，诋毁别人的声誉比承认你写的代码不符合标准更容易。
即使他们给你看了一些代码，这是否足以让你对你将要花时间使用的代码的质量得出一个粗略的结论？例如，在我以前的地方，他们的一个产品是大型电子银行中间件应用程序。该应用程序的核心是C++，并以出色的方式进行设计和编写。然而，C++中的扩展（到目前为止，它涵盖了应用程序的很大一部分及其各种不同版本），大多是由经验不足、知识渊博的开发人员编写的，它们是一堆糟糕的代码（我有时不得不修复和使用这些代码，或者从头开始编写），拼凑在一起才能以某种方式工作。如果我在面试中让他们给我看一段代码片段，并且他们给我展示了一些核心内容（扩展代码实际上主要包含特定于客户的业务逻辑，所以如果没有业务领域的知识，它就没有多大意义，等等），我会认为代码的总体质量很好（事实并非完全如此）。
我认为，比索要代码片段更重要的是询问他们使用的是哪种源代码控制产品（逃离回答"Visual SourceSafe"的公司）以及他们使用的方法："敏捷"或"Scrum"发出了积极的信号，CMMI通常意味着公司喜欢官僚程序，如果他们给你一个"嗯？"，你就会受到警告；）
我认为这是个好主意；然而，作为一名雇主，我会犹豫——即使有保密协议——是否要为面试候选人提供真实的工作代码样本，除非我非常确定我想雇佣这个人。
问题是他们会向您展示一小段代码，但他们的每个程序员都会以不同的方式编写代码。不幸的是，您必须处理代码库中写得很好的部分。
询问他们的编码标准以及他们如何执行它更有可能有用