Some companies do this and pay the candidate for their time, regardless of outcome. I don't think there's much to comment there. Some don't pay the candidate. In that case, it's just a predatory practice to take advantage of the tough job market.
Just my personal take on this, but I’d happily perform real work for free instead of sitting for leetcodes and behavioral questions. I struggle with those formats a lot but have no problems shipping in a realistic problem domain.
That tradeoff makes enough economic sense to me personally, but to each their own.
I do agree that companies flush with profit should be able to offer a stipend though, and unwillingness to do so is a signal I use to evaluate them.
Everyone prefers real problems. It's something you already know how to do instead of something you explicitly have to train for.
It doesn't change the fact that the real work could be an hour's exercise or longer remunerated work. This isn't an either/or scenario like you put it. Plus, for a fact, companies will happily have you doing both the leetcode and the take-home test.
I would never perform work for free. What if my work has a hidden oopsie that ends up causing problems later? What if the code review is lax, and a bug ends up hurting someone? Unlikely scenarios, but things I’d be concerned about.
'We are extracting free labour from employment candidates, it is great for us'.
Why not go a step further, and add a fee to become a candidate? Or perhaps just to skirt the queue and get to the front of the line?
Edit: Then there's the industrial espionage aspect but I don't really care about that, it's probably for the best if competitors and curious folks interview with them to learn what they have and how it works and undermine their business.
The "work an unpaid shift" interview is a common tactic of low-rent bars. It's very scummy.
In software, how much can you really get out of a human with a very small context who has no long term view or investment in the quality of the codebase? If you care that little, you'd just punt it off to vibe agents.
In the article they spend a lot of time explaining how they surveil and supposedly evaluate interactions with LLM bots, so I gather that's what they care about rather than inherent skill and personality of the candidate.
I've been interviewing some lately, mainly with organisations that have tight restrictions on non-EU-services. It has been nice, we've been able to talk about what they need, what I can do and how their team works together and interfaces with the rest of the organisation.
Eventually I settled on an offer from an organisation that handles a lot of sensitive information and runs a kind of 'factory' style process, so there'll be requirements reminiscent of old fashioned industrial engineering and exactly zero vibing at work, at least if the Security Service says my reputation is good enough.
> If you're the kind of engineer who reads the implementation instead of trusting the function name, we'd like to talk.
Functional decomposition, combined with good naming, is what allows engineers to raise the level of abstraction and localise understanding of a large codebase.
Without it, if your only option is "read the implementation" for every line of code, you've lost control of the codebase.
What you're saying touches on a real problem, but in this context it doesn't make sense. It's very normal to read implementations you're not already familiar with. Nobody has "lost control" in that scenario. It doesn't have to be the first thing you do - you should just trust the names and documentation when getting a big-picture view of the codebase, but eventually you should read the implementations.
It's healthy to not trust function names - it doesn't mean the whole codebase is out of control.
This is a much better signal of real engineering skills than memorizing whiteboard patterns. Reviewing actual pull requests shows how candidates think, communicate, test, and ship production-ready code.
There are “a few odd” things here. It is not entirely clear if this is sort of a rage bait blog post as well. What looks to me they do not even care if you are good “engineer” rather look for prompters and then use their contributions to improve their own platform; many of us have automation templates for that which would be difficult to replicate. I am not even talking about the mention of JS to do that, like sure it is easier because your platform does not need to compile, but if they move huge amounts of money and JS is actually used for it, you’d expect someone to understand how VM interprets that code etc. IMO it is possible (such interview practice) purely because it is a tough job market now.
I think a better model is likely building a full dummy repo and operating within that.
It’s now trivial to extract a toy app that is a dummy version of your product system, introduce a sprinkle of bugs, write ok documentation etc - and then spend an afternoon with each candidate building in it. This was way too much work to be practical pre-LLMs but I think it’s very doable now.
The problem with having them work on prod code is it will (hopefully) get thinner for real example cases for candidates.
"All rights reserved." "Use or linking of code to other code leads to the usual unrevocable and perpetual full rights to redistribute and relicense and so on and on..."
Would be the most fair ground rules to set as candidate.
Some companies do this and pay the candidate for their time, regardless of outcome. I don't think there's much to comment there. Some don't pay the candidate. In that case, it's just a predatory practice to take advantage of the tough job market.
Just my personal take on this, but I’d happily perform real work for free instead of sitting for leetcodes and behavioral questions. I struggle with those formats a lot but have no problems shipping in a realistic problem domain.
That tradeoff makes enough economic sense to me personally, but to each their own.
I do agree that companies flush with profit should be able to offer a stipend though, and unwillingness to do so is a signal I use to evaluate them.
Everyone prefers real problems. It's something you already know how to do instead of something you explicitly have to train for.
It doesn't change the fact that the real work could be an hour's exercise or longer remunerated work. This isn't an either/or scenario like you put it. Plus, for a fact, companies will happily have you doing both the leetcode and the take-home test.
I would never perform work for free. What if my work has a hidden oopsie that ends up causing problems later? What if the code review is lax, and a bug ends up hurting someone? Unlikely scenarios, but things I’d be concerned about.
I don’t understand how those concerns are alleviated having been paid
If it’s paid, I understand the limits and liability.
i cant imagine wanting to operate code written by said interviewees
it seems like such an obvious target for the likes of north korean saboteurs.
Interships already exist as "doing work as an interview"
'We are extracting free labour from employment candidates, it is great for us'.
Why not go a step further, and add a fee to become a candidate? Or perhaps just to skirt the queue and get to the front of the line?
Edit: Then there's the industrial espionage aspect but I don't really care about that, it's probably for the best if competitors and curious folks interview with them to learn what they have and how it works and undermine their business.
The "work an unpaid shift" interview is a common tactic of low-rent bars. It's very scummy.
In software, how much can you really get out of a human with a very small context who has no long term view or investment in the quality of the codebase? If you care that little, you'd just punt it off to vibe agents.
In the article they spend a lot of time explaining how they surveil and supposedly evaluate interactions with LLM bots, so I gather that's what they care about rather than inherent skill and personality of the candidate.
I've been interviewing some lately, mainly with organisations that have tight restrictions on non-EU-services. It has been nice, we've been able to talk about what they need, what I can do and how their team works together and interfaces with the rest of the organisation.
Eventually I settled on an offer from an organisation that handles a lot of sensitive information and runs a kind of 'factory' style process, so there'll be requirements reminiscent of old fashioned industrial engineering and exactly zero vibing at work, at least if the Security Service says my reputation is good enough.
> If you're the kind of engineer who reads the implementation instead of trusting the function name, we'd like to talk.
Functional decomposition, combined with good naming, is what allows engineers to raise the level of abstraction and localise understanding of a large codebase.
Without it, if your only option is "read the implementation" for every line of code, you've lost control of the codebase.
What you're saying touches on a real problem, but in this context it doesn't make sense. It's very normal to read implementations you're not already familiar with. Nobody has "lost control" in that scenario. It doesn't have to be the first thing you do - you should just trust the names and documentation when getting a big-picture view of the codebase, but eventually you should read the implementations.
It's healthy to not trust function names - it doesn't mean the whole codebase is out of control.
> every keystroke, with millisecond timestamps
Finally someone has figured out how to hire accurately.
Funniest comment in this thread :-D
They are asking candidates to do work in their repo and taking it to prod? That feels odd.
The repo in question is for the take home exercise that candidates go through.
Aren't there tons of scam interviews these days where there is malware in the build script of their repo of the take home exam?
Damn, I knew there was a risk of spam and identity fraud but I hadn't even considered this.
26 years since I started being in this game - how I hate the "take home exercise".
Unless they're compensating people, and chose not to mention it, this is just a confession to failing to pay the minimum wage.
This is a much better signal of real engineering skills than memorizing whiteboard patterns. Reviewing actual pull requests shows how candidates think, communicate, test, and ship production-ready code.
There are “a few odd” things here. It is not entirely clear if this is sort of a rage bait blog post as well. What looks to me they do not even care if you are good “engineer” rather look for prompters and then use their contributions to improve their own platform; many of us have automation templates for that which would be difficult to replicate. I am not even talking about the mention of JS to do that, like sure it is easier because your platform does not need to compile, but if they move huge amounts of money and JS is actually used for it, you’d expect someone to understand how VM interprets that code etc. IMO it is possible (such interview practice) purely because it is a tough job market now.
I think a better model is likely building a full dummy repo and operating within that.
It’s now trivial to extract a toy app that is a dummy version of your product system, introduce a sprinkle of bugs, write ok documentation etc - and then spend an afternoon with each candidate building in it. This was way too much work to be practical pre-LLMs but I think it’s very doable now.
The problem with having them work on prod code is it will (hopefully) get thinner for real example cases for candidates.
I don't buy it.
How can an engineering team say they have a good process if they don't measure the results of the process?
Sure, you can make a lot of logical leaps, but what does it actually produce?
How does this compare to hiring by randomly picking a sufficiently good-looking resume?
"All rights reserved." "Use or linking of code to other code leads to the usual unrevocable and perpetual full rights to redistribute and relicense and so on and on..."
Would be the most fair ground rules to set as candidate.
I miss reading things written by humans.
Digital: https://libbyapp.com
Analog: https://bookshop.org
[flagged]
[dead]
[dead]
[dead]