What is absolutely baffling to me is that companies assign coding tests as a <i>pre-qualifier</i> for the usual whiteboard interview despite the coding test being a far more adequate measure of the abilities of an engineer. I&#x27;ve had interviewers tell me that my coding samples went above and beyond what they usually receive (exhaustive docstrings, tests that make sense) and yet rather than discuss, say, how my code worked or why I chose one algorithm over another, they insist on making me solve puzzles on the whiteboard as the ultimate decider.<p>The ideal hiring process for me would be introductory culture fit phone call, in which working hours, benefits, vacation policy etc are discussed to see if there is a lifestyle fit between prospective hire and employee (not &#x27;Do you rock climb and crush brews?&#x27; culture BS), then a coding challenge, and then an in-person discussion of your code. The in-person discussion could involve throwing new requirements and hypotheticals at the problem to see how the candidate thinks on their feet, but it would still be relevant to the work they did at hand rather than some arbitrary puzzle pulled from Cracking the Coding Interview.<p>I would be interested to know how the hoop-jumping-to-whiteboard process came to be standard. To me it does not make any sense why the determining factor for receiving an offer for a software engineering job should be dependent on one&#x27;s improvisational problem solving abilities over actually writing code that runs and satisfies requirements. Is it because a whiteboard interview is much more cut and dry than code evaluation? Because every software company wants to think that they are Google?