Partly — Senior Software Engineer, NZ

What Partly will likely assess

• Distributed systems and fault tolerance
• API and SaaS platform design
• Concurrency and data consistency
• Relational/NoSQL data modelling
• Testing and production ownership
• Communication and collaboration
• Comfort with complex domains and ambiguity
• Bonus: Rust experience
• Willingness to work office-first in Auckland and relocate

90-second introduction

I’m a senior software engineer with over 19 years of experience building and operating backend and full-stack systems across banking, logistics, enterprise software, and AI products.

My strongest areas are Java and Spring Boot, distributed systems, APIs, Kafka, PostgreSQL, security, and production reliability. At SICPA, I currently build services across several product lines, including AI- and search-driven products. Previously, I led banking systems, delivered a highly available equities-trading platform with multiple vendor integrations, and built DHL logistics software processing millions of delivery signatures daily.

Partly interests me because it combines mission-critical SaaS and APIs with a complex real-world domain and AI infrastructure. I’m particularly interested in contributing my experience with reliable distributed systems, data modelling, integrations, and production ownership. I’m based in Malaysia, require New Zealand work authorization, and am prepared to relocate to Auckland.

Five STAR stories to prepare

1. High-scale processing — DHL Electronic Proof of Delivery: millions of signatures daily. Emphasize throughput, batching, failure handling, monitoring, and correctness.
2. High availability and integrations — Standard Chartered equities platform with six-plus vendor integrations. Emphasize boundaries, retries, timeouts, contract failures, and launch ownership.
3. Security-sensitive systems — Banking fund-transfer service with ThreatMetrix and payment rails. Emphasize authorization, idempotency, auditability, and defensive design.
4. AI connected to production software — SICPA computer-vision pipeline from data/model training through Spring Boot and mobile inference. Emphasize engineering trade-offs, not only the model.
5. Failure or disagreement — Choose a real incident involving a production defect, design disagreement, missed assumption, or delivery risk. Explain what changed afterward.

Likely system-design question

Design a platform for identifying compatible automotive parts.

Discuss:

• Vehicle identity: VIN, make/model/year, engine, and configuration
• Part entities, alternate parts, supersessions, suppliers, and fitment rules
• Provenance and confidence for data from different sources
• APIs for search, compatibility checks, and catalog updates
• PostgreSQL for authoritative relationships; search index/cache for fast reads
• Versioned data and audit history
• Idempotent imports and asynchronous processing
• Caching for read-heavy compatibility queries
• Timeouts, retries, circuit breakers, and dead-letter queues
• Metrics: latency, error rate, stale-data rate, and compatibility accuracy

Strong opening:

I would first separate authoritative fitment data from derived search and recommendation views. The write path would validate and version incoming catalog data, while read APIs would use optimized projections and caches. I’d make compatibility decisions explainable by retaining the source and confidence behind each result.

Technical questions to rehearse

• How do you make an API request idempotent?
• How do you handle duplicate Kafka events?
• When would you choose SQL versus NoSQL?
• How do you prevent lost updates?
• How do retries create outages?
• How do you design graceful degradation?
• How do you investigate a latency regression?
• What belongs in unit, integration, and contract tests?
• How would you migrate a large database with minimal downtime?
• How do you handle eventual consistency in a customer-facing system?

Rust preparation

Java and Spring are my deepest production strengths. I also have Rust experience and understand its ownership, borrowing, type-safety, and error-handling model. I’m comfortable ramping up quickly where Rust is the appropriate tool.

Review:

• Ownership and borrowing
• Result and Option
• Enums and pattern matching
• Traits and generics
• Send/Sync
• Async versus blocking work
• Why Rust can be useful for reliable, performance-sensitive services

Questions to ask Partly

• What would success look like in the first three to six months?
• Which team or platform area would this role join?
• How do you validate fitment accuracy and handle conflicting catalog data?
• What are the biggest reliability or scaling challenges today?
• How much of the work is new development versus improving existing systems?
• Where is Rust used, and what would you expect this role to contribute?
• What are the stages of the interview process?
• How does relocation and Accredited Employer Work Visa support work in practice?

Location and work authorization answer

I’m currently based in Malaysia and would require employer-supported New Zealand work authorization. I’m committed to relocating to Auckland and understand that Partly is office-first there. That arrangement works for me.

Main focus

Prepare around distributed-system trade-offs, data correctness, production reliability, and clear communication. These align most closely with both the job description and your background.