Redesigning Tech Interviews, Product-Centric Teams, AI Security | Anna J McDougall, Software Engineering Manager at HelloBetter
Currently managing engineering teams at HelloBetter, she has established herself as a pioneering voice in reimagining technical hiring and team dynamics through her "McDougall Method".
Anna is a 2024 WomenTech Global Awards winner and TEDx speaker. Author of the bestselling "You Belong in Tech," she is an expert in career transitions, AI-influenced hiring processes, and engineering team scaling.
Takeaways
In mental health tech, "move fast and break things" isn't an option. Engineers must understand that a product glitch isn't just a technical error, but could trigger real emotional harm for patients.
Vulnerability in cross-functional teams is essential, it's the bridge between engineers and product managers. Creating trust means repeatedly admitting "I don't understand" until collective comprehension happens.
The McDougall Method suggests that technical interviews should feel like a candidate's first week on the job. Let them use AI tools, ask questions, and show how they really work, not how well they can memorize code on a whiteboard.
Security is the silent battlefield of AI's expansion. As AI generates code and attempts to breach systems, companies must proactively invest in pentesting, bug bounties, and continuously evolving security standards.
Yassine: You manage a small, cross-functional squad shipping medical-grade features at HelloBetter. How important is it for engineers to have a strong product mindset in this environment?
Anna: It’s essential. I think many engineers want to put their heads down and just code or come up with cool technical implementations, but in a healthtech environment, that’s just not an option. Fortunately, when engineers work on products they love and care about, they tend to have more buy-in on the product side anyway. However, the regulatory hurdles and the higher barriers on product safety and data security mean that engineers can’t afford to just do what’s cool or what’s new: everything has to be justified, secure, and reliable. If we have an outage, it doesn’t just mean frustration for our patients, it could also mean a breakdown, or triggering a sense of isolation, or similar.
In mental health, these impacts have to be acknowledged and prevented, so the bar is set a lot higher in terms of product stability and security. As a manager, I need to know that my team understands that. When hiring, this is something I absolutely screen for: We are a startup, but we can’t have a cowboy/cowgirl mentality here. “Move fast and break things” isn’t how we can afford to work.
Y: What single habit or ritual helps you nurture that product mindset in your team?
Anna: I would say a really solid working relationship with our Product Manager. She is in all our meetings, is part of our team in every way, and we ask her all sorts of questions. In return, she asks us about technical details that many PMs might ignore or just think “that’s not my area”. By being open about what she wants and what we want, and how we work, and our areas of confusion, etc., we’ve managed to open up a strong dialogue and basis of trust around which to have larger conversations.
Vulnerability is needed from both sides here, basically an ability to say “I don’t know what you’re talking about: explain it to me more simply” over and over again until we’re all on the same page.
Y: You used your "McDougall Method" to redesign technical interviews and allow candidates to use AI copilots. What problem does the McDougall Method solve?
Anna: Companies that are stuck in this 90s/00s way of interviewing are essentially trying to replicate the old whiteboard interviews in a remote context, and it just doesn’t work anymore because you can’t control a candidate’s environment. The alternative is a take-home, which disadvantages many different types of candidates and is also uncontrolled in that you can never really know how long someone has spent on it or what tools they’ve used.
Instead, we use a pair programming approach based on a miniaturised (fake) version of our real codebase, with the mindset of: “The candidate is in their first week at our company and this is their first ticket”. We give them access to the repository one hour prior to the meeting, then give them problems to solve in the code, bugs, etc. They can then talk it through with the engineer, ask where things are, use whatever AI tools they want, etc.
The goal is to replicate that “first week” feeling as closely as possible without any access to proprietary material. That way, we can not only assess how they solve problems (in their actual way of working, Google, AI, and all) but then, with some follow-up questions, we can dive deeper into their understanding of what they’ve implemented.
The goal here is not only to assess their ability to implement and understand code, but also to see how they work with others and explain programming concepts in a way that others understand.
Y: How does the format surface useful skills better than common industry practices?
Anna: Well, for one thing, code doesn’t exist in a vacuum. DSA tests for memory, but doesn’t test for natural problem-solving ability. Take-home evaluations test for implementation, but it’s impossible to know how much of the work is their own. I’ve seen arguments that we should not test skills at all and instead rely on CVs, but CVs can lie, and people can be persuasive. Then I’ve seen others who say we should rely on referrals, which to me would be a disaster for creating teams with depth and diverse perspectives: most of us are friends with people who are similar to us, and going from 1 engineer to 10 engineers based purely on referrals is a fast way to create homogeneity and groupthink.
In the end, we want people who add something to our engineering departments: skills, an ability to work and communicate with other engineers, and something new that we didn’t know we were missing. The McDougall Method isn’t the whole answer to that - after all, there are still other interview rounds - but it is part of getting there in a way you can trust, with skills that an engineer will actually use in their work.
Y: In light of all the ongoing conversations about leadership and AI in engineering, what aspects do you think we're not talking about enough?
Anna: Security. I think it’s natural to get excited about the possibilities of AI for speeding up engineering work, quickly creating prototypes, etc. However, what I’m more interested in is how AI-generated code is going to impact security, and how AI-generated bots will try to overcome those safeguards.
I see the potential for there to be a kind of ongoing escalation of AI security standards vs AI automated hacking attempts in the coming years. I think every company needs to be investing more into security, pentesting, bug bounties, etc., as the use of AI continues to expand.
📚 Anna J McDougall's Go-To Resources:
People I follow and recommend:
Adelina E. Chalmers: CTO expert who is all about building business and political acumen in a technical business environment.
Kave Bulambo: She posts all kinds of insights about the tech industry in Berlin and Germany specifically.
Irina Stanescu: Offers engineering leadership insights balancing pragmatism and humanism.
A podcast I make time for:
Soft Skills Engineering: Each episode, they answer two questions from engineers or engineering managers about how to handle workplace or technical issues.
A newsletter I rarely skip:
A book that shaped my thinking:
The Organized Mind by Daniel Levitin: This book helped me to find ways to ‘outsource’ my brain to different systems. As someone whose brain moves a million miles an hour, this is a book that really helped me find ways to bring order to the chaos.
Thank you Anna for your time and insights!
This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.