What I&#x27;m writing is tangential, but related to the topic.  When we discuss tech interviewing, I think it helps to start with the basics of the process and the motivations behind technical interviews that are essentially exams.<p>Recruitment for tech companies is near constant at a certain level of talent.  While there are smaller or profitable but stable niche companies that aren&#x27;t looking to add engineers, most companies would always hire an engineer with a skill level that exceeds a certain threshold.  In other words, if you&#x27;re really good at coding, have a really strong understanding of software design, and you aren&#x27;t a hard person to get along with, they&#x27;ll have something for you.<p>This leads to the technical &quot;interview&quot;, which is really better described as a technical exam.  The most infamous incarnation of it goes like this: you arrive in a room, a very strong software developer arrives you are asked a variant on a data structures&#x2F;algorithms question that you must solve at the whiteboard.  It will be difficult to get it exactly right in the time allotted, but you will now demonstrate that you are able to write tight, good, efficient code that largely solves the problem.  You will also demonstrate that you can clearly explain difficult technical concepts in clear human language (usually English), without getting angry or excessively flustered.  If you&#x27;re really, really good at this, they have something for you.  Exactly what that is we can all work out later.<p>This leads to a constant state of &quot;filtering&quot;.  These companies are continuously scooping up silt, sifting through, to see if there are any good bits of gold in there.  If they accidentally throw out a bit of gold, that&#x27;s fine, they just keep sifting and sifting.<p>The odd thing about this (having been on a few of these interviews myself) is that it turns the &quot;interview&quot; process into a technical exam.  I&#x27;ve been shuttled from room to room for six hour of whiteboard exams, all about tree traversal, complex sql, some math, and at the end of the day, I honestly have no idea what this company does or what they&#x27;d want me for (aside from what I&#x27;d read about in preparation for the &quot;interview&quot;, none of which was discussed at all).  But I do get it from the point of view of the company - if I can do certain branches of math, write tight code, and do sql really really well, and I clearly have the verbal and presentation skills to explain it all, then yeah, they will be able to make good use of me at their company (for the record: no offer ;) )<p>The filtering is irritating for candidates, of course, since it means that in our field we sit for exams constantly.  The saving grace is that these companies must devote the valuable time of their strong engineers to conduct the interviews, which means they don&#x27;t do it unless there&#x27;s a good chance you&#x27;re a good candidate.<p>The more insidious side of this is the rise of automated testing and&#x2F;or &quot;projects&quot;.  You spend 30 minutes talking with a recruiter, and then you get a link to an on-line exam or project that can take from 2-8 hours.  This allows the company to cast a wide net without wasting time.  Well, wasting <i>their</i> time.  The process allows them to push the inefficiencies of the process out onto the candidates.  The amount of time spent by developers on these exams, only to be dismissed in 5 minutes, is staggering.  This is one reason I won&#x27;t take these exams (if they occur very early in the process - if it happened much later, when it was clear both sides were serious, I would reconsider), even though I will spend an equivalent amount of time on in-person exam&#x2F;interviews.