In a talent landscape full of competitive opportunities, where change and turnover are part of the norm, Kogan.com stands out as a place where people choose to stay, grow, and advance their careers. Many of our team members have long tenures, with some contributing as long as 12 or 15 years, reflecting the strong culture and opportunities here.
This month, we celebrated three team members reaching their four-year milestone. To mark the occasion, we spoke with them about what has made their journey so rewarding, what has kept them at Kogan.com, and what continues to inspire and excite them as part of our team.
Adam Slomoi
Adam is currently the Tech Lead of a squad. He joined Kogan as a Software Engineer and quickly progressed to Senior Software Engineer, and most recently to Tech Lead. In this role, he continues to sharpen his technical skills while growing his passion for people leadership.
How has your role or perspective on engineering evolved over the last four years?I’ve been fortunate to work across different areas of the business and on various components of our system during my time at Kogan. One theme that has remained consistent throughout, and that I’ve gained a greater appreciation for, is the focus on business outcomes.
How did you feel stepping into your first leadership role, and what did you learn from the experience?
I felt well prepared before officially taking on a leadership role. We have a very collaborative team, and there have been many opportunities along the way to have a say and help set the direction for the team.
Sam O’Halloran
Sam started at Kogan in his first formal software engineering role straight out of university. He has honed his technical skills, contributed significantly to his team, and grown in both technical depth and breadth, applying best practices efficiently.
Which project are you most proud of, and what made it exciting or unique?
I’m most proud of the work on product variants. It wasn’t one big launch, just lots of smaller fixes that added up. I tightened grouping logic in pipelines and batch jobs, cleaned up SPS edge cases, and ensured changes flowed through to OpenSearch. On the UI side, I tweaked filters, added a simple horizontal selector for single-variant products, enabled a promo palette, fixed dropdown ordering, and added a VariantGroup sitemap for better SEO. It was satisfying because variants are messy in the real world, and these changes made choosing the right option faster and clearer for customers, and saner for our internal teams.
Can you share a moment where your work made a noticeable impact for the team or the product?
I led a performance pass on our Product Listing Page. I cut work above the fold, switched tiles to responsive images, added light skeletons, virtualised the brand filter with React Virtuoso, lazy-rendered heavier lists, and fixed scroll and CLS issues. The page now loads faster and filtering feels smoother, which reduced the performance issues we were tracking on that screen.
I also flagged follow-ups for our Product List endpoint to make it simpler, faster, and more reliable.
Yanxu Zheng
Yanxu is a highly skilled Senior Software Engineer who has developed deep technical expertise. He was recently promoted to a tech lead role and is now responsible for leading a large squad.
What’s one of the most interesting technical challenges you’ve solved during your time here, and how did you approach it?
Our keyword-based search sometimes failed to grasp user intent, leading to irrelevant results. I tackled this by leading an experiment to test whether a hybrid search model combining keyword and semantic matching could perform better. To avoid any risk to live services, I ran the experiment on a parallel cluster that mirrored production data. We then conducted an A/B test comparing the new hybrid search against the existing keyword search.
The results were clear: while the new model showed a modest improvement in relevance for some queries, it produced no statistically significant lift in user conversion. Based on the data, we decided not to roll out the feature, as the additional infrastructure cost wasn’t justified by the lack of business impact. My key takeaway was that a technical improvement is only valuable if it moves a core business metric. This experience reinforced my approach of always tying engineering efforts to measurable business outcomes.
Is there a problem you tackled that taught you a new skill or changed how you think about engineering?
I once fixed major performance issues in our OpenSearch cluster by challenging the official best practices. The standard advice was to use 10–50GB shards, but our search latency was poor. I ran experiments and proved that for our specific workload, smaller 5–10GB shards were far more efficient. Switching to smaller shards cut our query latency by over 20%. The experience taught me to always validate standard guidelines with real-world data, as optimal solutions are context-dependent.