[FormhellFrom]

I really don’t see what’s wrong with an applicant saying “no”. Employers say “no” all the time! The paragraphs and paragraphs about small-business ownership and how you have to hustle and grind and have character seemed really odd to me. Your applicant didn’t want to do what you wanted them to do. Just move on?

[ip26]

I think the author was just a bit peeved after interviewing what he saw as the hardware equivalent of a software engineer who considers writing any tests beneath them, a job for someone else.

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

[FormhellFrom]

Someone else pointed out that nowhere did he list how much he was going to pay this guy. Horror stories abound about companies using “take home” application tests to get work done for free, I think it’s somewhat reasonable for the applicant to be wary about this.

[jcims]

>On top of that, my client was offering to pay this individual to do the work.

[FormhellFrom]

Yes, but /how much/ was the client offering to pay? This whole situation screams of someone trying to get a cheap deal, then getting mad when the attempted victim wises up. (This is pretty typical with loud-and-proud small business types, IME)

[Danieru]

How can one get a "deal" on "throw away interview tasks"? The requested tasks only existed to prove the candidates skill. Paying for the time was above all a method to justify the time usage and show seriousness on the client's part.

The only value created by the interview is the possible hiring of the candidate themselves. There is no room for profitability interviewing candidates "on the cheap".

[panicpanicpanic]

I think it matters whether or not the amount was explicit, that's not clear in the post. Also, based on the (inexplicably) one time the author mentions the candidate was Indian, it's plausible the latter was wary of being exploited.

[geofft]

But "verification engineer" is a separate specialty - much like "QA engineer" is a separate specialty. I didn't get the sense that the candidate considered anything beneath them, just that the candidate was looking for a specific job.