A Friendly Dialogue: An Overview of Broadlume Engineering’s Interview Process

Sekhar Paladugu
Broadlume Product Development
6 min readMar 31, 2021

--

As one of the longest-tenured engineers on the Broadlume team, I’d like to say I’ve had special insight into our technical hiring processes here. My colleague Ian Ker-Seymer and I both have been with Broadlume since the seed-stage startup days.

Heading into my sixth year at Broadlume, I know we’ve had a healthy, consistent approach to building our team via our hiring processes. While the company has gone through many changes and iterations, particularly during the turbulence of the pandemic era, one throughline has remained constant. Broadlume Engineering focuses on hiring humans with practical technical skills alongside a healthy emphasis on pairing and collaboration.

A Zen Buddhist rock garden. The perfect place to contemplate a beginner’s mindset.

Our team’s mantra is “the beginner’s mindset,” a concept originally from Zen Buddhism. Broadlume engineers strive to approach all situations in the workplace with openness, eagerness, and a lack of preconceptions.

At Broadlume we treat engineers and non-engineers of all skill levels the way we’d like to be treated and solve problems together without judgment. As we seek to grow our engineering team over this coming year, these practices will continue to influence our hiring process as well as our organization more broadly.

First Interview: Intro People Team Call

Our current interview approach starts with a phone call with our Broadlume Talent Acquisition Manager Jyllian Shepard. Jyllian begins the interview process with a standard roughly 30-minute call with the candidate. In the past, hiring managers, other team members, and even the co-founders (back when I first interviewed) have done this phone screen with potential Broadlume employees.

The goal of this call is to get a general sense of what you as a candidate are looking for in a new engineering role, what your past experience was like, and answer any questions you may have. With a basic sense of a mutual fit, the candidate will progress to the next stage.

There are not any technical questions or other long-winded projects or exercises designed to “weed out” candidates at the outset of our interview process. Broadlume just hopes to have a pulse on the candidate before moving further and also allow the candidate to interview us and determine whether they themselves do want to continue the conversation further.

Second Interview: Intro Engineering Call with Teammate

With the second interview, a prospective Broadlume engineer would meet with a current member of the team for a conversation about background, mutual fit, and technical topics. While some teams may emphasize “culture” in a way that can be fuzzy and undefined, for our team we want to get a sense of what professionally makes you tick, what you enjoy working on from a technological standpoint, and how you wish to grow as a developer.

This team call will often have a candidate talk through past challenges they had on the job (or equivalent settings for junior candidates) both technically and otherwise. Another topic I personally like to focus on is hearing a candidate speak about a library or tool set they’re passionate about, or other code-related topic they really enjoy. Some sample topics might be:

  • Why do you love working in TypeScript?
  • Why was building out the permissioning system for your prior company ultimately your favorite recent technical project?
  • Who has been the best mentor you’ve had as a software engineer?

I still remember the conversation I had with both my current boss Ian Ker-Seymer and early Broadlume (formerly AdHawk) colleague Diego Watanabe. We talked through my goals as a young developer and my experiences at coding school. I spoke about the challenges I faced coding a reporting dashboard as a contractor in SQL and Ruby on Rails at the time.

My second interview with Broadlume was a thorough give-and-take and did not feel like I was grilled on “gotcha” technical questions. Through this conversation and the third and final interview, I also was able to talk about my process when coding and how I build out a project on a granular level. The third interview which followed even allowed each party a chance to test drive coding together and ask questions of each other’s individual process.

Third and Final Interview: Technical Exercise with a Teammate

My technical interview five years ago was a core reason why I joined the Broadlume team. Back when I interviewed, I did a Google Hangouts interview where my soon-to-be colleague Ian Ker-Seymer shared his screen and we paired on a text editor. Our goal was to build a mailer that sent an email to a customer about resetting a password, and we spent much of our two or so hours together writing a spec to test that in Ruby and then passing that spec.

I found a pairing-oriented interview (with a healthy dose of test-driven development) to be an awesome way to gain insight into how the codebase functions and what collaboration would feel like with a potential colleague. This interview served as a great way to ask questions and interact on practical challenges instead of arbitrary or esoteric questions. While data, structure and algorithm-oriented topics definitely have their place and influence how I code at a high-level, a pairing interview is a much more accurate way to gauge a candidate’s skill in our experience.

Pairing and similar exercises also allow a candidate to see how it would feel working with a potential teammate. One similar exercise we have built from scratch that emphasizes that is a pull request review technical interview. Together with a Broadlume engineer, the candidate reviews a preexisting mock pull request against a codebase. Together the engineers (potential teammate and candidate) write GitHub comments, talk about the pros and cons of various approaches, and leave feedback for a hypothetical teammate about a pull request.

For those of us in the field in development work, we know more and more over time that pull request reviews are a critical part of the software engineering life cycle. A mock pull request review exercise has been an excellent way to interact for both sides and understand how we approach coding and collaboration.

Overall I felt quite comfortable after my final interview with Broadlume. The technical exercise allowed me to get a solid sense of working with my soon-to-be colleague Ian, who later become a close friend and my main mentor (and now boss) here in the workplace. Even just our handful of hours together pairing was a representative sample of what working together over the past five years has been like. I’m grateful I got a chance to myself interview the team before joining to validate my decision to join the Broadlume team.

Our Team Philosophy

Overall the Broadlume Engineering team is focused on hiring developers from all backgrounds, with an interview process that doesn’t waste time and that focuses on technical topics in a practical way. We like to get to know the human behind the resume.

I hope this overview has given you a sense of the beginner’s mindset approach to hiring Broadlume has developed. I know in my personal experience having a sense of what an interview process entails helps ease any anxiety throughout the process.

If our team’s approach to work interests you, please check out our list of open roles and reach out, we’d love to talk further about opportunities at Broadlume. We expect additional open technical roles to appear over the course of the coming year. Feel free also to contact us at the recruiting inbox at careers@broadlume.com if you have specific questions regarding our hiring process or would like to share their resumes for future roles that are not live on our website.

--

--

Sekhar Paladugu
Broadlume Product Development

Remote Software Engineer at Broadlume, Stay-at-Home Dog Parent, All-Around Nerd