[gopalv]

> a software engineer who considers writing any tests beneath them, a job for someone else

I'd also balk at that for an interview take-home test.

I was an Indian QE guy looking for a dev job once. I was that guy whose job was to write tests for someone else, which wasn't fun at all.

If I had interviewed somewhere and I felt the conversation was going towards "how good are you at writing tests, write some", I'd have noped out of it immediately.

Specifically because testing was being offshored (think of the early 2000s) and development work was being held at HQ at my then employer.

I would expect that this work would be my day-to-day based on that interview.

That sort of "stale smell" around the job of writing tests for someone else's code stinks to say the least.

Right now I'm on the other side of the hill, I'd consider it a red-flag if someone interviews me for a day without asking me "review this code" or "analyze this design", but merely whiteboard a bunch of algorithmic C++ code without any tests.

[brandmeyer]

I can see why your experience might lead you to that particular bias. However, that's not where he's coming from. If you've followed his blog over the years, you'll see that he believes you cannot be a decent hardware engineer unless you also have some formal verification chops and use formal methods as part of your design methodology. That's his bias. He expects a practicing HDL engineer to write their own verification proofs.

[Danieru]

To expand on your point: the client asked him to evaluate. That he expects good HDL engineers to handle verification is thus also part of the client's requirements.

The client trusts him, not a theoretical average engineer but the exact specific engineer who has been successfully delivering results. The client wants another one of those HDL engineers who handles verification. The candidates rejection is indeed an impasse, such happens. Doesn't mean the candidate was wise.