Recruiter Phone Screen - You should be able to answer basic questions about joins and loops.

Coderpad Tech Interview - Fairly easy questions involving SQL joins, aggregates, Python loops, and string manipulations. If you can solve most of the medium and hard SQL and Python questions on LeetCode without looking anything up, this part should be easy. However, do verbalize your thoughts to leave a good impression on the interviewer.

In-Person Interview - Three whiteboard interviews. The most important thing to practice is rapidly solving common logic/programming problems on a whiteboard. You will not be asked obscure functions or modules, the relative efficiencies of sorting algorithms, nor will there be "trick" questions. These are practical problems, not theoretical or academic ones. Don't waste time memorizing every sorting algorithm.

You have to quickly identify the problem and write the optimal (or extremely efficient) answer. I say "rapidly" because in an hour-long interview, you may only have 20 minutes per problem between introductions, talking, and explaining. It may also be difficult to understand the interviewer's accent or handwriting. One interviewer I encountered was particularly bad about interrupting, explaining boundaries, and constantly having me change my variable names, which lost a lot of time and understanding.

Although they say they insist on perfect SQL, one interviewer told me I could not use a multi-part join condition and insisted I use two different joins. Hmm...

Also, it's a whiteboard, so syntax and setup matter far, far less than your logic. The interviewer cares way more that you grasp the essential problem and solution than if you remembered a colon or to import the right module at the beginning.

"Product Sense" - I received feedback that my product sense was not strong enough. I'm not sure why, but perhaps study problems faced by huge companies like Facebook, such as very large-scale data processing, or brainstorm all the edge cases faced by a user before designing your solution, rather than letting the interviewer hint at the edge cases.

Given a multi-step product feature, write SQL to see how well this feature is doing (loading times, step completion %). Then use Python to constantly update average step time as new values stream in, given that there are too many to store in memory.