Why the traditional engineering interview is a just shot in the dark.
There’s an elephant in the room when it comes to hiring engineers, that no one likes to admit: if the New York Times were to hire the way tech companies interview engineering candidates, they would be looking for master essayists by judging impromptu tweets.
Let’s be honest: tech companies are hiring half-blind. Furthermore, the pandemic and the world of all-remote interactions have compounded this problem to another level.
Hiring managers and interviewers already know if you can “clean code” or dream in algos, that you supposedly delivered a “launch-critical service deploying machine-learning models at scale to a billion users, 6 months ahead of schedule”, or that you were “a pleasure to work with” according to ever-friendly former PMs. Wonders of living in the era of Github, LinkedIn, and L33tC0d3.
What companies had a hard time discerning was, “will this dev be thoughtful about future-proofing a new service but also execute like a rocketship? Will this dev get up at 3 AM if a service goes down? Is there growth potential to his/her skillsets? How does s/he handle feedback? How does s/he handle disagreements, especially in technical decision-making”?
Even before the pandemic, these were extremely difficult issues. Final decisions are usually made within 3–5 interactions on imperfect information. It has become increasingly easier to peacock code contributions (everyone is a ❄️ Github Arctic Vault contributor these days 🙄), parrot the right jargon, and prep the hell out of l33tcode. As much as humanity benefited from more software developers coming out of the bootcamp-industrial complex and nouveau CS programs, hiring managers now face the unenviable challenge of finding needles in the growing LinkedIn haystack.
Then Enter COVID
Gone are the subtle, intangible, and unscalable sources of signals that you used to rely on — subtle cues, social mannerisms, the beer pitcher you shared after the interviews — maybe you sense leadership potential, or the candidate also loves Catan as much as the iOS Engineers play amongst themselves. We’re basically left with Zoom and CoderPad to determine if we could productively AND enjoyably spend more time on Slack with this stranger than with our own partners or families. Oh, and also, you have no option but to venture a guess on whether this candidate constitutionally handles remote work well.
When was the last time you decided to get into an indefinitely-long-distance 3–5 year relationship with someone after 3 FaceTime calls and it worked out to “happily ever after”? If this is you, please share your life tips in the comments below for humanity’s benefit!!
The rest of us are left wondering, could there be a better way? At Dataframe, we believe we’ve found that new path.
But first, why should you care or listen to us?
To give you some background, I co-founded and run the engineering team at Dataframe. We’re an exciting startup building “the home for your team’s data”, so that data producers like data engineers and analytics engineers could test and monitor the quality of their pipelines, and data consumers like data scientists, analysts, and ML engineers could write analyses or models more productively. I used to lead the engineering team at Bird (🛴 the scooter company that was the fastest company to reach unicorn status ever — $1B valuation in 18 months), and I’m bringing all the best practices from Bird to grow Dataframe with the same rapid iteration and product obsession DNA. (We’re actively hiring ;-) Scroll down for job postings)
We set out on this exciting journey to build a “Github for Data”, when we realized we could no longer tolerate the atrocious tooling around our data-centric work as data scientists and engineers. So to build this new sophisticated product category, we are always swamped with complex tasks, everything was due yesterday, and we need to make hundreds of explicit trade-offs per week. We feel this hiring problem very acutely because our single most powerful lever in this fight against chaos is hiring world-class engineers to build quickly.
Enter Trial Periods
For the first few steps, we do the usual song & dance, of course — light phone screen and technical screen. But we don’t break a sweat or over-analyze the candidate’s algos on CoderPad or LinkedIn.
But here’s where we diverge. Once you pass our preliminary screens, we offer a paid trial period — for 2 weeks, the candidate will work on real tasks with real coworkers on Slack with the same tools that they will use later on. We spend a few days on onboarding, then we assign a few manageable, isolated, but challenging tasks.
Instead of optimizing for Merkle tree implementations and Zoom chit-chat, the company gets 2-weeks at-bat to evaluate on the skills that will actually matter; on the flip side, the candidate, in addition to gauging fit with remote work or the colleagues, could also show off their inquisitiveness, openness, initiative, leadership, and thoughtfulness, all in long form. And in our experience, these are the magical qualities that make for engineers who grow over time, empathetic devs that grow into Product Managers, tech leads that command respect across technical functions, and raises the tide of productivity and morale across the team.
You could say, we are “trialing before hiring” just like how one would “date before marrying” — as high-fidelity a simulation as possible bears the best results 🤖
Of course, this process isn’t perfect; it’s a trade-off! In the spirit of building a tribe around this practice, we’d like to share an honest self-assessment from our own data.
- Both hiring manager and candidate get a much more accurate preview of what it’s like to work at Dataframe (technically + socially)
- Meaningful, semi-hidden truths get exposed over time:
One candidate from a large company asked thoughtful questions that showed off her general technical understanding in the first week, but she barely pushed any code. We realized that startup hustle and real output is one aspect we couldn’t compromise on.
- A million new factors come to life. Real testimonials from real candidates-turned-employees:
“I got to know the tech stack deeply in a low-risk way (didn’t feel like an interview!) and I think I showed off more positive aspects than I could have in an interview”
“I loved the flexibility to walk my baby in the morning and work late-night hours, and realized I could really get with this all-remote cadence”
“I didn’t have to put up any disingenuous faces and I felt so much more comfortable to be myself, code as thoughtfully and thoroughly as I usually do, and get to know my coworkers a bit better to overcome my usual shyness.”
- The candidate’s interest level must be sufficiently high to commit to a 2-week trial. This might disincentivize those with an exploding Google offer (or those with too many options), those candidates who arrive at decisions more slowly.
Our answer: we do not need “perfect-on-paper” or “Prom King” candidates; we believe this practice filters for the right candidates and profile for our company (which should fit most other companies!)
- Following the above drawback, the company bears the additional onus of drawing enough interest from candidates to convert into trials. This would require additional investment in better storytelling around the company’s mission, engineering challenges, and hiring ethos.
Our answer: we believe that it is a worthy investment to attract energy and talent, the lifeblood for creative companies like ours.
What do you think about the trial period? Please comment and tell us about your own experience, if any! We’d love to hear how this went for others.
Dataframe is Hiring 💻🚀
Dataframe is actively hiring talented Senior Product Engineers and Senior Backend Engineers. If you’re an elite h4ck3r and these hiring practices seem interesting to you, please say hello through Lever or learn more about Dataframe! 👋
For the right candidate, we’d love to go on a date. 😉