Lightricks Data Engineer Interview Guide

Our candidates report that Lightricks is less interested in flashy theory than in whether you can make clean, defensible choices with messy data. The strongest signal across the experience is query design under constraints: one prompt asked for pairwise GDP differences without duplicates, another for state-level user ratios, and another for ranking songs by plays. In each case, the interviewer seemed to care as much about why the solution was structured that way as about the final result. That means they’re watching for careful joins, correct aggregation boundaries, and whether you notice edge cases like null handling or one-row outputs.

A recurring theme is that they also want to see how you reason about evolving user behavior over time. The feature-activity problem, where “expert” status depends on the third use and affects later rows only, is a good example: this is the kind of logic that separates someone who can write SQL from someone who can model product behavior accurately. We’ve also seen a live discussion around SCD-style session logic, which suggests they value candidates who can translate ambiguous event data into a stable analytical structure. In other words, stateful thinking matters here.

The HR conversation appears to be straightforward, but the technical side rewards candidates who can explain tradeoffs clearly. One candidate explicitly noted that the interviewer probed why they chose a particular solution path, which tells us Lightricks is checking for judgment, not just syntax. If your approach is correct but brittle, or if you can’t justify how it handles real product data, that’s where interviews here tend to get interesting.