Q-Khu Plot – my experience as a Quantium data analyst (4)

Posted on: February 12, 2025

Post Category: Professional Development

---

Q-Khu plot is a series where I share the experiences I’ve had at the company – all the great things and challenges. And this is my most recent biannual update.

As of today, I’ve worked at the company for 2 years:

• Mid-2023, I released part 1,
• Late-2023, I released part 2 (around when I nearly finished the graduate program), and
• Mid-2024, I released part 3.

So, let’s get it.

Where I went, and the type of work I’ve done

As of writing, I just completed 2 years at the company – and over the past half-year, I spent my team in one of the company’s product teams.

To say the absolute least, to describe the product, it is a data analytics platform. And as an analyst (in a team of many engineers), my role was to ensure that the platform aligned with user requirements and was accessible.

Most of my time in the team was spent writing documentation, running tests and constructing/testing samples – so that users had the required services and knew how to use them.

And generally, the experience has been great. For the first time in a couple of months, work felt a bit more predictable and slower-paced – but at the same time, I was getting pushed and building my technical skills decently quickly.

But work had also it’s challenges. Two things come to mind: (1) learning totally new tools, and (2) having conversations with the engineers involved. (1) is pretty self-explanatory; joining the team meant I had to upskill, but the unfamiliarity I felt this time around was the biggest it had been in my career. As for (2), writing documentation, running tests and understanding the product got a bit confusing because, most of the time, I’d rely on the engineers – and they would have a very deep technical understanding of it.

My first year in the business was in finance, and I was used to being the technical guy that the financial analysts would come to for questions – to pull their data or do an automation. But now, the engineers are the technical people – and I’m the one asking the questions.

Learning how to paraphrase and get to “no” (quickly)

To make communication easier between me and the engineers, I learnt how to paraphrase (what they say) and get to “no” (quickly).

I paraphrase to make my attempt at understanding what they say, put into my own words. And to make sure that I get a straight answer on whether my interpretation is correct, I use a yes-or-no question. For example:

• “Is my interpretation correct?”
• “Does that sound right?”

If it wasn’t a yes-or-no question, the engineers could say anything – and sometimes they would provide additional context and information I wouldn’t understand, which makes the conversation more confusing.

So, in a lot of the Slack threads I have with these engineers, I would ask questions like:

• “It looks like X… is that right?”
• “It sounds like X… does this align with your understanding?”

I found that this helped me get answers quickly – and I was able to get a clearer view of the next steps.

Even with my current lead/manager, I found this helpful. Whenever I get given a task without much context, I get these “dumb” yes-or-no questions out of the way to know for sure what I need to do.

Next challenges and steps

In terms of tools, I’m still trying to get a good grasp on them. I’ve spent a considerable amount of time taking online courses to build my foundational knowledge (as part of my Learning and Development), and recently I’ve been getting more opportunities to practice those tools and technical skills.

Otherwise, with this current team, I feel like I’m being challenged and I feel I will learn a lot from the experience – which is a good thing. Even after 8 months in the team, I still feel like I have a lot to learn and a long way to go before I do (more) valuable things – but that’s fine, it will take time.

I look forward to the next couple of months!