{"id":474528,"date":"2025-09-10T21:00:22","date_gmt":"2025-09-10T21:00:22","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=474528"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=474528","title":{"rendered":"QA Engineer in a Product Company: How I Left Outsourcing and Stopped Panicking Before Releases<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

Six months ago, I had a cultural shock. My entire career as a QA Automation Engineer was spent in outsourcing: stable, predictable, even comfortable at times. But during the January holidays, I had a thought for the first time in ages: I\u2019m almost 30, a confident senior, and yet it feels like I\u2019m standing still.<\/p>\n

<\/figure>\n

All I did was toggle \u201copen to work\u201d on LinkedIn, and unexpectedly got an offer from a product company EXANTE. I went to the interview \u201cjust to take a look\u201d and stayed.<\/p>\n

This article is an honest take on how work, the approach to quality, and life in general change when you switch from outsourcing to product. No sugar-coating, just facts. I\u2019ll share what surprised me, what delighted me, and why releases no longer give me tachycardia. Maybe my experience will help someone decide to leap.<\/p>\n

Onboarding and Paperwork<\/h2>\n
<\/figure>\n

Theatre starts with the cloakroom, and a new job starts with onboarding. And here, onboarding turned out surprisingly pleasant.<\/p>\n

There were just two interviews. The first was with HR: they introduced me to the company and team, and asked about salary expectations. The second was with the backend QA manager \u2014 shoutout to Vova! Funny enough, I had read his Habr article long before he interviewed me.<\/p>\n

All paperwork happens through a personal account. No papers, no running around with your passport. Contract, payment details, and everything else are uploaded in a couple of clicks, and you\u2019re already in your probation period. Expense claims for conferences, software, and education are also handled online.<\/p>\n

And if something goes wrong? You can message the CEO directly in Slack. Seriously. Later in this article, I\u2019ll talk a bit more about bureaucracy, but the kind that doesn\u2019t make you grind your teeth. Almost.<\/p>\n

Documentation \u2260 Bureaucracy<\/h2>\n
<\/figure>\n

At my previous job, I churned out \u201cexplanatory notes,\u201d \u201cuser manuals,\u201d and other documents the client would skim once, nod, and then forget forever.<\/p>\n

Here, it\u2019s different: there\u2019s a dedicated technical writer, and their work doesn\u2019t go into a drawer. Everything lands in a living, structured Confluence with headings, a table of contents, proper search, and no archival dust.<\/p>\n

The writer isn\u2019t locked away in an ivory tower. They work closely with developers and QA: short sync calls help clarify details without breaking flow. As a result, documentation is not \u201cfor the sake of process,\u201d but genuinely useful.<\/p>\n

Even AI now helps describe code and tests. Most of the time, you just tweak the wording. And honestly, documentation is like revising past lessons: great for memory, super handy for the team.<\/p>\n

And yes,\u00a0 there\u2019s nothing sweeter than finding your own article in Confluence and finally understanding what the heck you wrote a year ago.<\/p>\n

Learning and Internal Knowledge Base<\/h2>\n
<\/figure>\n

I already mentioned that the company reimburses external courses. But the real gem is the internal learning available to everyone right away.<\/p>\n

We have a library of internal meetups: a media archive of talks about technologies and processes actually used in the product. Everything is curated and to the point. No need to waste evenings hunting for courses or sifting through dubious speaker reviews.<\/p>\n

Bonus: If a technology is already in use, there\u2019s a good chance you\u2019ll face it soon. Knowledge goes straight into practice.<\/p>\n

Special mention: the QA culture here is mature. The team includes SDETs who don\u2019t just build frameworks, but make them pleasant to use, stable, and free of debug voodoo. Working with them helps you grow as a coder, write stable code without crutches and print()s in production.<\/p>\n

\u201cPush it to the repo and hope for the best\u201d? Doesn\u2019t fly. Every piece of code goes through an SDET review \u2014 tough but fair, and that\u2019s where growth begins.<\/p>\n

(On page 3 of the original file, there\u2019s also a useful visual comparing I-, T-, and M-shaped skill profiles, showing the value of broad, cross-functional knowledge.<\/em>)<\/p>\n

How We Handle Releases<\/h2>\n

The next shocker: releases. But don\u2019t cringe; here they\u2019re not about late-night panic deploys or Tuesday burnout.<\/p>\n

The process is set up properly. You\u2019re on duty, but you\u2019re not walking through a minefield. Everything is planned, no panic.<\/p>\n

Each release has three simple steps, about 30 minutes each:<\/p>\n