garyjlin

It's idealistic and naive to say that we'll replace the entire onsite interview, and I wouldn't even recommend we go in that direction. What we're trying to do is clear out the technical evaluation part of an onsite so that there's more time for engineers to have insightful conversations with the candidate, and to get to know them more as humans and potential colleagues. If you're spending too much time with a candidate staring at a whiteboard going over code, you don't have enough time to gauge culture fit.

However, because we're still early, it's not fair to ask clients to chuck out the tech eval part of their onsites, since we haven't proven effectiveness to them yet. So instead, we'll replace whatever they use mid-funnel, and also early funnel auto-interviews. We still recommend someone talk to the candidate both before and after the Litebulb interview.

I think you make a good point here, you're right, because leet code style interviews don't work for most companies, but they do work for some companies with specific needs. I recently spoke to a prospective client where they mentioned they need a quick way to filter through hundreds of candidates pre-funnel and they only want to know if they can write basic code. If you can write basic code, you pass and your resume gets a look. They specifically didn't want anything too deep or difficult. I actually recommended that they use a tool like HackerRank or LeetCode instead of us because it made more sense for their use case.

This is exactly the problem we're trying to solve for. You have too many candidates, you want to be fair to all of them, but you don't have the resources to manually talk to every one of them one by one. You could give them a LeetCode-style auto-test question, but that's not much better than flipping a coin on every candidate. You could also use a service like Karat to do the interviews for you, but before you know it you'll be out $200K. Give them a Litebulb interview, let them do it on their own time, everyone that pushes up a solid solution gets scheduled for a call.

Yeah we generally discourage users from using Litebulb as a "weed out" exercise, first of all because we just don't agree with that practice as a principle, and second because Litebulb is a terrible pre-screening filter. As a pre-screener, the only people Litebulb would filter out are the good devs that have options. ie: if I have companies A, B, and C that I want to check out and C needs a multi-hour take home before I even talk to someone, you can bet your ass I'm not applying to C.

That's not what Litebulb is for though, we're mid/late funnel. As a candidate, if I have to choose between a 4 hour onsite or a 5 hour take home, I'm probably going to do the take home.

In terms of pay, I know some really good companies with a healthy eng culture and heavy pay that do take homes (not as a pre-screener, for sure).

Btw from my experience, resumes are a pretty weak indication of skill. I have interviewed people with 15+ years of experience, some at MAANG, that couldn't comprehend basic systems infra scenarios, and I've interviewed interns that had production-grade code. You need to actually try it out, one way or another, to be sure.

> If you want to test someone's ability to do the real work, then give them an obscure error code from a little-used utility and see how long it takes to find the fix.

This is actually a type of interview we're trying to support! A blocker right now is that once it's leaked, you basically have to throw the interview away. The good part about the "feature building" type interview questions is that it almost doesn't matter if the prompt + codebase is leaked, because your solution is probably still not optimal. "Good code" is super subjective and takes years of experience/learning to master, but an obscure bug fix shifts the end result to a boolean state, which is easy to leak (thus hard to detect plagiarism).

I completely agree, our marketing message needs to hammer in the concept that a Litebulb interview is pretty much just picking up a ticket off the backlog. We've actually had candidates say that halfway through an interview they forgot they were in an interview.

Also, the biggest problem prepping for tech interviews is that it's a different vertical of skills you're optimizing on. As you said, getting better at LeetCode doesn't necessarily make you a better engineer for the specific job you're being hired on to do. One of our goals at Litebulb is that if you're a good dev, you shouldn't need to prep for any Litebulb interviews. If you do prep, all you're doing is making yourself a better developer in general.

Really appreciate the support here and you make some excellent points! We're trying to make something that already exists just a bit better. :)

1. That point is actually one of the reasons behind Litebulb! For most LeetCode-style tools, getting 100% is easy if you just google the question, copy the top answer, then change up a few variables. For Litebulb, a legitimate submission has multiple commits, so when we do git history matching, no two legitimate submissions will have the exact same commit history, which means submissions either have a <5% or >95% match. The >95% matches are plagiarism and will be flagged.

2. Litebulb is meant to replace the initial LeetCode question + the mid-funnel technical screen. We still recommend doing a hiring manager screen at the beginning and team onsite at the end, but using Litebulb correctly should lessen an engineer's interviewing burden, not increase it.

Thank you! Data science interviews are definitely on our roadmap, but unfortunately we won't be able to get there within the next quarter. Biggest reason for this? Nobody on our team has data science experience! I'm not going to pretend like we know how to interview data scientists when none of us actually have the experience, but we will be spending time collaborating with (if not straight up hiring) a few data scientists to help build out our first few DS interviews.

I certainly hope so too! And yeah getting to know the team is really important as well.

Yeah this is actually why we recommend liberally-timed take homes instead of a sit down 45 minute block. It's super frustrating to get 95% of the way there just to be cut out by time.

Great set of questions!

1. Complex cases:

We can spin up isolated AWS or GCP environments with some resources pre-filled, and the rest is up to the candidate to build. Basically a systems design whiteboard challenge, except instead of a whiteboard, it's actually in a cloud environment. Since "input" will be defined, and specific "output" will be expected, we can then run tests against this environment to test for sufficient robustness. For example, if the prompt is to build a load balanced CRUD api, we can run create resource a million times, then try to read, update, or delete, and measure total response time. For something like testing concurrency safety, we can run a bunch of parallel threads attempting to access the same resource, then test for timeouts (deadlocks) and inconsistencies.

2. A solution that's code complete but has a minor bug that prevents compilation

For a solution like this, code completeness scores are unfortunately going to be 0, simply because there's no way to test for functionality, performance, event logs, if it doesn't compile. However, our static code analysis will still work, so they may still get high scores on code style, code complexity, naming, etc. Something we might be able to add is a way to flag to employers that a submission has high scores for everything except a specific metric, and so we'd recommend manually diving into the code.

3. Cheating

We can't prevent cheating if the candidate gets their roommate to do the interview for them. However, if someone just blatantly copies an old solution their friend sent or they found on the internet, we can check for that. We can run a diff between the submitted git history and all previous submission's git histories. 2 legitimate final solutions might be close (ie 60-70% match), but you'll never have 2 organic git histories with multiple commits be close, (it'll pretty much be either 0% or 100% match). Looking things up on the internet isn't considered cheating, I don't know of a single dev that could survive the day without SO :D