Hinge Data Engineer interview experience
A niche dating app company. I heard the work is pretty relaxed and the benefits are good.
Round 1 | HR
I started with a short self-introduction, then we talked about my current team: how many people there are in total and which part I'm responsible for. They also asked what data I work with day to day and how large it is.
I picked the project that was the hardest to get done and walked through it. They followed up on two points: where exactly I got stuck, and what technology I used to solve it. They also asked at the end: once this thing was built, who actually uses it day to day?
We also talked about my rough salary expectations and the RTO policy.
Round 2 | HM
We first went through my resume, then picked one project to dig into. The project background was only part of it; they asked in more detail about what I personally did and why I designed it that way. Also: how do you get other people's buy-in without having authority?
Another question was about how you give feedback at work. If you think a colleague or your direct manager did something badly, how would you tell them? And in the other direction, how do you handle it when others give you feedback?
Round 3 | Onsite
Data modeling
The scenario was a chain of sports venues. Every venue sells classes, and operations wants to see sales by venue and by class. I was given three datasets. The first two look like ordinary CSV tables, and the third looks more like a receipt.
Venue info (dim): one row per venue, with venue ID, short name, address, and manager ID. What you get each time is always the latest version. For example, if the manager changed last week, this file only shows the new manager's ID.
Class catalog (dim): one row per class, with class ID, class name, and separate IDs for the major category and the sub-category. For example, the class "Weekend Intro to Rock Climbing" has the major category "Sports Classes" and the sub-category "Rock Climbing". This file also only gives the current version.
Checkout transactions (fact): one checkout is one record. On the outside you see the transaction number, member ID, which venue it was bought at, and when it was paid. Inside there is a line-item list. For example, if someone buys a climbing class and a swimming class in one go, there will be two line items, each with the line number within that transaction, the class ID, and the amount actually paid. Every row of this table has FKs to the first two tables, so it's obviously the fact table.
First we talked about how to split these datasets into tables once they go into the warehouse, what one row means in each table, and how you join them when querying.
You can start by describing the constraints on each table, for example how you set PK, FK, nulls, and unique identifiers, what the grain is, how they join, which business questions your model can answer, why you set it up this way, the trade-offs, and how it scales.
Then you write queries against your own design. They asked roughly these SQL questions:
Given a time range, which class sold the best in that period?
For a specified day, which classes had revenue above $xxxx?
Within each sub-category, which class has the highest revenue? They explicitly said to rank by the amount actually paid. You can split it into a few CTEs: group by -> row_number() window function -> final select filtering by rank.
Counting from the first transaction, which manager has the highest total revenue under their name? Then a follow-up: if a venue changed managers midway, the classes sold before the change still have to be credited to the previous manager, but the venue file only has the current one, so how do you change the tables? You can use SCD Type 2 to keep the full change history, and when you JOIN, use the date to match each day's transactions to the right manager of each venue.
You write code on a whiteboard and don't run tests. Don't just rush into solving the problem blindly. The interviewer wants to see your thinking, so you can write down your approach first and then do the problem.
System design
I was given two real-time data sources and asked how I'd design the data pipeline, what happens in the warehouse, and how it scales.
First clarify the requirements and then state your assumptions (how often the sources send data, who the downstream users are, whether they want real-time or batch is fine, whether duplicate data might come in, roughly what scale), estimate capacity, talk about what the data model looks like, and then which tools and technologies you'd use, why, and what the trade-offs are, where the data contract lives and what the benefits are, how to do ETL, how to orchestrate, how to do DQ checks, how to validate results, how to backfill, and how to do failure recovery. The interviewer also asks questions about your design, for example how to control cost, how you handle two events being out of sync or at different scales and why you handle it that way, what to do when an event arrives late, and which metrics you'd monitor to make sure the system is running normally. This round didn't even have a whiteboard; you just say it out loud, so you have to pay extra attention to how you express yourself. Keep it concise and follow a structure and flow so the interviewer can follow your answer.
Discussion
Loading comments…