Part 1: Job hunting, recruiters, interviewing, and the technical screen
Maybe you’ve recently left a job. Maybe you’re thinking about leaving a job. At this time last year I was coming to terms with the fact that I needed to make a change in my professional life. But even when you have the power to make that decision yourself and the need to make a change is clear, it is neither an easy decision to make, nor does it have a clear path forward.
There are an enormous number of questions that come with a job change and a significant amount of uncertainty. How do you decide when it’s time to go? How do you optimize around questions of compensation vs. work culture or personal happiness and fulfillment and is it possible to find a perfect balance? How do you manage your time while you’re on the job market? How do you prepare for the interview process?
Let’s break it all down, step by step.
Despite the recent high-profile layoffs at FAANG(+T?) companies, we’ve grown so accustomed to the dominance of the “prestige” firms that it’s easy to assume if you haven’t heard of a particular company before their recruiter contacts you, it means the company cannot possibly be offering the sought-after combination of stability, great culture, and competitive compensation. But software engineers remain generally in demand. This is especially true in health-tech, an industry that is projected to continue growing over the decade:
At the beginning, I wasn’t sure where to look, but I knew I didn’t want the FAANG companies and it didn’t occur to me to look at health-tech. My first steps were to reach out to my Linkedin network for ideas and to start saying “yes” to recruiter notes in my LinkedIn inbox.
It’s hard to get to know a company through a cold application, so I prioritized finding unique personal perspectives to help orient me. I narrowed my search to a few industries: crypto (for the fun of the numbers and modeling, even though I knew it to be a high-risk industry), and hedge funds (for the compensation and because I was already working in finance, even though I knew it could be a blow to the happiness factor). There was a third category of miscellaneous companies that just “seemed interesting” based on how they described their work.
I spent several weeks talking to recruiters at 20–30 companies before focusing on a small handful. This narrowing was assisted by a couple recruiters who were particularly open, honest, positive, and not pushy during the process. They were not just interested in “placing me,” they clearly wanted me to find the best match. Talking to recruiters didn’t just provide insight into individual companies, these conversations also helped me understand the hiring process better. A couple really great recruiters broke down the steps for me in detail and took the time to explain how different companies approach each stage of the process.
The process will invariably get messy. It’s ok.
Organizing the interview process
When you’re in a state of hyper-applying, you’re bound to have the problem of overlapping interview processes. After understanding what the standard hiring process looked like, I realized this would be a significant time commitment, especially while working a full time job. I decided the only way to keep up was to become my own project manager:
My organizing template was like a Kanban board where I copy/pasted rows from top to bottom on a LibreOffice ODS sheet. No need to use proprietary software (i.e. your job tools); there are plenty of free, open source tools out there.
The onsite interviews are the most time-consuming step. I had 10 days of vacation left (…is it too soon to mention that Datavant offers unlimited PTO?), and decided to commit them all toward taking onsite interviews.
Two big takeaways from recruiter conversations and my mini-foray into project management:
- You never know where critical information will come from, so approaching recruiter conversations with an open mind is key.
- It’s useless to try to force a neat organization of these overlapping timelines. The process will invariably get messy. It’s ok. Line it up on a high level, but don’t try to micromanage the individual steps.
I was nervous about my “skills.”
Preparing for the interview: to LeetCode or not to LeetCode?
Nearly all engineering interviews have a technical step. In order to “be efficient” at this stage, many companies turn to LeetCode’s list of 2,552 problems and pick a few to throw at engineers. They may not be exactly the same questions, but the variation is small enough that the problems are virtually the same, things like finding the longest common subsequence with dynamic programming, or traversing graphs with the same set of commonly used algorithms. Because this is something of an open secret, engineers in turn think they need to practice these kinds of interview questions like they are preparing for the SAT.
I was no exception. I was nervous about my “skills” because I hadn’t done these kinds of problems since I was in school. So I paid around $40 to practice LeetCode questions for a month. It felt like an action step, a sign of commitment to my seriousness around my job transition, something concrete I could do to prepare myself for the unknown. After a few technical interviews, however, I realized that my well of experience was deep enough from my working life that even if I wasn’t “fresh” on a particular problem, I could figure out how to solve it in the moment. Also, it’s crazy to think that while you are still in a job, AND managing a potentially complex interview schedule that you are ALSO going to practice a significant subset of the 2,552 questions you MIGHT encounter. In the end, I only practiced 4 LeetCode questions (…that’s $10/question, for those of you who are keeping track).
The other truth is that recruiters for in-demand skills have a hard job. Often, recruiters are incentivized to speed up the hiring processes, and in several of my interview processes, the technical component was skipped altogether. On the one hand, this made my application process easier. For those that skipped this step it meant less of my personal time that I had to commit to a company I may or may not eventually work for. But on the other hand, it also left me wondering if I wanted a company to skip their technical interview with me based on a couple of conversations we had. Were the engineering teams at these companies ones I actually wanted to join?
There is a space to grow at Datavant, and we want people who want to be in that space.
Datavant’s interview process
As I mentioned, it had not occurred to me to consider health-tech specifically, but my first contact with a Datavant recruiter was convincing enough that I agreed to enter the process. It seemed like the Datavant recruiter was reaching out to me specifically based on my background and experience, and not because I had been swept up in a [location, skills, years of experience] algorithmic dragnet. Because I had never heard of Datavant, I fell into the easy assumptions that the compensation probably wasn’t very good, or that the level of the team probably wasn’t very high. Initially, I regarded the Datavant interview as one of my “practice” interviews, a chance to hone my story ahead of my “real” interviews.
Like many engineering interviews, Datavant’s interview process has a series of steps and can unfold over a couple weeks.
My first interviewer spoke with me from abroad, which signaled to me that at the very least Datavant is committed to the flexibility promised by a remote-first workplace. In my first rounds of interviews I knew very little about PHI and HIPAA and how these related to Datavant’s technology, so I asked a ton of questions. I worried, in fact, that I was asking too many questions. Now that I’m on the other side of the interview process I can say that I love interviewing candidates who have done enough homework to have a sense of what they don’t know and are curious about how their skills might map to our mission. Datavant actively seeks people who consider themselves life-long learners. There is a space to grow at Datavant, and we want people who want to be in that space.
Datavant’s Technical Assessment: a debug
When I got to the technical stage of the process, I was completely rethinking my initial position on Datavant. Datavant’s first technical assessment is a debugging session. This both surprised and delighted me, as I had not seen this in any of my other interviews. A debug is not an arbitrary hoop to jump through like a set of LeetCode problems. It takes sincere effort to design a debug well and hit the sweet spot of just the right amount of challenging.
Your experience as an engineer, your problem solving capabilities, your curiosity, and your ability to articulate your thinking is all you need to bring.
Now that I’m the Engineering Chief of Staff, I can say that we don’t use LeetCode questions for a few reasons. First, we want to test people in tasks that resemble the tasks they would actually perform on the job: can you come into a codebase, understand it quickly, and succeed at adding fixes? Second, we think the debug offers the interviewers more opportunity to understand a candidate’s thought process and to discover if a person can think with both specificity and flexibility. We are less interested in people who are able to memorize answers to standard problem sets.
During my debug, I talked myself through every step, verbalized every observation and decision, even seemingly silly ones, because I wanted the interviewer to fully understand my approach and my process. In essence, I wanted the interviewer to be able to read my mind. Throughout the interview, I kept mentioning how happy I was about how similar this looked to my job at the time. Debugging is a puzzle that helps both learn more about the system and improve deductive reasoning. I’ve enjoyed doing it in the scope of my job and this process was an extension of that.
If you’re worried about studying algorithms and data structures ahead of the Datavant debug, I’m here to tell you that you don’t have to bother. Your experience as an engineer, your problem solving capabilities, your curiosity, and your ability to articulate your thinking is all you need to bring. Also, if you’re uncomfortable with performing a debug in a live interview setting, or if you simply can’t carve enough hours out of your work day, we also offer a take-home project via Woven as an alternative.
The debug is paired with a “behavioral” interview. By the time I arrived at this step, I had stopped thinking about the process as an “interview process.” I was thinking of it as a conversation with the person interviewing me. I felt I could be transparent and openly share my frustrations with projects I was working on and why I wanted to leave my previous job. Coincidentally, a lot of the frustrations I shared focused on how it seemed my team was prevented from getting things done…
Datavant is for people who find coasting boring
If I take a step back, I see that coming to the realization that I had given up at my previous job was a gradual process. I noticed it was nearly impossible to push ideas forward, even if they were ideas we knew would be highly profitable ones, and even if my team knew we could execute on them over a short timeline. It began to feel like our assigned project schedule was designed to keep us in our place and at a particular pace. New projects would dovetail onto the ends of old projects with a precise rhythm that obliterated any sense of individual autonomy. I called the result of this, “learned hopelessness.”
Datavant hires people who are smart, nice, and get things done. If I’m going to be completely honest, I was very skeptical of Datavant’s culture at the beginning. (I’ve been in industry long enough that I’m wary of “corporate cultures” in general.) I half expected Datavant to be yet another example of a place that outlines high ideals but doesn’t practice what it preaches.
Now that I’m inside it, and indeed a steward of it, I find that the energy Datavant focuses on its culture is substantive and meaningful specifically because Datavant maintains such a simultaneous focus on individual autonomy and critical thinking. There is ongoing discussion about our culture and how we are collectively maintaining it. We take a default stance that feedback is a gift, we look out for biases and instances where bureaucratic structures get in the way of getting things done, and we work together to figure out how to improve things. This approach has not only improved my career growth, but my personal growth as I find “get things done” has become a mantra that helps prevent me from drifting into procrastination!
I would argue that this careful and intentional cultivation of a culture places Datavant in a rarefied cultural Goldilocks zone. It’s a narrow bandwidth that is difficult to stay in, particularly while a company is growing, because it demands a high level of agreement on exactly what the culture is (crystallization) and continuous investment from the people inside of it to maintain it while also interrogating it (intensity of practice).
Fighting to keep us in the Goldilocks zone is a part of my work here that I’m quite proud of. It’s a marker of our high expectations and the degree of autonomy we expect our teams to maintain.
Does this sound interesting? Get on a call with a recruiter.
This is the first in a series of posts about interviewing at and joining Datavant. In the next post in this series, I’ll talk about my experience at Datavant’s onsite interview.
By Carlos Guzman, with input from Nicholas DeMaison and Alicia Loewenthal.
Carlos Guzman started as an IC Engineer at Datavant in May 2022, became an Engineering Manager in July 2022, and is now the Engineering Chief of Staff. Read more about his journey here, and connect with Carlos via LinkedIn.
Nicholas DeMaison writes for Datavant, where he leads talent branding initiatives. Connect with Nick via LinkedIn.
Considering joining the Datavant team? We’re hiring remotely across teams and we would love to speak with any potential new Datavanters who are nice, smart, and get things done, and want to build the future tools for securely connecting health data and improving patient outcomes.