Purplle SDE Internship Interview Experience (2026) - AI Retail Challenge to Offer

• An ingestion layer accepted camera streams or video files.
• Detection and tracking produced stable customer identifiers across frames.
• An event layer converted low-level movement into business events such as zone entry, dwell time, and checkout activity.
• Backend services persisted events and served queryable analytics through REST endpoints.
• Docker made the components reproducible for reviewers.

The hardest decisions were at the seams. Tracking output is noisy, so downstream events need confidence thresholds and deduplication. Multiple cameras introduce identity and ordering problems. Analytics queries favor pre-aggregated data, while debugging favors retaining raw events. I documented those tradeoffs instead of presenting every choice as universally correct.

The submission window was short enough that scope control mattered. A reliable vertical slice—video in, track produced, event stored, API response returned—was more valuable than a collection of disconnected advanced models.

Shortlisting and Preparation

Several weeks after submission, HR called to schedule the first technical interview for the following day. With less than 24 hours, I did not try to learn a new stack. I reviewed every API, data model, Docker configuration, event transition, and architectural decision in my own repository.

That was the right preparation because both interviewers used the project as a map. Any line on the architecture diagram could become a discussion about alternatives, failure modes, or scale.

Round 3: Project Deep Dive (About 60 min)

A senior data scientist led the first interview. We discussed the computer-vision pipeline, backend APIs, database design, event flow, deployment, and scenarios that would break the happy path.

Most questions took the form “why this choice?” rather than “what did you build?” I explained what I optimized for, what I gave up, and when I would choose differently. For example, a relational store can make analytical joins straightforward, while a high-volume event stream may call for append-oriented storage and asynchronous aggregation. The useful answer was not naming one database; it was connecting the choice to access patterns, consistency requirements, and expected scale.

I also separated model quality from system quality. Better detection accuracy does not help if events arrive out of order, duplicate, or cannot be traced back to the source frame. Observability and idempotent processing were part of the design, not cleanup work.

Round 4: Production Design Discussion

The final technical interview moved further from implementation and closer to engineering design. Topics included concurrency, latency, database selection, deployment, scalability, and how the prototype could evolve for many stores and cameras.

I described partitioning work by store and stream, using queues to absorb bursts, and assigning idempotency keys to events so retries would not double-count a customer action. For latency, I separated real-time operational signals from slower aggregate reports. For deployment, I discussed health checks, resource limits, model-version rollout, and the ability to replay retained events after a bug fix.

Nearly every response received another “why?” The strongest answers began with the requirement and constraint, then compared alternatives. Listing technologies without that chain would have sounded rehearsed.

HR Discussion and Result

After both technical interviews, HR discussed availability, working mode, and an immediate joining timeline. The written SDE internship offer arrived a few days later.

Tips

1. For project-based hiring, know your own repository more deeply than any generic interview guide.
2. Build one end-to-end path before adding advanced features; reviewers need a system they can run and reason about.
3. Document tradeoffs beside architectural decisions so you can explain why, not only what.
4. Prepare failure cases: duplicate events, dropped frames, model drift, camera outages, and retry behavior.
5. Treat Docker and APIs as part of the product. Reproducibility and clear contracts are evaluation signals.
6. When asked to scale a prototype, separate real-time requirements from batch analytics before choosing infrastructure.