Dinner with Brad Davis, Best in Test's “Test Engineer of the Year”
Last night, after Brad Davis of Broadcom won the DesignCon Best it Test “Test Engineer of the Year” award, I got to tag along when the folks at Test & Measurement World and National Instruments (whose equipment Brad uses in some of his setups) took him out for a celebratory dinner.
Brad’s test group is charged with developing the test hardware and software – including test fixtures, stimulus signals and signal capture, and test patterns) for the horrendously complex Broadcom ASICs. Test in this case involves putting both the chip’s circuits and software through its paces, and the testing can serve as an impartial observer of which aspect of an IC is responsible for a problem: If the chip circuit design group was in charge of test, then likely the software would always be at fault, and if the software group was responsible, the finger would always point at the hardware. The test group has to be a master of both.
Brad uses this opportunity to develop deep skill sets as a recruiting lure when interviewing new engineers. “I tell prospective hires that they can get as deep into the hardware and software of the chip as they want.” After all, few freshly-minted engineers come out of college wanting to go into test, and they probably don’t even know the discipline exists, let alone realize that it can be one of the most challenging parts of electronic design.
Brad also mentioned that much/all of the programming his group does is in Python. I was surprised and asked, why not C or one of its close cousins? He said that, while most engineers will put C on their resume, often their experience is cursory, perhaps just from a college course or two, and not at the level needed for test development. Python is a more accessible language which does the job without the complexity of C. (This approach of using a simplified language agrees with that of many of the new microcontroller development platforms, such as the arduino.)
I think Brad said that his first job out of college was working for a company that developed LabView-based test setups. And no, while an engineering student at the University of Calgary, he never really considered becoming a test engineer. That clearly didn’t prevent him from reaching the top of his very challenging profession, while enjoying it to the hilt.
Lonnie Burk commented:
Congratulations Brad, from one test engineer to another.
William Ketel commented:
I have wondered about that for some time. If folks want a program writer, just say so, and I will not apply for the position. An electronic engineer is different, with a different skill set than a program writer. I have written detailed functional specifications for programs, describing what must happen for each input, and what the screens must look like, but that is different than being a programmer.
Patrick Mannion commented:
Hey Margery, I thought Brad had a really interesting response when I asked if he'd actually wanted to be a test engineer. It turns out he doesn't really see it that way, nor does he focus on that angle when interviewing candidates. Instead, it's design job: Designing test systems for ICs. Interesting perspectice.
I put a poll on www.scopejunction.com asking how engineers view the test function. It's primarily a healthy 'art of test' or a 'learning experience' attitude. Anyway, hat's off to Brad: an engineer's engineer!















