Services that automate the interviewing or vetting process benefit the hiring manager, but feel impersonal and disrespectful to candidates. (Isn't my time valuable too?)
In today's market you will likely see a large percentage of candidates opt out of the interview process when you send them an automated technical interview.
Can confirm, I bail if you ask any amount of time at all be put into a "weed out" exercise before even talking to a real person. If my resume's not enough to get you interested in a conversation, I'll look elsewhere. If you have that many candidates and you find enough of them equally interesting that doing this is necessary, I reckon my odds are terrible anyway, so it's just a waste of time doing work and not just not getting paid, but very likely not seeing any kind of reward whatsoever.
Moreover, if this is necessary, I kinda assume the pay is mediocre at best. If you knew how to get enough value out of me to be able to pay me really, really well, and if I look like a good fit for the job, then again, my resume ought to justify our talking. If any of that's not the case, then it seems like the pay's gonna suck or I'm just not a good fit, so I'm out either way.
I want someone who's fishing for me with a lure, not by dragging a huge net through the water. Seems like a better sign all around.
But, from an employer's perspective, resumes tell you very little about a candidate and are essentially worthless. The sole usable metric we get from them is years of relevant experience.
We respond with a questionnaire that gets us more uniform answers about experience and technologies used.
Assuming the above doesn't filter the candidate out, we move on to a 90 min max "take home" exercise. In our case, it's not a coding exercise, but that's not that important for this discussion.
Only if all of the above hasn't filtered out the candidate, do we move to a Zoom meeting. In the Zoom meeting, after an initial introduction, we do a few easy coding exercises. Like, reverse a string or sum the integers in a file easy.
A few notable things from this experience:
1. The number of candidates who struggle with the Zoom interview coding exercise is surprising. It's a lot higher than expected and almost all of our candidates at that stage have 2+ years of professional development experience.
2. The number of candidates filtered out by the "take home" exercise is very high. 85+%
We literally don't have enough time to talk to every candidate that applies with the right amount of experience. And, even if we did, many/most candidates on the market aren't good developers. Our signal to noise ratio is already bad. In that case, it would be terrible.
As a developer, I sympathize with your perspective. But you may be passing on some good opportunities by not being willing to "play the game" a bit. Some employers are indeed bad actors and/or terrible at hiring. But given the current market, even those making a valiant effort to do it well, due to sheer volume, are usually going to have an exercise of some kind.
We post our salary ranges up-front, don't want to waste anyone's time that way. We also put a ton of effort into a very detailed job description and application process. The hope is that the candidate can see the effort we put in and will be willing to reciprocate. If that doesn't end up being the case, we assume, like you, it probably wouldn't have been a good for anyway.
If you sent me a 90m(!) takehome non-coding test I would absolutely nope out of that process. You're not respecting your applicants time. At all.
Your funnel is steep because it has bullshit steps. And the only people coming through it are probably desperate, which is why your signal/noise ratio is "already terrible".
And, given that perspective, you'd probably be a bad fit, so no time lost on either side. :)
What kind of experience do you have hiring? If you have a better process, that has been proven over time to work, please share.
I'm part of a small group of leaders/owners from other development shops. We meet monthly to collaborate and learn from each other. Hiring is a frequent topic and I assure you that our steep funnel and perspective on candidate ability is not a unique experience, despite divergent hiring processes.
It is true that our process could be filtering out candidates who might otherwise apply. In that case, it's most likely working as intended.
>In that case, it's most likely working as intended.
You are very casual in claiming that there is such an intentional correlation between developers who are not willing to spend 90+ minutes on a non-technical prescreen with a 15% success rate and competent developers who can translate business needs into actionable steps. It's reasonable to say you are willing to accept that there are developers who are unwilling to go through this process, but to say you are filtering them out intentionally is needlessly contemptuous.
But, seriously, it's intentional in the sense that if someone is a fantastic developer, but can't appreciate why a process like this is valuable to them and us, then it's a good thing they aren't applying. I need our developers to be competent at development but also reasonable in their perspective on the give and take between a business and their employees.
It's deliberate that I don't want people with your perspective/attitude to apply. I don't want people who can't appreciate the others parties constraints. It's not going to be a good match in the long run. And that's true even if said person can code circles around our best developers.
The problem is, unless if you're paying candidates, I think you're selecting for a group of desperate people. Which is to say, I don't think that your process respects candidate's time. You talk about give and take, but all I see is take--"submit to our process or F off." Or enlighten me, what are you giving in the exchange?
To me it sounds like you needed some way to thin the stack of resumes, and this is the method you chose. I'm just skeptical that you're going to get a lot of quality candidates. How are you going to pull developers who are comfortable in their existing jobs with such onerous requirements? These are people worth hiring: they're competent, skilled, and don't need to find another job.
Though looking at your profile a little, I think the answer is clear: you don't try to. Rather, I think maybe what you mean when you say fit is "we filter for people who need this job so badly that they'll go through our hoops to get it."
perhaps its that a web dev shop can't afford to hire the best talent, so the that sort of a filter is useful.
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.
> [W]e do a few easy coding exercises. ... The number of candidates who struggle with the Zoom interview coding exercise is surprising. It's a lot higher than expected and almost all of our candidates at that stage have 2+ years of professional development experience.
>The number of candidates filtered out by the "take home" exercise is very high. 85+%
For a 90 minute take home exercise that I have to complete before I am allowed to speak to a human being, that is on average about 10 hours of work your company is expecting me to do, for free. And then I have to do a coding assignment afterwords anyways.
I will say that the fact that you post the salary range is good. This is the sort of time investment that would only be worth it for a top end salary.
Also, I wouldn't say it's "not allowed", just not the standard process. We have, for specific reasons at the candidates request, done a Zoom meeting earlier in the process.
Candidates are also encouraged to email us with questions and we put a lot of effort into being responsive and good communicators with the applicants.
Just out of curiosity, what do you mean when you say many/most candidates on the market are poor developers? Seems crazy that a majority of people applying for any position lack the requisite ability to actually fufull the positions requirements.
Wow! That's crazy. As a relatively Jr dev still early in my career, any recommendations for differentiating myself from those people on my resume/portfolio? I have a github, is that enough or are these people plagarizing github repos as well?
I think the frustrating reality is that it's usually not possible to tell the good from the bad at the portfolio/resume level, some kind of skills/competency test must be given.
I personally don't look at GitHub repos because I don't know how long it took to write that code. If it's great code, but took 4x to write than it should have, I wouldn't know. There are also a lot of applicants that just don't have much public in GH.
Finally, to be clear, I'm not saying they are all bad actors. I'm sure some are and the same for employers. Mostly a result of the current world economics.
In the past, we hired devs who could code well when given well defined problems, like you'd get in an interview process. But they struggled with the actual development work after we hired them. We put some effort into figuring out the disconnect. Turns out, one of the most important skills in our organization is being able to break down a business level description of the work to be done and turn it into discrete development steps. Also, need to have a good grasp of data modeling and how to change the model to support changes in the work requests.
So, those are the first two things we test. We give the candidate a description of the work to be done and ask them to interact with it. What questions would you ask the client and how would you break this down into stories/issues? Then, we give the schema of the existing database and ask them to modify it so the new schema supports the work requested.
Still very software development oriented, just not coding. We have more in-depth coding exercises later in the process.
I realize in some orgs, there would be a project manager or product owner of some type who would break that work down. And we have team leads who do the majority of that work. But for our org, devs who couldn't do this struggled to perform well in the development work too. So it became a skill that correlated to being able to succeed after hire.
I do understand that, but from my experience short coding tests give by far the best signal. We ran an experiment and found that actually not doing a pre interview and straight to code test gave us better results than interview then coding test.
Why? Because people tend to hire people with qualities like themselves, and overlook many things. It also then caused people to overrate/underrate the analysis of coding tests based on the previous interview (as they (dis)liked the person).
This also massively increased the diversity of our team.
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.
I completely get what you're saying. We've seen many candidates that have expressed the concern of "if I'm going to put X units of time into this, you should also put X units of time into this". A good approach of running a Litebulb interview is to offer to do it in a sit-down session over a call with the interviewer, or to do it asynchronously. When we did sit-down sessions, we offered candidates a choice to just go off and do it throughout the day, whenever they can find the time. 100% of candidates chose to do it async. As it turns out, trying to code something with an interviewer breathing down your neck wasn't a good experience and made them very nervous.
Note that it's an option, not mandatory, to do it async. If the candidate wanted to do it in a sit down session, then we prioritize making time for it to be there the entire session. The reason we offer this option is because devs that have busy lives often can't easily find a single consecutive multi-hour session to do an interview. They have full time jobs, and might have family obligations at home and over the weekends. Basically, the only way to actually do a full onsite interview is to take a day off work to go do the interview. We're giving the flexibility for the candidate to find a chunk of time here, a chunk of time there to complete the interview.
We tested this above approach, because just as you said, we did see a huge dropoff when we just emailed candidates the interview link. After we offered to hop on a call and to be available for support, we saw dropoff reduced to less than 15%.
Also, a good chunk of candidates that drop out of interview processes are senior engineers that can't be bothered with lengthy processes, which is fair. I wouldn't give a Litebulb interview to a senior engineer to begin with. Debatably I wouldn't give any kind of technical interview, actually. If they have decades of experience leading teams at big or high-growth tech companies, those achievements speak for itself. The interview process for seniors should be more geared towards finding a product-team-eng fit, rather than an evaluation.
> As it turns out, trying to code something with an interviewer breathing down your neck wasn't a good experience and made them very nervous.
That is the fundamental issue with technical interviews, because there is very little about that manufactured situation which is applicable to the candidate's ability to do the work. There are extremely few real-world coding situations that come anywhere close to the pressures felt while having someone hyper-analyze everything you do in real-time, particularly when that someone is responsible for deciding whether you're able to pay bills next month or feed your family next week. It's a needless, pointless and ultimately self-harming methodology that filters out exceptional candidates in favor of the most extroverted or arrogantly confident, which is a bizarre twist considering the most influential and game-changing coders are also famously some of the most introverted and "unusual" people.
On top of that, because we're all in dependency hell at this point, far more time is spent googling for framework errors that don't make any sense until you find that one undocumented command line argument that a single person posted deep inside a GitHub issue thread. 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.
> 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).
> The interview process for seniors should be more geared towards finding a product-team-eng fit, rather than an evaluation.
Please use your platform to spread this message to employers. I have increasingly been getting leads asking for some sort of automated testing, even when I bring 25 years of hands on and management industry experience. The tests typically require multiple hours of time investment, with no real guarantees. That's asking a lot.
Yes. If I’m going to put a large time and effort investment into interviewing I want an equal investment by the hiring team. We both need “skin in the game” so I know that they are semi-serious about hiring me.
Yup, our clients have brought this up with us as well, which is why we recommend they offer 3 choices for the candidate to do the interview:
1. Hop on a call, do the interview in one sitting together and share thoughts/questions
2. Hop on a call, make sure set up is smooth, prompt is clear, questions are answered, then candidate goes off on their own. Hop on another call later in the day to demo the solution and talk over design decisions.
3. Do it completely async, submit the solution whenever you have time
From what we've seen, this flexibility has simultaneously reduced dropoff rate and increased candidate experience, since we're catering to the candidate's needs. Some would prefer to do it face-to-face, others prefer to work on their own.
If I was a hiring manager with the actual time to do this I think what I would likely do is come up with a series of thought experiments and some actual technical tests for the candidate. Probably I would try to pick things that I did not (off the top of my head) know the answer to and exactly how to do it. And then I might try to go through with the candidate and see their thought process through the whole thing while also volunteering some of my thought process to try to solve it together.
The point would not even be to try to necessarily solve the problem itself - more just to see how I got along with them. Of course some people might freeze up when asked to do this, but I think that happens in any higher pressure interview environment. And if I do not know the solution off the top of my head either and am obviously even struggling in some parts myself I think that takes a ton of the pressure off of them to be a wizard that can solve it in the moment.
This makes a ton of sense to me. Seeing how you solve a difficult problem with someone collaboratively is a great insight on how you'll continue working together, because that's exactly what you'll be doing. It's also very valuable to see how someone receives suggestions or criticism and how they respond. We'd actually like to build a lot of these concepts into Litebulb, ie: responding to code review requests?
As an add-on, an interesting question one of our clients asks as a conversation starter is "what's the most technically complex project you've ever worked on?". This question sets up the space such that the candidate is the expert (since they've already worked on it), and it almost becomes a session where the candidate teaches the interviewer.
What matters most to me as a hiring manager is your ability to think critically. There's so much to know, and so many different permutations with how those things can present themselves that I'm not hiring you to know the answer every time. I'm hiring you to figure it out.
I wouldn't necessarily put it that way, primarily because some of our interviews require less than 20 lines of code! It's a bit more about selecting candidates with the right fundamentals. You don't need to write too much code, but the code that you do write, is it clean? Are you following best practices? Is it efficient? Have you thought about how your new service affects the rest of the system, and what the implications are?
I do agree though that some of our frontend interviews are a bit heavier on code + css and less on systems design thinking.
Btw just to clarify, we have a policy where we won't host any interviews that are just open dev tickets to build a feature that will be used in production. Like, we DO NOT tolerate companies using interviews to get free labor.
> we DO NOT tolerate companies using interviews to get free labor.
What does that change from a candidate perspective? In both cases the candidate wastes their time. I'd offer a better solution: the company pays market rate for the time needed for the test, and can then ask for anything they want - in which case an actual ticket is the best solution as it will evaluate the candidate's performance on the kinds of problems they'd actually be working day-to-day.
Have you taken a bunch of these and still gotten the same ghosting, empty promises, non communication and put in multiple hours of your time for free? I certainly have. The best interviews for me are where I can talk in depth about a topic and to a lesser extent, about a hypothetical problem and how I might handle it.
I tried a few of these with different companies. Each one has failed due to technical difficulties of the platform (in my case prerecorded video interviews) and in every case I tried to file a ticket and never heard anything back. Black hole.
In one case I did a prerecorded interview and they later contacted everyone because something went wrong and they wanted everyone to do it again.
I would have no problem with this as a 45min screen after having talking with a hiring manager. I’m going to invest that time anyway and it’s nicer to not have to “do it live”. There does need to be humans for the later rounds though - because I’m assessing the company as much as they’re assessing me!
Yup! That's why we recommend using Litebulb as a mid-funnel tool. Initial screening should be with a hiring manager (or a founder if it's an early stage startup), final meetings should be with team members/managers to get cultural fit. We just try to make the technical coding evaluation part easier.
I second this. What's worse is that being a devops guy, most coding interviews I've ever done are totally irrelevant to the roles I've had. In a good market I can avoid companies using services like this.
I built a very similar product 10 years ago and even back then we heard feedback like this. And I believe the situation may be more pronounced today.
There seem to be markets (or large enough organizations?) where coding job ads get a tonne of applicants, many of them inexperienced, and so automation is a good fit. But not when things are tipped the other way.
Our bet was for real-world tests too but it wasn't enough. A few things we missed that might help…
- Candidates don't want to be treated like cattle
- For many companies a good interview platform will be more beneficial than automation
- Companies say they care about the experience candidates receive, they'll say they're rigorous and try to be as objective as possible with the way they collate information and make decisions, they'll talk about how high their standards are, etc etc. Be weary
- There may be more gains to be made outside of the tech space
- The problem most companies complained about and is probably still the hardest: going out and finding people
I like the way you've solved the "real-world challenge" problem.
With COVID and the rise of remote working there are a whole lot of companies where the developers are the asset, the commodity, where those companies are just the middle-man receiving for the work the developers do and getting the big part of the cut in the process.
Those are mostly the "sweat-shops" that hire developers that can work for less for several reasons. I see that in this particular case this solution might be very welcome to assess new hires.
But for more high-profile jobs and companies, the company that eventually follow this path will probably end with low quality hires, unless of course it just create crud's anyway.
Because this is a self-fulfilling prophecy in the end. Once the candidates know what they will face, they will train until they get good in that game, which most of the time doesn't mirror the qualities required for the job.
Currently: candidate does a Litebulb interview, gets a report, that report can be shared with whoever they like, hopefully speeding up interviews at other companies.
Next up: candidate does a Litebulb interview, gets a list of actively hiring companies that use that stack and would like the candidate to be inserted mid-way into the interviewing funnel.
I've thought about this as well, the biggest problem here is that I have Github repos from 7 years ago with very, very, poor code quality, and also just a bunch of incomplete test repos. I wouldn't want that to lower the perception of my current skillset.
If I could select which repos to include, that could be very interesting.
Also interesting additions: open source contribution analyzer, Stack Overflow Q&A quality analyzer.
In today's market you will likely see a large percentage of candidates opt out of the interview process when you send them an automated technical interview.