The standard engineering interview process was designed, largely by accident, to select for neurotypical social performance. It filters out neurodivergent candidates at every stage — often before a single line of code is evaluated.
Where the Standard Process Fails
The whiteboard interview asks a candidate to write code on a vertical surface, in silence, while one or more strangers watch and evaluate them in real time. For a neurotypical candidate with strong social confidence, this is uncomfortable but manageable. For a candidate with ASD or social anxiety, the performance pressure can completely suppress the cognitive function being tested. You are not measuring coding ability; you are measuring the ability to code while being watched. These are different skills.
"Culture fit" questions — "Tell me about yourself," "What's your biggest weakness?", "Where do you see yourself in five years?" — are open-ended, socially loaded, and reward candidates who are fluent in the implicit social contract of professional self-presentation. Autistic candidates in particular often answer these questions with disarming literal honesty ("My biggest weakness is that I find small talk exhausting and pointless") and are penalized for it, despite the answer being both accurate and professionally relevant.
Unstructured conversation rewards improvisation. Neurodivergent candidates often need processing time. A question that a neurotypical candidate answers in three seconds may require ten seconds of genuine cognitive work for an autistic candidate — and that pause is frequently misread as confusion, disengagement, or lack of knowledge.
Building an Inclusive Interview Loop
1. Eliminate ambiguity with advance notice.
Send the interview topics — or even the specific questions — 24 hours before the interview. This is not "giving away the answers." It tests the candidate's ability to prepare, research, and structure their thinking. That is a job-relevant skill. Improvisation under social pressure is usually not.
2. Replace whiteboarding with work samples.
A take-home assignment (with a reasonable time limit and clear scope) or a paired programming session on a real computer with a real IDE tests actual coding ability. The candidate can use their tools, their environment, their process. The output is the signal.
3. Use explicit, structured questions.
Instead of "Walk me through your resume," say: "Please describe your last two roles. For each one, tell me: what the system did, what your specific contribution was, and one technical challenge you solved." This is not dumbing down the question. It is removing the social overhead so the technical content can surface.
4. Accommodate sensory and physical needs.
Allow candidates to keep cameras off during remote interviews. Allow fidgeting, stimming (self-stimulatory behavior that helps regulate sensory input), or movement during in-person interviews. Offer a quiet room rather than a glass-walled conference room. None of these accommodations compromise the integrity of the assessment.
5. Audit your "culture fit" criteria.
Write down what "culture fit" actually means for your team. If the list includes things like "enjoys team lunches" or "comfortable with banter," ask whether those traits are genuinely required to do the job. Usually they are not. Replace them with observable, job-relevant behaviors: "communicates blockers proactively," "gives and receives written feedback constructively."