An Interview with a FAANG engineer

Interview Summary

Problem type
Banking Ledger
Interview question
Design a Banking Ledger.

• Assumption: Assume the frontend client exists/ ATM [Multiple sources of transactions e.g. PayPal, Zelle, Direct Deposits / Checks]
• List expectations in terms of requests

Interview Feedback

Feedback about Indelible Torch (the interviewee)
Advance this person to the next round?
Yes
How were their technical skills?
4/4
How was their problem-solving ability?
4/4
What about their communication ability?
4/4

Overall more relaxed and it absolutely changed the game! brilliant job!

General Feedback

• Excellent work scoping down the focus. It was good that you realized just how expansive the system can be and abstracted over all aspects of authentication and didn’t focus too much on nuances.
• Brilliant work thinking about the point on reconciliation. It was impressive that you immediately intuited this aspect despite not designing a banking system before.
• We still spent extra time on requirements but you are doing very well with ensuring the interviewer is in the loop so this was time well spent. It felt justified and as the interviewer, I approved the discussion thus it gained you points. You also knocked off an important discussion on DB selection by engaging the interviewer.
• Be mindful of the common terminologies. Summarize types of consistency on a chart, load balancing strategies, rate limiting approaches, caching strategies etc.
• Brilliant work bringing up MFA right from the get-go! This is something very few people think about yet in a banking app, it is absolutely key. Even better, you made the token idempotent.

Interview Transcript

The Legendary Avenger: Hello.

Indelible Torch: Hello.

The Legendary Avenger: Hey. Hope you're doing good. How is your day going so far?

Indelible Torch: I'm good, I'm doing well. How are you?

The Legendary Avenger: I'm doing well. I know we've had an interview since the last one. I remember it was my feedback. It was very borderline. I felt as though for senior it would have been an easy ask for staff level. I gave some recommended questions on things to look at in order to convert. So maybe give me a run through of what you've done since then. That way at least I can come in know with us new set of difficulties depending on your practice.

Indelible Torch: I haven't done a whole lot actually. I've just given a couple more interviews, just tried to get comfortable with the process and just to be able to think on the spot, organize my thoughts and present it during an interview. I've also started reading some more system design problems just to get myself familiar with a few more domains just so that if an unfamiliar problem pops up right, I might have some idea if I've done some prior reading on it.

The Legendary Avenger: Excellent. Okay. Yeah. And if I remember correctly, you are going through Alex Shu's book, right?

Indelible Torch: Yeah, I have gone through his book earlier. I just ordered his volume two. I've read like two problems from it. Haven't really read the whole thing, but yeah.

The Legendary Avenger: Excellent. Okay. And at least final line of question on that. Have you had any interviews since the last session and if so, how did they go or how did you feel they went?

Indelible Torch: No real interviews. I had a couple of mock interviews so they were both leaning higher. So that was an improvement from last time.

The Legendary Avenger: That is good. Excellent. Okay, cool. And so that makes sense. So maybe give me a run through at least for today in this case. Is there any specific aspect you'd like to focus on or do you want me to throw a problem your way and then we just agree through it?

Indelible Torch: Yeah, I think similar to what we did last time, let's just go through a problem and as you gave me some tips on what's expected out of staff level and what I can do to make sure that I don't get down leveled right. So those kinds of things would be helpful.

The Legendary Avenger: Perfect. Okay, that makes sense. I'll try and take you out of your comfort level for this one here. So I think I've been very interested in this problem because it's very fundamental. I feel like it's one of the high level ones, but we're going to try and design a banking ledger and for clarity here I'll give you some initial assumptions. That way at least we're not focused on the wrong aspect of the system. Assume the front end client exists and you can also assume it could be an ATM system or just Zelle or support for PayPal. So basically the only thing I'll note here do note that it's multiple sources of transactions, e. g., PayPal, Zelle, or even direct deposits checks. So we want to make an assumption that that bit exists. That said, when you are going through it, if you need any particular features from it, list expectations in terms of requests. So if you expect a request might come in from any of these clients, feel free to list it. Just give me the expected interface structure. But the core bit I want you to focus on is how do you even handle these requests from this system? Like if it's authentication, if it's transactions, security, et cetera. So I want you to be like the person behind the loop that nobody really knows. Now build that system out for me. Is that okay?

Indelible Torch: Yeah, sure.

The Legendary Avenger: It's a good challenge.

Indelible Torch: Sorry?

The Legendary Avenger: It's quite a good challenge based on how and for context, I'll even do this for you because I know you're a fan of Alex Shu. So I'll give you this banking ledger so that after you're done, you can go through the way Alex Hugh has done it so that you also at least have, you know, depending on what you come up with, also look into how they did it and then see if you can gain any lessons from it. Don't open this yet, but the point is, it's actually something that they discuss in depth. So I want to just see what you can do now and then how you can improve on that.

Indelible Torch: Okay, sounds good. Okay, let's start with the functional requirements. Okay, so there's like a lot of things, I believe, within a banking system or a banking ledger. So we want to at least narrow down a few requirements that we can discuss and we can go from there. Right. I guess the first thing that comes to mind is user sign up and opening a new bank account. Is that something since you mentioned that we'll be focusing on the ledger part of it. Right. So is this something that we can assume that is already done and we don't have to discuss this in too much detail?

The Legendary Avenger: Yes. So for now, assume that the user sign up experience exists. That said, there is one aspect that I'll need you to think about, and that's the authentication bit. So it will be good for you to talk about the expected protocols and mainly in light of how you use the tokens, because we expect the ledger system to be sensitive about the tokens. So just be mindful of that authentication bit, but you don't have to design the core user experience.