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.

Fact: Over 26% of adults in the United States have some sort of disability. To ignore such a massive part of the population would be ill-advised for any company, legally, financially, and above all, ethically. How can you stay ahead of the curve when it comes to maintaining a progressive and responsive organization? 

We reached out to two experts - Alwar Pillai and Perry Trinier of Fable – on the topic of designing products that have inclusivity for people with disabilities at their core. Here are the 3 things they think every engineer, developer and product designer needs to know about inclusive design and how it will inevitably affect the future of their companies.

1. Inclusive design has already brought us Alexa, Siri and countless other smart gadgets

Often times people assume that tech companies are driving innovation through focus groups or trying to cater to the average consumer, but that’s not always true. Some of the greatest recent innovations in tech have been found by designing technology to be as accessible as possible to people with disabilities. By keeping the designing process inclusive, you maximize potential for growth.

Alwar Pillai: Each of us today use technology that’s been designed for assistive technology users first, from as simple as an electric toothbrush, which is designed for people with motor impairments, but this is something that everyone uses now… you have voice to text was for people with disabilities again. And now we have... Siri, and Alexa, and like dictation, and all of that existed because it was designed for people with disabilities first, so it is already proven that when you practice inclusive design, and design for the edge cases, there is that broader impact.

2. Inclusive workplace culture draws in better talent

When you put inclusivity and accessibility at the front lines of your work culture and development process, you not only maximize your potential customer base but increase your pool of applicants and make your workforce more efficient. Some of the best talent in the world of inclusive design comes from people who use accessibility technology daily. Maximizing your accessibility to potential employees gives your company the best shot at finding the right person for the job. What does it mean today to build an accessibility first dev culture? 

Perry Trinier: I think it's like sort of the opposite of saying that accessibility is an afterthought. In this case, accessibility is absolutely primary. And it's also like a shared understanding on the team that accessibility isn't an extra feature or like a defect that they can backlog. It's just a table stakes dimension of the quality of what they build, and that they kind of aren't finished building what they're doing if it's still inaccessible.

Alwar Pillai: There's a lot of barriers when it comes to trying to build an inclusive team, to just the workplace tools that are out there, you know?... And so we've had to do a lot of... custom workarounds for some things. But it has resulted in every single person in the team understanding the impact of accessibility and taking that extra initiative and make sure whatever they're sharing with... each other internally is easily accessible to everyone.

3. Inclusive design’s influence is set to explode

There seems to be a cultural divide when it comes to inclusivity and many companies are hesitant to make the necessary changes to fuel a more accessible work culture. Making the effort to enact real change is necessary for the health of your business and the respect of the individuals who need accessible technology. More and more individuals and companies are seeing the need to stay current with inclusive design or, better yet, lead the way to establishing new and exciting ways to stay inclusive.

Perry Trinier: I think it's important to invest in helping the team members to build the knowledge and specifically set goals for reports to, for example, complete a course in accessibility. It's an important skill, just like security and performance are for front-end developers. And it should be treated in that same way for professional development. And there are tons of resources online courses on LinkedIn, Udacity. And there are lots of blog posts and talks by experts in the community like Marcy Sutton, and they’re directed to developers, like front-end developers who just need to learn what they need to know to be able to test their interfaces and to build experiences that everyone can use, so I would say that's the place to start is just with building up that capability.

Design is changing… Moving towards a more inclusive future

There is a fundamental gap in what is provided and what is needed for many people who use accessibility technology. The way of the future is to practice an inclusive design culture and keep every person in mind in your design process. 

Alwar Pillai: The way we build digital products right now is broken. There is a digital divide between the experiences of people with disabilities and people who are able bodied. And we as people who are part of engineering teams and engineering cultures, it's our responsibility to make sure we change the way we build products and make the process more inclusive, so that more and more people have access to the products that we're building.

---

If you want to know more about Fable and their ability to help your company evolve and grow while staying accessible to everyone, please visit www.makeitfable.com. Be sure to listen to and review this interview’s podcast and many others on Apple Podcasts, Spotify, Stitcher, YouTube or any of your favorite podcasting apps. Also, be sure to join the Dev Interrupted Discord community where we have conversations about topics just like this going all week long.

Grammarly has a simple but ambitious mission: to improve lives by improving communication. Every day, our AI-powered writing assistance helps 30,000 teams and 30 million people communicate clearly and effectively wherever they write.

But behind our technology is a team of engineers. Until recently, our engineers focused exclusively on building a product for consumers. When I came aboard to lead new initiatives as the Director of Engineering for Grammarly Business and Grammarly for Developers (expanding our product to support teams, organizations, and third-party developers), it was clear Grammarly approached full-on hypergrowth.  

Then the pandemic changed everything. Suddenly, we found ourselves transitioning to a remote-first organization amid hypergrowth hiring and onboarding. The company doubled in the past year to over 500 team members, and my teams have grown even faster. 

To be successful, we needed to spearhead initiatives that solved two problems. The first involved people: How could we successfully maintain a culture reflecting Grammarly’s EAGER values in a remote world? The second was technical: What tools and practices would enable our team members to thrive? 

Transitioning to remote

Historically, Grammarly has had an in-person culture. We have four hubs—in Kyiv, San Francisco, Vancouver, and New York. But when I joined in July 2020, everyone was remote. Few assumed it would stay that way, but the “return to normal” kept getting pushed further back. Eventually, Grammarly adopted a remote-first hybrid model. 

With “remote-first,” Grammarly team members work primarily from home. However, we continue to believe in-person interaction builds trusting relationships and a supportive culture that fosters innovation. So our offices became collaboration hubs where face-to-face meetups will also take place each quarter.  We made this decision based on our progression as a company; because we felt we’d learned how to communicate and collaborate effectively and saw advantages to the remote-first model.

Keeping it personal 

I look forward to meeting people in person at our first team-based meetup next year, but with my quickly growing team split between Kyiv and North America, we need to constantly build and maintain personal connections.

“I've onboarded fully remotely. I've only met four of my coworkers in person.”

- Dev Interrupted podcast at 19:33

Thus, we’ve tried our best to foster a thoughtful approach to team bonding at Grammarly—which signals that breaks and fun are important, too. 

Some example approaches: 

• Events celebrating everyone’s individuality and encouraging personal connections
• Coffee/donut chats, compliments of Grammarly
• Virtual hackathons

Our events motivate people to break from work and connect with each other. Activities range from educational to creative and silly, including an Indian cooking class during Diwali, a graffiti workshop, a cocktail class, a Halloween costume competition, and Grammarly’s twelfth-anniversary talent show. This personable approach also translates to how we chose the tools for remote collaboration.

Finding the proper tools

Setting hypergrowth teams up for success requires investing in the right tools and processes. As often as possible, we try to implement asynchronous communication and development best practices. Proper tools that facilitate organizational transparency are critical for alignment in a remote-first company.

Fewer people are required in Zoom calls because we share recordings and notes in open Slack channels. For collaboration and stakeholder alignment, our Engineering teams use Confluence for documentation, Jira for issue tracking, and Figma for collaborative interface design. Architecture and whiteboard sessions occur in Miro, while team retrospectives happen in Parabol. 

The archival component of these tools is invaluable; new and old team members alike can discover information through Glean, which gives us aggregated search across all our tools and content. 

Embracing the talent diversity potential of remote work 

One of the most exciting opportunities with remote work is in finding hidden talent in overlooked geographies. Silicon Valley gets all the attention, but it’s not the only region with great software engineers. There’s plenty of talent out there just waiting to be found. 

“Genius is evenly distributed by Zip Code, but opportunity is not”

- Mitch Kapor, Kapor Capital

Finding talent in other locations also leads to more organizational diversity. Whether that diversity is racial, ethnic, socioeconomic, or generational, diverse teams are going to improve your product. I’m a huge believer in diverse teams for two reasons: 

1. Better problem-solving than homogenous teams: I’ve witnessed this in my career, and it’s been proven with studies. Creativity naturally flows from visible and invisible diversity. Companies embracing differences will achieve better outcomes because the ensuing creative conflict helps you innovate and build better products. 
2. Stronger empathy for the customer: In Grammarly’s case, building writing assistance for the world’s 1 billion English speakers makes diversity in engineering critical. For example, those speaking English as a second language often visualize the language differently, leading to feature ideas that wouldn’t occur to primary English speakers. 

You need a diverse team to build the right product for a broad audience. We’re excited to use recruiting tools like SeekOut and partner with organizations like Elpha and AfroTech to help us connect with and hire engineers from underrepresented groups. 

Onboarding

But hiring isn’t enough! Many organizations are too focused on hiring, at the cost of onboarding. How we onboard folks and make them feel welcome is critical to their long-term success at Grammarly. 

A small test of our onboarding process is whether new engineers can push code in the first week. If they can, it’s a signal the dev environment is well documented and has minimal friction. The faster people can be productive, the more confident they feel, which ultimately boosts team morale. 

That said, onboarding is about more than pushing code. Engineers are encouraged to meet people and learn the product before they feel pressure to deliver. New engineers have a Getting Started Guide that includes who to meet and links to resources. Managers check in daily to answer questions. They also pair with a non-engineering Culture Buddy plus a mentor from their team so they can get to know all aspects of Grammarly life. 

Thoughtful onboarding during hypergrowth helps new team members build connections, which leads to better team health in the long term. 

Staying Grounded 

My advice to any organization about to engage in hypergrowth is to remain thoughtful. Think about hiring, onboarding, your processes, how you measure success, and how you want your employees to feel when they join your team.

Remember, too, that diversity is more than a checkmark or an abstract goal. Diverse teams will be your strongest asset. They will push creative boundaries—and in doing so will build the best possible product with the best possible outcomes. 

_

Want to join us in helping 30,000 teams at thousands of companies succeed through effective communication? We’re currently hiring for roles across the Grammarly Business and Grammarly for Developers teams.

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 >>

A year ago I wrote an article for Dzone titled The Rise and Fall of a Senior Developer. Filled with personal anecdotes and stories from my years as a software engineer, the article was a critique of industry practices surrounding the somewhat controversial issue of ranking programmers’ seniority.

I realized that I might sound like an elitist dinosaur patronizing the upcoming generation of software engineers. A sort of “back in my day we did things differently” mentality that every generation seems to age into. 

So you can imagine my surprise when the article became not only my most popular submission, but caught the eye of Dan Lines, host of the Dev Interrupted podcast. 

In a follow-up to my article from last year, I’d like to share some of the takeaways from my discussion with Dan and discuss whether or not some of these hiring practices have changed in the past year. 

The rise of remote work is truly changing the landscape of hiring developers and finding talent. But are companies better able to find The True Senior Software Developers in 2021?

What is a "senior" developer?

There is no objective measure of a senior developer. Everything is dependent upon the specific work environment a developer finds themselves in. A humorous analogy could be the movie Idiocracy.

Seniority is determined very differently in an environment where your superiors have less knowledge and experience than yourself. Likewise, in a highly technical environment filled with experienced individuals, for instance, Tesla’s autonomous car team, you might discover seniority is determined by different standards. 

My most pragmatic answer is to say that it really depends on where you are and that hopefully your organization isn’t being run completely incompetently. 

To me a senior is someone who has mastered their domain beyond a majority of their team. That's probably the safest way for a manager to define how to find a senior developer: quantify the average level of knowledge on their team, and seek somebody who is above that average.

Being good at your job doesn’t make you senior

Not everyone hired at a company can be a senior developer but that’s a good thing because you don't want everybody to be at the high end of the spectrum. You need a team which is properly varied and has people with all levels of skills to fill in all the niches and gaps in your development process.  

Very often, companies just need someone who is good at React or proficient in TypeScript, able to adapt well to a team, understand a project, pick up tasks and implement them efficiently. That’s a good developer - not a senior developer. Those are things that you would expect from any member of a team because that’s what you pay people for.

I believe that when you're looking for a senior developer, you should be evaluating well above average. Unfortunately, it seems many companies advertise for senior developers, in the hope that they will somehow filter out the noise and get the most talented people, simply because they made it clear they were searching for senior candidates.

Of course every developer that shows up to an interview is going to say “I am a senior developer, a god amongst men.” Why? Because that’s what everyone wants to hear! 

That's probably a reason why seemingly 90% of advertisements for developer positions are for seniors, while the reality is that on a team there are only a few seniors. 

Experience isn’t everything

Though a year has gone - and you, dear reader, find yourself with another year of experience - that’s not an indication that you have magically become a senior developer. My belief that experience matters but is in no way an indicator of being a senior developer hasn’t changed.

Let's be honest, somebody can be a lazy bum for ten years and by sheer luck navigate through corporate realities and get away with it. As I said before: 

“10 years of JavaScript is just as good of an indicator of me being a senior programmer as 10 years jail time for armed robbery is an indicator of me being a law professor.”

Years of experience are needed, but I would never use them as the sole indicator of being a senior.

Where are we today?

Now that we have recapped, where are we today?

The rise in remote work is changing the hiring landscape and the development process. Companies are beginning to shift more teams to asynchronous development or hybrid models. These changes might be well-received by individuals but what will the long term impact be on hiring practices? 

It’s my opinion that companies are way too focused on the hottest frameworks, coolest tricks and fancy techniques, while forgetting the bigger picture, the concepts and principles behind software engineering and languages.

In the interview process applicants will claim to be Angular senior developers because they have an understanding of how to set up Vuex state store or fetch data from REST service using Axios, but having no idea about observer pattern, how asynchronous JavaScript actually works and are ignorant about prototype inheritance.

All these fancy things, they come and go very fast. But fundamental knowledge stays with us much longer, and if needed, allows us to learn all these transient frameworks, fads and fashions. 

Companies need to train themselves to filter out the noise. Don’t hire for passing fads. Look to hire developers with strong fundamentals because those are difficult to teach. If a candidate is good at something, even if it’s not the particular framework or language you are looking for, you should not dismiss them.

A real-life example

When I arrived in Ireland, I began applying for jobs and got interviewed by two gentlemen who started grilling me at the whiteboard. At some point during the interview I interrupted and said, “Guys, I think you have the wrong person here. I came to Ireland with a background as a .NET with a specialty in C sharp.” They wanted someone proficient in Python and I had never worked with it professionally. 

What they said next completely blew me away:

“We understand you don’t know much Python but we like your way of thinking, we see you are a brilliant C sharp programmer.”

Then they allowed me to take the test assignment for the interview in my preferred language of C sharp. Once I finished, they brought in a colleague from another floor who was a C sharp expert, he looked at my work, gave his approval, and they hired me on the spot. 

After about half a year, I was actually teaching Python to junior developers on the team.

I was taken by this honest approach to logic and hiring. They recognized an expertise in me even if it wasn’t exactly what they were looking for. 

There’s no replacing good fundamentals

It’s possible that the past year, and the continued evolution it has brought to remote work and remote dev teams, has caused more companies to jump at the chance to hire senior developers who claim they are experienced just because they put “managed remote dev teams for x years” on their resume. 

But when I watch events like this remote engineering panel, it is my hope that more people in the industry are adequately identifying The True Senior Software Developers, by avoiding the pitfalls of buzzwords and fad languages to hire exceptional individuals. 

While the fads and fashions of 2021 won’t be around forever, good fundamentals aren’t going anywhere (remote work might not be either.) Stick to hiring principles with an emphasis on expertise, but avoid having so narrow a view as to overlook talented individuals, and remember to always give honest feedback.

Not everyone is a senior developer, but if we’re honest with ourselves and our abilities, we can all take the steps to get there! 

If you’re interested in this topic, you can find more content like this on my blog at https://letsdebug.it.

Also consider checking out Dev Interrupted, a weekly podcast featuring a wide array of software engineering leaders and experts, exploring topics from dev team metrics to accelerating delivery. 

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 >>