In the summer of 2008, I was 23 and preparing for my fifth and final year at the Faculty of Automation, Computers and Electronics in Craiova. I had chosen the hardware track, I was finishing the fourth CCNA module, and I knew one thing with great confidence: I did not want to work in software.
It was not a carefully considered career decision. Programming scared me. I did not think I could become particularly good at it, so I was aiming for hardware or system administration instead. In my head, that was the sensible route.
This is how I became a QA engineer: I spent almost a year looking for the right job, finally found it, and then did not get it.
I Was Trying to Avoid Software
One Saturday, our CCNA professor came to class with an announcement. The small outsourcing company where he also had a management role was hiring a junior system administrator. Experience was not required. They would train the person they selected.
Perfect. The stars had finally aligned, or so I thought.
I prepared my CV, sent it over and waited. After some time, the professor called me. The company had changed its mind and hired a sysadmin with experience.
That was disappointing. But he had another question: would I consider interviewing for a Quality Assurance internship? It would last two or three months and could turn into paid work if things went well.
QA had never crossed my mind. I barely knew what it was.
I also had no job, no other offer and nothing clever waiting in the background. I had seen university colleagues leave the country after graduation and end up working in completely different fields. I wanted to start working before graduation and avoid drifting away from the profession I had studied for, so I went to the interview.
There was no moment of revelation. I did not suddenly discover my passion for software quality. The job I wanted was gone, and another door was open. Sometimes a career decision is no more glamorous than that.
QA Was Not the Plan
The interviews went well. We spoke about my university projects, I answered some questions in English, and I met the QA manager and the CEO. They offered me the internship.
Then they trained me from the beginning: what testing meant, how to read requirements, write test cases, report a bug properly and give developers enough information to reproduce it. I also learned how to discuss a problem with a developer without turning the conversation into the traditional QA-versus-dev nonsense.
I started with small internal applications. About six weeks later, I signed my first paid contract and began working on a client project.
The atmosphere in that first company was excellent. I had very good colleagues and leaders around me, and it may still be the best team atmosphere I have experienced. That made learning a new profession much easier than it could have been. It was a good start, but I still assumed QA was temporary.
A lot of companies use QA as a polite synonym for manual testing. That was never the whole job for me, although some teams certainly treated it that way. My first role was manual-heavy, and some developer colleagues called it “clicka-clicka”: going through an application and clicking buttons all day. I laughed, but I was not entirely convinced they were wrong. My vague plan was to get into the industry through QA and move to development later, where the “real” technical work supposedly happened. The work itself started dismantling that idea.
When “Clicka-Clicka” Stopped Being a Good Description
One project involved mobile advertising. This was 2008. The iPhone had launched only the year before, and the first Android phone went on sale later that year.
I was still testing ads on Java .jar applications and mobile sites. Mobile data was uncommon and expensive, so I looked specifically for phones with Wi-Fi and .jar support and bought a few suitable models, including phones with QWERTY keyboards. I researched emulators, built simple test applications, created test landing pages and installed the applications on the phones.
I checked whether the ads displayed correctly and whether impressions, clicks and click-through rates were recorded properly in the reports. The point was not just to follow prepared test steps. I often had to create the setup before I could test anything.
That was quite a lot of effort for “clicka-clicka.”
This was the part of QA I had missed from the outside. The role was still mostly manual, but the work had already become more technical than clicking through prepared steps. It meant researching unfamiliar technology, creating the setup I needed, following data across a system and explaining a problem clearly enough that somebody else could fix it.
I also did some Java and Selenium automation in that first job. It was useful, but let us not rewrite history: the work was limited, it was not especially complex, and I was not an automation expert. I learned from it, but the deeper automation work came later.
What mattered was that I was no longer judging QA by its title or by the jokes around it. I had started seeing the full scope of the work, and it was broader than I expected.
The Career Makes More Sense in Reverse
I eventually became a lead for a small team of QA and support engineers. Later came larger companies, automation, engineering management, software development and customer-facing technical work. Listed like that, it looks suspiciously like a plan. It was not.
Looking back, I had stumbled into a niche that suited me better than I could have known at the time. Some of that fit was already there. Some of it developed through the work. I liked understanding systems, explaining problems, working with people and going deeper technically when the job required it. The mix mattered more than becoming exceptional at any one part.
Had I forced myself into pure software development, I might have become an average developer. Staying purely in manual execution would have limited me in a different way. QA gave me room to build a career between those two paths.
I would take that QA interview again. Not because everything happens for a reason; that is easy to say once you know the ending. I would take it because I nearly dismissed a field I did not understand, based largely on fear and a few jokes from developers. I remember that beginning fondly now. There is something suitably funny about trying so hard to avoid software and then building a career in QA. The student who was running away from software has now spent almost twenty years working in and around it. QA also left me with a permanent habit: when somebody says something should work, I remain optimistic, but I still want to see the evidence.
Was your current role part of the plan, or did it begin with an opportunity you almost dismissed?