A while back, I starting writing something like this in cover letters to companies trying to recruit me as a Quality Engineer.
Lastly, I ask that I am able to see a few existing defects and test cases (automated/manual) at some point during the hiring process. I am happy to sign an NDA or they can be redacted if there is information that is confidential. Mainly, this is to ensure that I am joining a team that has the same philosophies related to quality as I do and also to make sure that I can ask the right questions and/or make sure I am empowered to make changes if I think they will be necessary. I know that this is not a normal request, but strongly feel it is important to the position and making sure I would fit well into your organization.
After writing it the first time, it seemed utterly asinine that I had never requested these things from a company before. In fact, I have barely requested anything from a company when interviewing. Meanwhile, companies have asked for my very urine. Well one company anyways, but I had to pee in a cup 3 times because apparently I drink too much water for drug testing. Who the fuck knew? But if they can ask me for my pee, I feel like seeing some of their defects and their test cases should not be a problem.
These things are crucial to the job of being a quality engineer. They are required for understanding what kind of organization you are walking into. What stage of development are they at? What is their philosophy on quality? Honestly, now I am worried about ever hiring an engineer that doesn’t ask to see those things. Because it seems incredibly short sighted and that is not someone I want working for me.
Don’t get me wrong. It’s natural for organizations to think differently about quality related to their product. Some organizations are selling millions of cheap units so it is easier to replace a unit than investing time and money into engineering a better product. Other organizations are the exact opposite. Even similar organizations might be at different stages for how they need to think about quality whether they are in startup mode or if they are already established in the industry.
The point is not that every company should have perfectly written defects and test cases. The point is companies should be making sure they are recruiting the right people for the job. It is not the same set of skills to revamp a company’s quality team, processes and tools as it is to create a bunch of new manual tests or new automated tests. There is variation even in the type of testing a quality engineer may be doing. There is plenty of overlap but people have the things they like working on. The point is letting people know what they are getting into and empowering them to make changes if necessary. But mostly hiring a quality engineer that wants to do the job you are hiring for and also that is going to tell you what you need even if you don’t realize it yourself.
For me as a quality engineer, this also means not getting burned. Though to be fair, the word “burned” might be a little strong. But it is a waste of time to spin your wheels in a job where the sense of quality is completely different from what you want to work on. I have walked into too many organizations having no clue as to what I was getting into. Every time, I think of that line from Dexter:
It feels like someone saying:
“Surprise Motherfucker! You thought we had our shit together…”
“Surprise! We don’t.”
And sometimes I have been lucky and things worked out and other times not so much. Ultimately, it is my own fault, but it seems odd the entire industry seems set up to blindside engineers joining an organization when it easily could be set up not to.
My first job coming into the Quality Assurance world (I was already an established developer), there were extremely limited tests written down. Product documentation was minimal at best. It was impossible to determine how the product was supposed to work. I got lucky and the product was fairly intuitive so in many cases it was obvious when there was a defect. That said, I still spent a lot of time sitting in the product manager’s office (Thanks Allison!) with my list of questions and working through the things that were not so obvious. Some of those changes made it into the next version of our product. It was immensely gratifying even if the company did not survive.
When I had a conversation with my boss about the lack of documented test cases, his answer was “just go do it.” And just like that, I was empowered to make the changes the company needed. The company was at a point where I was able to start getting tests better documented and ultimately break them into different types of testing that we could reuse for our product line. The team as a whole was generally open to improving the processes so it worked out well.
More recently however, I walked into an organization whose entire bug database was a fucking disaster. There was a huge backlog of issues, but even the new issues were being entered with limited information to be reproduced. The company had grown rapidly the year before I was hired, but the bugs were still being written from the perspective of people who had worked for the organization for years and knew how the product should work. To make things worse, the product was not intuitive and it was complex enough that looking into each issue took a large amount of time.
The process was to attempt to reproduce defects entered by other development/quality/customer support teams in the organization prior to assigning them to my team’s developers. It seemed easy enough and pretty typical in terms of quality processes.
But the problem for me quickly became clear. I had unwittingly joined an organization where I would have to send back 90% of the bugs that were assigned to me due to missing information. They had minimal “steps to reproduce”. They had no “expected results.” They were missing basic elements of a good defect making my job time consuming, difficult, impossible and most of all miserable.
It is difficult to tell your manager you are bringing value to the team when you just reject everything that comes to your desk. Either you can plod through and figure it out on your own which takes a lot of time or you can try and change the processes so you end up with less shit on your desk. Or you do a little bit of both.
For me, I tried both, but I found it deeply unsatisfying. My boss wanted to see more out of me, but I was trying to fix things and getting nowhere quick. Ultimately, it was a mistake for me to join the team despite my boss being a longtime friend. The organization was not setup for me to do the kind of work that I wanted to do. Many quality engineers were happy enough to just plod through, but for me it felt like a waste of time.
Quality management at the company had not set any kind of requirement for defects and did not seem motivated to do so. In a year of working there, I only started finding people motivated to change things my very last day of work. Literally, there were a few people asking if they could call me the day after I left the organization for my input. It felt validating, but also incredibly disappointing. The perils of working at a company with 3000 people is it sometimes takes a while to find the right ones you can work with. It was a frustrating experience to say the least and ultimately for me it was my 2nd worst job ever. On the plus side, I was paid well and still have a lot of friends that work there on the development and management sides and I enjoyed working with them so I am grateful for that.
The thing is, it was my fault for joining the organization. If i had asked to simply to see what I was getting into before accepting the position, I would have known immediately it was not an organization that I would want to work for. Or at the very least I could have asked questions to make sure I was empowered to change things. Instead, I went in blind and trusted the process would work itself out. And maybe if I had asked I still would have hated it, but again at least I would have known what I was walking into.
The problem is the process is fucking horrible and more so it seems to be status quo for the industry. Being on the other side of the table, I’ve had zero interview candidates request to see test cases or defects or ask about our backlog of defects. These are fundamentals to doing the job of Quality Engineering and yet nobody is asking to look at them before they agree to join an organization. And similarly, there are probably questions related to seeing code and defects that should be asked for development positions as well. But again nobody is asking or it is happening much too rarely.
It’s curious to me why we as engineers accept going in blind? Why do we ask engineers to go in blind? Why aren’t we asking for a better understanding of the job before we accept it? It makes no sense. I’ve been on interviews where I have spent anywhere from 4 to 8 hours of my time interviewing. There was plenty of time to introduce me to the content of what I would actually be doing and working and understanding non-generalities. It would honestly be a 20 minute conversation. Most of the content and defects are not so important at most companies that they need to be veiled under NDAs and even where they do it seems worth it to end up with engineers who fit better in the company.
Again, it makes no sense. But until we fix it and until we start asking…
“Surprise Motherfucker!”
Be First to Comment