The Interview That Ships to Production: replacing whiteboards with pull requests

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.

'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.

> 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.

> every keystroke, with millisecond timestamps

Finally someone has figured out how to hire accurately.

They are asking candidates to do work in their repo and taking it to prod? That feels odd.

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.