<story><title>A senior engineer&apos;s guide to the system design interview</title><url>https://interviewing.io/guides/system-design-interview</url></story><parent_chain><item><author>stale2002</author><text>If the entirety of your web development knowledge is NDA&amp;#x27;ed, then what good are you as a potential employee anyway?&lt;p&gt;You wouldn&amp;#x27;t be able to build anything, as all your knowledge is NDAed!</text></item><item><author>rco8786</author><text>&amp;gt; 98% of what you&amp;#x27;d be inclined to diagram out and explain for a system design interview isn&amp;#x27;t remotely proprietary&lt;p&gt;Maybe we&amp;#x27;re just on different wavelengths, but literally every single thing I work on that would be a good candidate for this sort of interview is extremely proprietary...and I&amp;#x27;m just working on regular ol&amp;#x27; backend services at [generic big tech].</text></item><item><author>eschneider</author><text>98% of what you&amp;#x27;d be inclined to diagram out and explain for a system design interview isn&amp;#x27;t remotely proprietary. People are generally looking for a high-level overview of a system you&amp;#x27;ve worked on to see a) that you&amp;#x27;ve really worked on it and b) you can explain it such that it makes sense.&lt;p&gt;Sure, folks will ask you to drill down here and there for more detailed info, but if someone pokes on something where the details really _ARE_ proprietary, it&amp;#x27;s fine to just say that and offer to drill down somewhere else.</text></item><item><author>azornathogron</author><text>I like this... in theory. But I don&amp;#x27;t think I&amp;#x27;m allowed to give you a system diagram and detailed explanation of systems I&amp;#x27;ve worked on, because obviously they&amp;#x27;re proprietary. That seems like a problem.&lt;p&gt;How do your candidates normally work around this? Does everyone just talk about hobby or open-source systems they&amp;#x27;ve worked on?</text></item><item><author>rednerrus</author><text>We&amp;#x27;ve gone away from system design interview questions on my team. We ask people to diagram something technical they understand well and the team digs in and asks questions to understand depth and breadth of the candidates understanding. For us it works much better. It&amp;#x27;s a chance to see how well candidates do in following instructions. It gives you a chance to explore depth and breadth of their knowledge on something technical that they claim to understand. Our philosophy is how well you understand something you claim to know well is indicative of the depth and breadth of your technical knowledge in general. There are plenty of opportunities in this to ask about design and get to know how people think when it comes to design. I think it helps to eliminate false negatives and false positives.</text></item></parent_chain><comment><author>everydayentropy</author><text>This comment is a prime example of how the non-technical founder understands the world.&lt;p&gt;Proprietary systems are company IP. Talking about the design of the system is protected by the NDA, which the exercise described above is asking the candidate to do.&lt;p&gt;You hire for the skills to develop your own proprietary system. The employer doesn&amp;#x27;t own the skill. The employer owns anything those skills produced for the employer.&lt;p&gt;You wouldn&amp;#x27;t want your employees giving the recipe to your secret sauce away to your competitor, right? That&amp;#x27;s what everyone is talking about.</text></comment>
<story><title>A senior engineer&apos;s guide to the system design interview</title><url>https://interviewing.io/guides/system-design-interview</url></story><parent_chain><item><author>stale2002</author><text>If the entirety of your web development knowledge is NDA&amp;#x27;ed, then what good are you as a potential employee anyway?&lt;p&gt;You wouldn&amp;#x27;t be able to build anything, as all your knowledge is NDAed!</text></item><item><author>rco8786</author><text>&amp;gt; 98% of what you&amp;#x27;d be inclined to diagram out and explain for a system design interview isn&amp;#x27;t remotely proprietary&lt;p&gt;Maybe we&amp;#x27;re just on different wavelengths, but literally every single thing I work on that would be a good candidate for this sort of interview is extremely proprietary...and I&amp;#x27;m just working on regular ol&amp;#x27; backend services at [generic big tech].</text></item><item><author>eschneider</author><text>98% of what you&amp;#x27;d be inclined to diagram out and explain for a system design interview isn&amp;#x27;t remotely proprietary. People are generally looking for a high-level overview of a system you&amp;#x27;ve worked on to see a) that you&amp;#x27;ve really worked on it and b) you can explain it such that it makes sense.&lt;p&gt;Sure, folks will ask you to drill down here and there for more detailed info, but if someone pokes on something where the details really _ARE_ proprietary, it&amp;#x27;s fine to just say that and offer to drill down somewhere else.</text></item><item><author>azornathogron</author><text>I like this... in theory. But I don&amp;#x27;t think I&amp;#x27;m allowed to give you a system diagram and detailed explanation of systems I&amp;#x27;ve worked on, because obviously they&amp;#x27;re proprietary. That seems like a problem.&lt;p&gt;How do your candidates normally work around this? Does everyone just talk about hobby or open-source systems they&amp;#x27;ve worked on?</text></item><item><author>rednerrus</author><text>We&amp;#x27;ve gone away from system design interview questions on my team. We ask people to diagram something technical they understand well and the team digs in and asks questions to understand depth and breadth of the candidates understanding. For us it works much better. It&amp;#x27;s a chance to see how well candidates do in following instructions. It gives you a chance to explore depth and breadth of their knowledge on something technical that they claim to understand. Our philosophy is how well you understand something you claim to know well is indicative of the depth and breadth of your technical knowledge in general. There are plenty of opportunities in this to ask about design and get to know how people think when it comes to design. I think it helps to eliminate false negatives and false positives.</text></item></parent_chain><comment><author>djs070</author><text>The flaw in this argument is assuming that you could do a good job of diagramming a system without describing the use cases of the system. My web dev skills are not proprietary, but the processes and systems I have worked on are.</text></comment>