Have you ever been asked to explain polymorphism as a Design Verification engineer?

This is a common interview question for Design Verification roles and I also used to ask it frequently during interviews.

Most engineers explain polymorphism with examples like a parent class (shape) defining a method to calculate the area, while child classes (circle, rectangle, triangle) override it for specific implementations.

While these examples are correct they don’t align well with our domain.

So how should you explain polymorphism as a Design Verification engineer?

I believe explaining it using something more relevant to RTL design like the payload of a bus and its parity signal, would be more effective.

As an example, consider a parent class as a base transaction object randomizing a payload and generating its parity bit. A child class could then be a transaction class generating parity errors.

This approach not only explains polymorphism but also:

• Introduces modern Testbench Architecture with transaction objects and sequences
• Explores randomize() and post_randomize() methods in SystemVerilog
• Sets the interview tone around design verification principles

What do you think about it?

Please note that we are still working on adding support to compile the code on our website!