Hiring from Within, Fast Delivery Culture, AI Strategy | Emily Nakashima, VP of Engineering, Honeycomb.io
Emily Nakashima is the VP of Engineering at Honeycomb.io, where she brings a business-oriented lens to developer tooling and observability. With over a decade of experience in B2B SaaS, she’s known for combining frontend engineering depth with a strong focus on developer experience and organizational systems.
Before Honeycomb, she led frontend efforts at Bugsnag and held engineering roles at GitHub, where she built performance-focused tools used by millions of developers.
Today, Emily is focused on scaling high-performing, inclusive teams, designing interview processes that reward time management over perfection, and helping engineering orgs adopt AI with clarity and intent.
Emily Nakashima is also an active voice in the monitoring and SRE community and a regular speaker at LeadDev and Monitorama.
Highlights
Rapid shipping matters more than brilliant architecture in startups
AI adoption fails when clarity is missing
Coding challenges reveal important time management skills
Internal promotions work because context beats credentials
Yassine: You joined Honeycomb.io as an IC and worked your way up to VPE. What blind spots do you think external leadership hires often have that your internal growth journey gave you perspective on?
Emily: Based on what I’ve learned from industry colleagues and seen at Honeycomb, I believe the strongest startup executive teams typically have a mix of homegrown talent and seasoned external hires.
That said, internal hires bring some key advantages that are hard for external hires to replicate. For one, you deeply know multiple areas of the company: product, technology, and team. When senior leaders are considering big changes, you often have the clearest window into how they will be received and how the company will adapt (or not). Your knowledge of the technology and team can also help you see opportunities for a pivot or for new investments and innovations that others may not immediately recognize. And you typically have deep conviction about the identity, culture, and values of the company; you become a defender and champion of those as the company navigates change.
When I first joined our executive team, I worried that I might always be playing catch-up, contributing less than more seasoned members. Over time, I’ve seen how I have a unique perspective that helps balance our other execs, who often bring an incredible breadth and depth of experience from the outside but are new to Honeycomb.
Y: While many companies are moving away from coding challenges, you've kept them at Honeycomb (+synchronous debriefs) to identify time-efficient engineers. Do you see this approach scaling successfully as the organization grows, or will it need to evolve?
Emily: There has understandably been some pushback on coding challenges in recent years, but we’re committed to keeping ours and believe we can scale them as the company grows. I think a lot of companies deploy these poorly and completely disrespect candidates’ time, but we try to do them differently.
We actually removed coding challenges from our hiring process at one point, but we added them back because we missed the signal they provided. At a startup, time is often our most scarce resource, and the coding challenge is the one place where we really see candidates interact with time as a constraint. They don’t have to write code perfectly in strict time constraints, but we want to see meaningful progress against the prompts relative to the time allowed. While coding challenges don’t perfectly match real work, we’ve still found that how the candidate manages time in the challenge is predictive of how they will manage time on the job. Candidates who turn their coding challenge in late or struggle to make meaningful progress in the provided time window may turn out to be wonderful teammates in many ways, but more often than not, they have those exact same struggles with timelines and task completion on the job too.
To mitigate some of the downsides of coding challenges, we position our challenge somewhere in the middle of the hiring process, not at the beginning, so you know the company is already showing interest in you as a candidate before we ask for the time investment. We also offer a synchronous debrief with two members of our team, as you mentioned, so you can discuss how you approached the problem and describe any work you might have wanted to tackle but didn’t have time for. This helps prevent the feeling that we are asking candidates for this commitment indiscriminately or sending their work into a black hole.
While the synchronous debrief does take significant investment from our team, as long as we are selective about who we advance to each interview round, the time is manageable and is on par with what engineers would commit to other forms of interviewing. The one thing we might evolve as our resources grow is the tooling around the challenge: at the moment, we do a scheduled email send and just link to a GitHub repository, asking them to send back a zip file of code or open a pull request in a private repo. It’s a lot of fiddly work on both sides, and it might be nice to offer a more streamlined workflow.
Y: You've highlighted that engineers who deliver adequate solutions quickly provide more value than those who craft brilliant solutions slowly. How does product-mindedness influence this efficiency, based on your experience?
Emily: I love this question. I’ll add a caveat: I think at software startups, it’s usually better to deliver adequate solutions quickly than brilliant solutions slowly, but it may not be true in all environments. If you’re designing space shuttles at NASA, a brilliant solution developed more slowly may be the better (and more ethical) investment. That said, product-mindedness has an important role to play when we define what “adequate” is in our current context. Engineers often have their own sense of what’s adequate, but our teams really can only define “adequate” through customer feedback and through how the solution does or doesn’t meet the needs of our business. Teams have to be grounded in real evidence of business and customer impact; otherwise, they end up rapidly iterating new products into the garbage can. It’s that simple.
Y: In light of all the ongoing conversations around AI in software engineering, what aspects do you think we're not talking about enough?
Emily: I think not enough companies have acknowledged that the most common feelings many employees have about AI tools are overwhelm and anxiety. While there’s rightly a lot of excitement around these tools, employees also feel burnt out by change and concerned about the implications for their jobs. Many engineering teams are rushing to get AI coding tools (Copilot, Windsurf, Cursor) into the hands of engineers because they believe these tools will increase the team’s efficiency. While I agree these tools are enormously powerful, they won’t be successful in many workplaces unless more companies start providing a higher-level framework for how to use them well.
At Honeycomb, we started not just with policy but with documented strategy: why are we even investing in AI, what use cases do we think AI is good for, how do we expect it to change everyone’s jobs, and how do we evaluate its success? I think teams should also be educated on the ethical issues around AI and the pitfalls and biases in how they work, and the best practices for using them well. Without these sorts of guidelines, teams are deploying AI in situations where it might not be safe, or failing to deploy it in situations where it might provide a big win because they are not sure it’s appropriate. Putting these sorts of guardrails in place can actually help teams go faster and innovate more quickly at the end of the day.
Thank you Emily 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.