So many &quot;hiring is broken&quot; stories lately.  I sympathize.  Interviewing is typically not fun.<p>However, I&#x27;d like y&#x27;all to consider the problem from the other side of the table.  I conduct a lot of technical interviews.  I desperately want to avoid bad hires.  How do I avoid the bad hires?  It&#x27;s a really hard problem and there are consequences from both false positive and false negative signals.<p>Google asks &quot;big-O&quot; type questions not because they&#x27;re shibboleths or useless trivia.  It&#x27;s practical knowledge in an environment where things often have to scale up to absurd degrees.  Most candidates haven&#x27;t had experience in that kind of environment, so interviewers are looking for signs of aptitude.  Knowing which kinds of algorithms can scale up is a sign of that aptitude for those kinds of problems.<p>Lately, I&#x27;ve been asking more questions from the domain of what I call &quot;programming in the small&quot; -- the kinds of things that crop up when actually writing or reviewing or debugging code.  I do this because I&#x27;ve learned that the ability to construct an airtight Boolean predicate expression to test for a well-defined condition is a survival skill for good programmers.<p>If you&#x27;re a good candidate, then I&#x27;m sincerely sorry that I waste some time (for both of us!) talking with you about some basic stuff rather than having a more interesting technical conversation.