Hiring neurodiverse developers can be challenging, particularly for smaller companies that are less experienced at hiring. This isn’t because you need an entirely new process or that neurodiverse people are inherently trickier to interview. It’s that small flaws in your hiring process get exacerbated. Obstacles that cause neurotypical people to stumble, become outright blockers to a neurodiverse person.
So we asked Matt Nigh, data engineering manager at UW Medicine, to give his tips on how to make sure your hiring process suits everybody.
“I think there are companies that other organizations could mimic,” Matt explained. “I would look at Google as one of probably the best that I’ve experienced.”
-On the Dev Interrupted Podcast at 25:50
1. Interview processes should be conversational
If you use a lot of formal language, jargon and needlessly complicated words, you’ll make it much harder for your interviewee to understand what you want them to do. It also makes the interview artificial and cold, which can lead to unnecessary stress and anxiety in your interviewee. This is true for everybody, but for a neurodiverse developer, it can be much more potent.
“The most inclusive interview process I ever experienced was at Google,” Matt said. “And the reason I felt they had such an inclusive process is that it was wildly conversational. They were incredibly good at explaining what they were asking and what they were looking for. And to me, it was an incredibly friendly process.”
-On the Dev Interrupted Podcast at 24:10
2. Neurodiverse developers prefer straightforward and clear instructions
When giving instructions, particularly in practical tests, it’s important to make sure that you’re being clear and straightforward. Leaving ambiguity can cause problems, especially for neurodiverse developers. That ambiguity can distract away from the actual task at hand. The clearer your instructions, the better you’ll test a developer’s actual skills.
“I would say the reason I failed the system design interview was (and this is an example of what autism will do during an interview) it was the first system design interview I ever had. And I spent half the time trying to understand the language that the individual was using, rather than solving the problem, trying to make sure we’re just on the same page with what we were saying,” Matt said.
-On the Dev Interrupted Podcast at 24:40
3. Neurodiverse developers need diverse recruiters, and stick around for longer once hired
Everyone has their own biases. While we should all strive to overcome those, it’s not always possible. The best way to avoid those problems is to make sure your interview team is diverse. Some coping mechanisms and strategies can seem strange to a neurotypical recruiter at first.
For example, someone with ADHD might ask you to repeat points or be typing as you speak. While it could initially look like they’re answering emails or not paying attention to you, it’s more likely that they’re taking notes to make sure they follow your instructions properly. The more diverse your recruiters, the fewer false assumptions you’ll make.
“Most recruiters are used to looking at neurotypical applicants, and they essentially have mental flags that come up with certain things, certain questions or anything like that,” Matt said. “Companies should ask: Do I have inclusive recruiters? So say, for example, at Google, they had incredibly inclusive recruiters. I was recruited by a deaf individual, for example. So this person very clearly understands me and anything that was going on.”
-On the Dev Interrupted Podcast at 25:13
4. Neurodiverse developers could be more productive, and worth changing your processes
A program at Hewlett Packard Enterprise hired over 30 neurodiverse people in software testing roles at Australia’s Department of Human Services. The initial results from the program seem to suggest that those testing teams are 30% more productive than others, according to an article in the Harvard Business Review, called neurodiversity as a competitive advantage.
It would seem that, while a neurodiverse person might struggle in some areas—like the social anxiety brought on by an interview—they could exceed in others, such as pattern recognition.
Watch the full interview
If you’d like to hear more from Matt on neurodiversity in software development, you can watch the full podcast on our channel.
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
Three years into my software engineering career I was loving life. I could fix anything in the codebase with no doubts in my ability. I was confident, too. Most 24 year olds are. When I was offered the opportunity to become a dev team lead I jumped at the chance. With so much confidence, what could go wrong?
The first few months hit me like a freight train. I might have been a good developer, but I wasn’t a good leader - not yet. It was a humbling experience that I continue to grow from to this day. Great leaders understand that learning is a process that evolves over time, but only if you open yourself up.
In the past year as the host of the Dev Interrupted podcast, I have had the pleasure of interviewing and learning from some of the best engineering leaders in the business.
Here are 5 of their most inspiring lessons:
Always be delegating
Brendan Burns, Corporate Vice President at Microsoft
Brendan is widely known as one of the co-founders of Kubernetes. But he is also responsible for managing over 650 engineers at Microsoft. Even though Brendan takes time to schedule as many one on ones as possible - sometimes as many as 14 in one day, and something he views as a priority as more teams become remote - he knows such large teams can only be successfully managed through delegation.
Let go of the instinct to jump into every project. It’s ok if your teams make mistakes. They’re going to learn, but only if you give them the space and agency to grow. Stepping away from micromanaging can feel scary, but it will set your organization up for long term success and your employees will thank you for it.
Remote first, not remote friendly
Shweta Saraf, Senior Director of Engineering at Equinix
Shweta had the unique experience of undergoing a fully-remote acquisition during the pandemic. Her small team was acquired by Equinix, the largest data center company in the world. As if this adjustment wouldn’t have been difficult enough on its own, Equinix wanted Shweta and her team to teach them - an organization with over 30,000 employees worldwide - how to implement remote work best practices.
To be as successful as possible with this transition they chose to embrace remote work completely. There would be no half measures. If they were going to become a remote work company, they would be remote first - not remote friendly.
Leadership with empathy
Ben Matthews, Director of Engineering at Stack Overflow
Ben wants leaders everywhere to know that no one has ever done a better job because they were scared, stressed, or worried about their future. Especially not in jobs centered around creativity and problem solving like software development. Providing people with benefits such as mental health days does more for an organization’s productivity than measuring hours worked ever could.
When you take care of people they will work better and faster - that’s also what they want to do. Everyone wants to be successful. Value creation happens when people are provided for, not when they are treated like widgets.
Comparison leads to unhappiness
Kathryn Koehler, Director of Productivity Engineering
Kathryn believes that what’s being delivered is ultimately of greater importance than how something is being delivered. Though she is in charge of making sure engineering teams at Netflix run smoothly and efficiently, she takes great care when evaluating a team’s performance. She understands that productivity isn’t simple math.
That’s because every project is different. The customer base is different, the use case is different, personas are different, and where a team is within the software development life cycle is different. Ranking teams against each other shouldn’t be the goal. Success is best measured in context, not in competition.
Avoid meetings
Darren Murph, Global Head of Remote at GitLab
Darren tells anyone that will listen there is a quick way to improve your meetings: make them harder to have. He believes people deserve to be able to focus on their work. No one wants to sit on video calls all day. Zoom fatigue is real. Focus should remain on critical day-to-day functions, not on hopping in and out of meetings that leave you feeling exhausted and unproductive.
Leaders should embrace tools like Slack that allow teams to gather consensus asynchronously. Reserving synchronous time for purposeful meetings like making decisions or sharing important status updates.
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
To call Google a titan of the tech industry would be an understatement. Their name has become synonymous with the internet itself. The very act of retrieving information from the internet - the core functionality of the internet and its most basic purpose - is known simply as “Googling” something. On their road to becoming the web’s biggest search engine and a moniker for the internet itself, Google also pioneered much of what it takes to grow a company at scale.
On the Dev Interrupted Podcast Google Senior Engineer’s Hyrum Wright and Titus Winters, shared their lessons learned from programming at Google with LinearB Co-Founder and COO, Dan Lines. Both engineers have a deep understanding of the principles behind software development: Hyrum is semi-famous as the "Hyrum" of Hyrum's Law; while Titus is responsible for 250 million lines of code that over 12,000 developers work on.
But what lessons can we take from their interview - and their book Software Engineering at Google: Lessons Learned from Programming Over Time? How can we apply those lessons to our own projects? I’ve pulled out the core takeaways from their interview and condensed them so that any developer or company, be they responsible for 2,000 lines of code or 2,000,000, can learn something from Google’s roadmap.
Why listen to Google
In spite of their enormous success and scale, Google doesn’t pretend to have all the answers; this lack of presumption is exactly the thinking that has made them the titan they are. Previous success is no guarantee of future success and no one understands this better than Google.
One thing that Google is very good at is not accepting how everyone else does it as the one true way.” - Titus Winters, on the Dev Interrupted podcast at 20:35
It’s easy to assume that events and conclusions are foregone, or that one event naturally follows another. Yet this is rarely the case. Most of the time people are working towards a specific outcome, and it’s not until later that the outcome is apparent contextually. This is true in life and software development.
Google has spent the past couple decades approaching everything they do as trial and error, learning what does and does not work, and trying to institutionalize the things that do work. This is not a straight path.
This mindset is obvious in Hyrum and Titus’ interview. Titus uses the analogy of Lewis and Clark to explain how the software development process at Google has unfolded.
“They say Lewis and Clark explored the Louisiana Purchase, by which we mean, they took one path out and one path back, which is not exactly mapping, but in a similar way, we're trying to give an exploration/trip-report/map.” - Titus Winters, on the Dev Interrupted podcast at 6:17
He’s admitting that Google doesn’t have all of the answers; that Google’s path isn’t the only path to success; that other paths may be superior to Google’s; and that their path may not work for every business. But, with decades of experience, Google has learned a thing or two along the way, and maybe, just maybe, we can all learn something from the path they have trailblazed.
After all, there aren’t many companies in the world that have hundreds of millions of lines of code.
The 3 Pillars of Software Engineering at Google
“Anyone can change a line of code or change 10 lines of code. But how about changing 10,000 lines of code or 100,000 lines of code in a reasonable time? - Hyrum Wright, on the Dev Interrupted Podcast at 17:15
With so much code to manage, Google has made maintaining their code a strategic goal. Code must be fresh and able to sustain changes to the code base for business or technical reasons. To best allow for this, they have identified 3 concepts that they believe are core to software engineering.
1.Time
All of the hardest stuff that software engineers are going to have to deal with like skew version, backwards compatibility, issues with data storage, dependency management, upgrades and many more, are all problems created by time. Once dev teams realize this, it will change their perspective on how best to write code.
For instance, if you are going to get rid of your code within one or two years, then you probably don’t need to worry too much about making changes or upgrades to it in the future. But if you are going to write code that will remain in use after five or ten years, then you may want to approach it differently.
If dev teams want their code base to last, they need to think about constructing code so that it can sustain changes within an organization’s lifespan. This fundamental realization allows time to peacefully coexist with the second pillar.
2. Scale
How your system scales is a relationship with time. Scaling isn’t a new problem and Google has been at the forefront of pushing scale their entire existence. For instance, email existed before Gmail and search engines existed before Google, but Google’s brilliance was their ability to scale these technologies better than their competitors. It’s the root of their success.
To beat their competitors they adopted a mindset of scaling as a process - a continual evolution.
As a company grows, all of its operations expand and that continued expansion requires more resources, which begets even more resources still. This means growth cannot occur superlinearly because if it does, eventually a company will consume all of its resources maintaining the status quo.
The key takeaway is to make sure your codebase and software both scale sublinearly, that way if your codebase doubles or triples you won’t need six times as many engineers just to maintain your systems. (Sublinear scaling refers to team growth that occurs more slowly than the number of supported services of a company. Superlinear growth is the opposite - with team growth outpacing the number of supported services.
3. Trade-offs and Costs
After taking into consideration the best practices around time and scale, what is left is good decision making. Just as Hyrum and Titus note in their book, “in software engineering, as in life, good choices lead to good outcomes.”
However, no organization has perfect data on which to base every decision, and therefore must strive to make the best decisions they can with the most data possible. People need insights into what an organization finds impactful.
For instance, if an engineer spends a week on a project, it should probably be a project the organization considers a priority. Because if it is not, then no matter how perfect the code, it probably wasn’t the best use of the engineer’s time. Brain power should be devoted to the most difficult problems, not where a semicolon should be placed. The cost of incorrectly evaluating trade-offs is failing the 1st two pillars.
Coming Home
While Hyrum and Titus may not be Lewis and Clark reborn, they have a valuable story to tell about trial and error in the Information Age.
How a company scales is likely to define how it differentiates itself from its competitors and whether or not it will be successful. A company that can scale sublinearly will thrive, all others will stagnate as victims of their own success.
Minding the principles of these modern-day explorations into the wilderness of code will help any organization keep an eye on the most valuable resource: time. But remember just as Lewis and Clark found one path forward, they didn’t find the only path forward.
We can all learn something from Google, but never forget the path forward is your own.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
