<story><title>My favorite coding question to give candidates</title><url>https://carloarg02.medium.com/my-favorite-coding-question-to-give-candidates-17ea4758880c</url></story><parent_chain><item><author>clnq</author><text>&amp;gt; No great engineer should ever settle for an O(n²) algorithm, unless bound by memory or some other unmovable constraint.&lt;p&gt;What if this is a one-off to produce a business report? Would it make sense to use programmer time to create an O(n) structure in memory, or just loop through the files line by line and let the CPU take a minute or five, or thirty? What is the programming language - something that has a library for this or something very low level where we’d read the file byte by byte?&lt;p&gt;If we’re dealing with the latter, a small amount of data, and a one off report, I don’t care at all in my work whether an engineer I’m managing somehow writes it in O(n^3).&lt;p&gt;It’s interesting how quick to judge the author is - ask this question for points, don’t even think about that, don’t mention arrays because they’re fixed size (despite implementations for dynamically allocated arrays totally existing and the candidate might be coming from that), and so on. Some humility would be nice.&lt;p&gt;Although I think what they wrote is very valuable, as this is how many interviews go. And I have to at least appreciate the author’s approach for trying to start a conversation, even if he still takes a rather reductive approach to evaluating candidates.</text></item></parent_chain><comment><author>jauntywundrkind</author><text>There&amp;#x27;s places where writing bad shitty code doesn&amp;#x27;t matter but frankly I&amp;#x27;d rather be at places and rather have colleagues and an environment where we don&amp;#x27;t write bad shitty code.&lt;p&gt;The attempts to circumstantially excuse away shitty answers goes against the desire to just not be shit.&lt;p&gt;The author here seemed able and willing to talk through constraints &amp;amp; issues. Their first paragraphs practically begged for it, as a sign of maturity. Rather than just excuse away shitty solutions, my hope is, even if you are not a super competent can-do coder, you at least can talk through and walk through problems with people that are trustable, to arrive at reasonably competent capable answers.</text></comment>
<story><title>My favorite coding question to give candidates</title><url>https://carloarg02.medium.com/my-favorite-coding-question-to-give-candidates-17ea4758880c</url></story><parent_chain><item><author>clnq</author><text>&amp;gt; No great engineer should ever settle for an O(n²) algorithm, unless bound by memory or some other unmovable constraint.&lt;p&gt;What if this is a one-off to produce a business report? Would it make sense to use programmer time to create an O(n) structure in memory, or just loop through the files line by line and let the CPU take a minute or five, or thirty? What is the programming language - something that has a library for this or something very low level where we’d read the file byte by byte?&lt;p&gt;If we’re dealing with the latter, a small amount of data, and a one off report, I don’t care at all in my work whether an engineer I’m managing somehow writes it in O(n^3).&lt;p&gt;It’s interesting how quick to judge the author is - ask this question for points, don’t even think about that, don’t mention arrays because they’re fixed size (despite implementations for dynamically allocated arrays totally existing and the candidate might be coming from that), and so on. Some humility would be nice.&lt;p&gt;Although I think what they wrote is very valuable, as this is how many interviews go. And I have to at least appreciate the author’s approach for trying to start a conversation, even if he still takes a rather reductive approach to evaluating candidates.</text></item></parent_chain><comment><author>0xb0565e486</author><text>I would argue that in most cases where performance isn’t a constraint, the first algorithm that comes to mind is probably the most optimal choice. He even says:&lt;p&gt;&amp;gt; About 80% of the candidates go for the naive solution first. It’s easiest and most natural.&lt;p&gt;The “naive solution” will be easier to understand and maintain. Why make it harder if it doesn’t add value?</text></comment>