There is a way to make the campfire approach a little bit less utopian: California could pass a law that makes it legal to have a second temporary job. So that FAANG engineers for instance, would be allowed to campfire/interview at another company with legal protections. Put a bit of grease in the interview system is good for candidates.
the labour cost of having an intern/entry level engineer spend ~30-60s looking through these is likely close to $0.20
Did you do the math? Your estimate feels way off. First, I doubt an intern would process one PR in 30s. Maybe 2-3 minutes, to read 10 lines carefully looking for typos and indentation mistakes. We pay interns close to $100K these days (in a company like CloudFlare), so that's ~80c/minute. My estimate is therefore closer to $1.6 per PR. About 10X.
You are correct that there is a residual value with the intern, over time they would start learning (a little bit) about the code base.
$100k is probably at the top end. Even at Cloudflare, interns are more likely to be making $25-40/hour according to levels.fyi, which works out to $52-83k.
We all have had the client from hell: they don't know what they want, they change their requirements all the time. Whenever they have a new half-baked idea, I need to scramble and re-design the architecture. They have no clue that a small change request has a big impact on the code.
Well... Now I can be that client. And let AI deal with my incomplete, always changing requirements. And get it done anyway.
That matches my experience. At least on the solo front, there were so many topics I wasn't an expert on, that limited what I could build. Now with AI assistance, the sky is the limit. I don't need to be an expert in frontend, backend, I can just build on my personal expertise in a functional domain, and leverage AI to fill in the gaps. I believe many people will benefit from being to build exactly what they want, without gatekeepers or investment.
This paragraph from September 2025 didn't age well:
Like you, we have seen numerous reports that more and more firms are capping their total headcount in favor of leaning on more AI tools, leading to downsizing their intern and new-graduate hiring. [...] But we think this misreads the moment completely, so we’re heading in the opposite direction.
Correct (well, maybe not half a century, maybe 30 years or so). I was just about to reply that I'd love a version of this that shows instructions going in and out of a re-order buffer. That would be enlightening.
Well, how about the Berkeley Out-of-Order Machine [0] (BOOM)? It's superscalar, out-of-order RISC-V design (one of the very first ones, in fact), and the documentation is fairly detailed. Read [0] and [1] for the general introduction, and then move down to the "Core Overview" section in the left navbar: "Instruction Fetch", "Branch Prediction", etc.
Also, here [2] is another, much more detailed explanation of an O-o-O implementation of a very simplistic RISC ISA which nonetheless has most of the relevant RISC-V features. There are also some other related texts on this subsite [3], including a single-cycle and a pipelined implementations, for the comparison.
You're not wrong, but blocking assignments (and their equivalent in VHDL, variables), are useful as local variables to a process/always block. For instance to factor common sub-expressions and not repeat them. So using only non-blocking assignments everywhere would lead to more ugly code.
Good question. For a long time I think the justification was location: Microsoft is in Seattle, and it’s only the Bay Area that is getting inflated salaries.
It's not misleading for people in the industry. ARM so far was selling IP (Verilog source code) that other chip makers would include in a full chip design.
Now ARM for the first time (this century) is making its own chip [design], which like most of its customers, is manufactured by a fab like TSMC.
Similarly Apple doesn't manufacture any of its own computers or iPhones (it's all contract manufacturers like FoxConn) but it would clearly be wrong to say "Apple doesn't make computers! Foxconn does!"
Agreed, in my experience, rule 5 should be rule 1. I think I also heard it said (paraphrased) as "show we your code and I'll be forever confused, show me your database schema and everything will become obvious".
Having implemented my shared of highly complex high-performance algorithms in the past, the key was always to figure out how to massage the raw data into structures that allow the algorithm to fly. It requires both a decent knowledge of the various algorithm options you have, as well as being flexible to see that the data could be presented a different way to get to the same result orders of magnitude faster.
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
I have seen a huge decline in data first over the past decade-plus; maybe related to a lot more pragmatic training where code-first and abstraction helped you go faster, earlier but I definitely came of age starting with the schema and there are an awful lot of problems & systems that essentially are UI and functions on top of the schema.
There is a way to make the campfire approach a little bit less utopian: California could pass a law that makes it legal to have a second temporary job. So that FAANG engineers for instance, would be allowed to campfire/interview at another company with legal protections. Put a bit of grease in the interview system is good for candidates.
reply