1. Round 1 – Excellent The first round with the CTO was smooth, focused and clear. It was the best part of the process – well structured, on-topic and respectful of my time and experience. ⸻ 2. “Culture” round – Mislabelled and unstructured Round 2 was described as a cultural interview, but in reality it was roughly 50% technical and 50% culture, with no clear structure. The VP of Engineering and Product Owner/Manager were asking questions more or less randomly. Despite that, the discussion itself went well – I answered most, if not all, questions with concrete examples from my past experience, and they appeared satisfied. However, labelling it as a culture round and then turning it into a mixed, unstructured technical + culture session is confusing and feels disorganised. I also raised relevant concepts such as Pact/contract testing as a core part of a shift-left approach – and it was quite clear this was not something they were familiar with. When asked what I knew about the company, I was able to provide substantial detail as an outsider, showing I had done my homework. ⸻ 3. Technical + “solve our problems on the fly” round – Poorly framed and unrealistic The second part of Round 2 (with the Principal Engineer and Engineering Manager) was the weakest and frankly very disappointing. • Questions were frequently asked with little to no context. For example, I was asked about “deadlock” without specifying whether we were talking about threads, queues, or messaging. When I clarified if the context was messages going to a dead-letter queue in something like RabbitMQ, the interviewer nodded, so I gave an example in that space. • When I spoke about parallel execution of tests, I was suddenly asked about memory being fully used, again without context. I explicitly asked whether they were talking about idempotency of APIs or general memory issues due to inefficient implementation. Only then did the Principal Engineer reframe the question to “how would you handle idempotency”, which I answered. • There was also confusion on basic terminology: I was asked what I would do if we “find a bug” in a release. I had to clarify the difference between a bug and a defect before we could even align on the question. On top of that, there was an underlying expectation that I should effectively design their test strategy and “fix” their current problems live in the interview, without any proper context, documentation or architectural view. I was treated almost as if I were already an internal employee with deep knowledge of the systems, rather than an external candidate. I specifically talked about: • Testing across different screen sizes and aspect ratios – which is absolutely core for a screen-mirroring product. • How to approach automation based on ROI rather than “automate everything” – prioritising critical paths and value rather than brute-force automation. • Pact/contract testing as a major part of shift-left testing, which again did not seem to land with the interviewers. As an external candidate, I can outline approaches, frameworks and strategies. But being asked to design detailed strategy on the fly, with minimal context and minimal understanding of quality from the interviewers’ side, is unrealistic and frankly unfair. Overall, it felt like they weren’t clear on what they were trying to assess, and lacked the testing maturity to have a meaningful, senior-level quality conversation. ⸻ 4. Short-term and long-term goals – Misinterpreted as a negative In 1st part of Round 2, I was asked about my short-term and long-term goals. I answered clearly and honestly: • In the short to medium term (3–5 years), my goal is to progress towards a Head-of-level position. I am currently doing my Executive MBA, and as part of that we prepared a personal leadership plan which aligns to moving into an organisation-wide leadership role. The position description for this role specifically stated responsibility for organisation-level QA strategy and culture, which is exactly why I applied. • In the longer term, I mentioned an ambition to become a non-executive board member for a policy-related organisation, so that I can contribute to purpose-driven, policy-level decision making. This is consistent with my interest in purpose-driven leadership, ethics and public value. This was somehow highlighted as a negative in the feedback. For a role that is effectively operating at a Head of Quality level (driving org-level QA strategy and culture), I would expect ambition, leadership focus and clarity of direction to be seen as strengths, not weaknesses. Penalising a candidate for having a clear leadership trajectory and long-term vision is a red flag about how the organisation views growth and leadership. ⸻ 5. Misalignment between role, process and final feedback The role is titled QA Manager, but the description and conversation clearly aligned more with a Head of Quality / Quality Engineering leadership role. They were asking for: • Organisation-level QA strategy and culture change • Automation approach across platforms (including Android/iOS) • Broader quality operating model and shift-left practices Yet the interviewers assessed this through: • Poorly structured, ad-hoc technical questions • Minimal context around their systems and constraints • A heavy developer-driven lens, with limited understanding of modern QA and quality leadership The final feedback I received via my recruiter was that I “lack strategy and technical skills”. This is completely at odds with what was actually discussed and demonstrated, including: • SDET-level technical experience and examples (parallelisation, idempotency, messaging, etc.) • Strategy around ROI-based automation, not over-automation • Shift-left through Pact/contract testing • Platform-specific considerations such as screen sizes and aspect ratios • A clear leadership trajectory and understanding of organisation-wide quality and culture Either the interviewers were not listening, were using a very different (and unstated) yardstick, or they were projecting internal issues and frustrations with their current state onto the candidate. ⸻ 6. What this signals about Vivi’s QA culture During the process, it was mentioned that the QA culture at Vivi is “not great”. After experiencing the interviews, I understand why: • The process is clearly dominated by developers who themselves have limited understanding of modern quality and testing practices. • There appears to be no established automation framework for Android and iOS, despite those being the primary devices for Vivi’s core screen-mirroring product – a basic expectation for a company at this stage. • Quality seems to be treated as an extension of development rather than a discipline in its own right. From the outside, the interview process and the feedback strongly suggest a weak and developer-dominated QA culture, which will make it very hard for any genuine QA leader to succeed.