Recently I interviewed a fairly experience tester for a SDET role at my company. He has a few years of experience under his belt and seems to have a successful track record at a large software house on the east side of Greater Seattle area. But like many candidates I have rejected before, he failed utterly on the interview day. The idea behind this post is to remind people that we could, or might I say must, apply the learning's from one area of life to another. In this case from one area of our professional life to another.
As testers we are used asking questions like what if, how about this, what else etc. to almost all problems we are given. Discovering the details of the products by digging around every possible nook and corner is part and parcel of a testers job. Because requirements, however detailed they are, seldom give the complete picture of the product or the problem at hand. Even if they do the solutions people come up with regularly hide issues that are not apparent at the first glance.
Similarly bringing a semblance of structure to otherwise chaotic SDLC is a regular part of SDET's life. Be it implementing continuous deployment today or a writing a good old test plan. Testers add quiet a bit of structure and determinism to seemingly unwieldy problems that technology creates or solves. So testers who practice such curiosity and discipline day in and day out, completely and utterly fail to use any of that when it comes to the interview day. They become nothing more than a mere answering machine. Please don't be an answering machine.
No comments:
Post a Comment