Editor's note: this was originally posted as a Twitter thread by TalkJS co-founder Egbert. We iterate on our hiring process all the time so it may be different when you read this.

Our current dev interviewing process is the most effective one I've ever seen, and I'm very happy about it.

I think we mostly stumbled upon it by accident though, so figured it might be worth sharing.

tl;dr: we do a collaborative SDK design session and we learn so much

Text chat interviewing

First, as a fully remote company, we prefer text over calling. That's why only the first interview is a call, and the rest is 100% text-based. We stole that from Automattic (ie the WordPress people, who were remote a decade before it was hip).

The intro call is mostly to sell the job to the applicant, to be honest. Think ~20 minutes about our working culture (unusually high-trust, high-flexibility) and ~10 minutes talking about code (eg "teach me a feature of our favorite language"). ~1/3rd pass this round.

The 2nd round is a ~2-hour Slack interview. It's 100% text chat, and it feels a lot like our regular work chats. After a 30 minute non-technical talk about goals and dreams, we get to the technical meat, an SDK design discussion.

SDK design combines a lot of skills

We're an API company. For us, asking SDK design questions is natural - we nearly always have some open design challenges about to-be-shipped features so that's great talking material.
But we've been stunned much we learn from applicants. Doing SDK design during an interview shows:

• Can they describe an idea?
• Attention to detail, eg idiomatic code style etc
• Can they code? (example code, typespecs, etc)
• Can they collaborate?
• Can they empathize with other programmers? (our customers)

That list touches a remarkably large part of what we care about in a programmer! Even if you're going to end up scaling our infrastructure and not build public SDKs.

SDK design skill turns out to be a great predictor for architecture skill, communication, etc - the best we've found.

We do ask a tiny prep exercise to prepare for this round, mostly to force applicants to read through our docs so we don't spend interview time explaining TalkJS concepts. It takes applicants about 30 minutes.

• No studying algorithm books
• No whiteboard quizzes
• No leetcode

We started doing this systematically when we began to notice that we always had much higher confidence about our yes/no decisions when we had happened to ask SDK design questions. It just covered so much ground in such little time. It also meant we could cut out a third round.

It saves time for the applicant and for us. The thought of multi-day interview processes creeps me out - how does anybody ship any work if you do that?

That's it! Do you know any similarly powerful interview subjects? I'm pretty happy rn but I bet this can be way better still.

--

TalkJS is a Chat API with prebuilt UI components that lets you make a chat feature in no-time. Want to come build great SDKs and APIs? We're hiring!