How to prepare for "pair programming" interview?
I recently interviewed with two 100-person startups and both of them have one round of "pair programming" interview. In that round, we do live coding with a very simple coding question. An example question is to design a Robot class that has integer 2D coordinates and listens to keyboard input to move up/left/right/down - Intro to Programming level questions. They emphasis on class methods design and how the solution code is structured.
During the interview, I feel like the interviewer has a clear answer in mind of how it should be structured, but I can't read their mind. I asked what's the use case of my class (how it's called, call patterns, future features, etc...) and the interviewers say something like use your best judgement or ask the question back. The interviewers don't seem to be interested in input parsing and edge cases (like how many edge cases could there be for such a simple question?). They also asked what would you do if you want to deploy it to prod, which feels more confusing (I answered a few metrics, logging, tracing and monitoring stuff but not sure if that's what the interviewer is asking for).
I failed both, but I want to get some learnings out of it. What are interviewers looking for in this round and how should people prepare for it?
Discussion
(2 comments)- 1
3 months agoEngineer @ RobinhoodMy view on how I would approach those questions are:
- Design the interface: figure out what methods should be exposed and what input/output should be for each method.
- Tracking state. Is there state that needs to be maintained and how should this state mutate?
- Edge cases. What edge cases will the class encounter? Should we no-op or throw an exception if they're encountered?
- Validation. How can I prove my code works (always start with unit tests)? Can I come up with a suite of test cases that will cover all possible behaviors?
You can cross-reference this list with how you approached the problem and see what does/doesn't overlap: if there's no overlap, then that might be an area you can look to cover the next time you get one of these interviews.
If you're dealing with smaller companies, you can always ask them for some high-level feedback. Usually, they're more generous with feedback compared to larger companies (whose processes are a lot more formal).
- 13 months agoTech Lead/Manager at Meta, Pinterest, Kosei
Let's start with the desired outcome for a pair programming interview: you want it to feel like an energizing mind-meld session where both interviewer and interviewee are working on a problem.
So I'd expect a lot of back-and-forth conversation and active listening.
I think finishing the programming task is actually secondary relative to the signal that is received from the conversation. Of course, I'd make progress on the question, but I'd provide plenty of hooks for deeper discussion:
In a side project, I learned a lot about the best way to create reusable logging, but for now I'll start with something simple here. Happy to explore that in more detail if you'd like.
The way I'd prioritize this feature is by looking at user data and UXR. I'll start with this approach, but let me know if you'd like me to go in another direction.
