> The response from this individual rather shocked me. He said, sorry, but I’m looking for a design job, not a verification job. This shouldn't have been too s

> The response from this individual rather shocked me. He said, sorry, but I’m looking for a design job, not a verification job. This shouldn't have been too shocking. In the digital design industry, design engineers and verification engineers really are different positions. They require different skills, and though there are people who can do both well, they haven't been interchangeable for a few decades. I'm not surprised that an applicant for a design position would decline a verification job, especially if they're not just looking for an entry point at some prestigious team like Apple's CPU group. The strange thing is that finding a bug and "fixing a broken design" is a design task, not a verification task. The verification engineer creates the simulation testbench and the tests to expose bugs. The design engineer uses these to find and fix the bugs. I doubt that most design applicants would balk at being asked to find and fix a bug in an existing design. So I'm not really sure exactly what he asked the interviewee that got the response he claims. > One of the realities ingrained in the history and culture of Gisselquist Technology is that simulations rarely find the critical bugs. This statement is so wrong that I think the author must have decided to redefine "critical bug" as any bug that simulation doesn't catch. In reality, there are critical bugs found at multiple steps -- design review, simulation, prototyping, ... not to mention critical bugs found in backend "verification" (timing analysis, equivalence checking, ...). The author pushes formal verification but it's not an alternative to simulation; it's a complementary strategy.