I didn’t accept the position they offered me, but after attempting and failing a few times, here are a few things I learned:

1. Don’t let perfect be the enemy of the good: Get a suboptimal working solution in the editor/on the board first. Then — and only then — should you try optimize or implement something more clever.
2. Work with your interviewer: If you don’t know/remember something, ask! They are trying to assess how you might collaborate with others to find a solution. Instead of freezing up, lean into not immediately knowing the answer and showcase how you respond when you know that you don’t know something.
3. For the on-site, write your code on paper: I think this actually helped me the most. It’s a hassle and it’ll expose weaknesses that might at first make you feel like you’re taking more steps back than forward, but being able to write runnable, high-quality, modular code on the spot is probably the most important thing to get right during your on-site that will differentiate you.

Other than those, just brush up on CTCI-type problems (I really liked leetcode.com) and make sure you’re able to communicate your ideas clearly.

Good luck!