Curriculum - How Google Docs Works

hey everyone I think we're now live at PM lon.com um I'm just going to go ahead and check and verify that we're live but in the meantime um I just wanted to let you all know that this is a PM lesson live mock interview where we interview great PMS to do mock interview questions and this is meant as an educational tool for all of y'all to get better at PM interviews um I'm super fortunate to be here today with Ethan who got the job at Google so he's going to be a Google product manager um

and Ethan was in the PM lesson course as well and used it um Ethan would you want to go ahead and introduce yourself while I get everything set up as well sure yeah hi everybody uh my name is Ethan uh like Stephen said I am an incoming pm at Google um I just had my on-site and finished up the process here in these last few months so whole interview process PM lesson all uh very fresh in my head uh before interviewing at Google I was a product manager at a uh series B Tech startup here

called Cordoba um so I had some PM experience prior but did not have much experience with this type of interviewing and and kind of the things student delves into in the course so uh it was new for me as well and and it was a great experience helped me get the job cool um and when do you so so you're you're about to start soon right Ethan yeah um I start on the 13th of May so got a couple weeks of fun employment here um I'm actually starting interviews yeah um doing a couple days helping

helping friends wherever I can uh but I'm actually going to be in the Boulder Colorado office so I got a move in front of me um but yeah starting in two weeks gotcha wow that's exciting um awesome okay so now we can kind of go ahead and get started um and just to for the folks listening in and watching um you're more than welcome and encouraged to participate to interact to like to do all those kinds of things as we go through the interview um and we'll start off with an interview and then I'll give

some feedback at the end and then I think Ethan might also have some good stuff and tips and other stuff to chat about at the end and feel free to ask questions throughout um cool so I'm going to go ahead and get into it now and so the question that we want to answer today is going to be a technical question and so for those of you listening technical PM questions are not necessarily asked at all companies but they are asked at Google specifically um and they're in general something that I would recommend preparing at

least somewhat for for most tech companies because if the overall rule is like if you're want to be a PM you're probably interested in technology so you should be able to at least Converse and have a conversation about it and be able to have a deeper kind of conversation than uh complete lay person would um so for this particular topic though it's going to be a technical PM interview question and the question that we're asking is how does Google Docs work um and so I will go ahead and write that up on the video but

in the meantime Ethan feel free to take your time and we'll kind of work together on figuring out generally how it works and I'm not expecting you to redesign the architecture to figure out everything but just sort of um let's talk together and figure out how some of the key components of what Google Docs does uh functions under the hood cool okay so how does Google Docs work um so I'm going to start how does Google Docs work okay I'm going to start by um defining what we mean by work so um I'm going to

say um I'm going to think of kind of some key pieces of Google docs functionality and then see what we want to dive into for there so uh just GNA give me take just a minute to write some thoughts down cool take your time so uh if I'm thinking about kind of what sets Google Docs apart and what the core functionality of Google docs would be uh the first thing that comes to mind is the real-time collaborative aspect um I think you know there are a lot of text editors a lot of you know email

writers a lot of places you can write plain text have it saved that's all great but when we talk about Google Docs and kind of as we know it I think the realtime collaboration is probably the biggest piece of functionality that jumps out to me um sounds reasonable I also think um some other areas we might want to explore uh so uh storage um I've never uh hit a limit on Google Docs I I know Google has some it's either unlimited or some very high limit that they set per user kind of for their drive

storage so they must have some some creative and and kind of a good way of storing that otherwise they wouldn't be able to offer that to their users so um I'm going to start with those I'm going to start with thinking about realtime collaboration storage maybe a third one I guess would be kind of Access Control um and what can you clarify what you mean by Access Control yep absolutely so um I generally mean permissions right uh not anyone if I'm creating a Google doc uh not anyone from anywhere in the world can access it

with a public URL right there are uh steps in place to make sure that either I'm working on it or people that I've approved are working on it um so I I can see actually how access Access Control what I really mean by access control is permissions um because it sounds from the words access control like I might mean um who's writing what but that I'm actually going to talk about in the realtime collaboration piece um so uh I think I'm gonna I I think those are kind of three big pools of functionality to to

start thinking about the one that I to dive into first is is the real time collaboration what do you think about that sounds good yeah I I agree it sounds like it's the as you mentioned like one of the main features of the product basically so yeah let's start talking about how that functionality works great okay uh I don't have a whiteboard so I'm gonna be using pen and paper try so everybody can see um so what do we mean I guess first I want to establish the problem space um like what what do we

mean when I say Google Docs facilitates realtime collaboration um so I'm going to draw a little diagram here um okay so what I generally mean if you can see my screen here is um I've got two boxes drawn for clients and what I what I mean here when I say real-time collaboration is that these clients as we know you know in web development clients uh usually represent an end user right so these are essentially two people logged into Google Docs working on the same document at the same time and uh we all know from using

Google Docs or if you don't this is definitely a main tenant of Google docs um that I can be working on a document and Stephen can be working on a document and we can both be typing at the same time and and our updates don't kind of wipe each other out right we both get to persist our updates um so that's kind of what I want to explore here uh how might that work first what are the challenges we face in doing that and and how might Google will go about achieving that cool that makes

sense and thanks to the diagram it's it's visible so works well yeah okay so let's say um client one and client two are both working on a document and the document just says dog okay okay both users see the word dog on their document and then let's say that uh client one a user go goes and tries to insert an X between the O and the G and at the same time client two goes in and deletes the G so basically client one added an X and this is what they expect to see but at

the same time client two deleted the D so this is what they expect to see so let's say we weren't worrying about like people updating the same dock what um what would happen here well client one would basically just submit a an API request like a post request right and they would say here is my new value it's dxg so they would just post that they would get the response back and they would see dxg client two would post OG so client one would submit a post request they would change their value and get it

back client two would submit a post request change their value get it back okay but what if they're collaborating on the same document okay this is one of the problems I want us to discuss uh so this is an issue of concurrency um concurrency I'm defining here as like when two processes are trying to act on the same thing right uh two actors so here it's two clients both working on the same document both trying to update the value what happens there right and so concurrency is is one element that I'm going to talk about

here um and the other element is updates so Ste again say it's it's me and Stephen here um we both go update the document um how does the document deal with our concurrent updates and maintain one source of Truth and then how does it push those updates back out to us those are I think the two problems I want to approach here how does gotta yeah that sounds great okay so first let's talk about uh concurrency so um and and what I'm trying to think about here is is how might Google handle this problem um

so there are obviously various ways to handle both of these problems the can currency and the updates um one thing that comes to mind here for handling concurrency um is the idea of uh so we can even go back to what is the point of having a server here um to navigate between these two clients well the point is to maintain one single source of truth right um and so what we're really talking about concurrency and pushing out the updates are just problems that arise when you think about a server as being the single source

of Truth so um how could we go about creating that concept of kind of a single source of Truth on the server well in this let's go back to this post request so let's say again I'm trying to um client one I'm trying to insert that X that request might look something like insert an X at index 012 right so say my post request looks something like this I want to insert an X at index 2H okay so I subm that request Steven is working alongside and he submits his delete request which is delete a

d at index zero okay so now as these come in let's say the delete comes in first so these essentially will be processed in a Quee by the server right first in first out first action the server gets it's going to perform on its version of the document which is the true source of Truth so let's say it gets Steven request first so in its CU it's got first a delete and then an insert well when it deletes the D then the source of Truth on the server so the source of Truth on the server

was doog then it becomes OG okay so how does that change this request well we are no longer inserting the X at index 2 now we're going to insert it at index one right so basically my proposal and the way I think Google handles this is by uh this is a concept um that I'm I'm previously familiar with called operational transformation and basically what this means is uh the server maintains its own State its own state of the document as we talked about source of Truth and whenever it gets requests um and those requests modify

the document the server keeps track of how the document was modified and changes its Todo list accordingly so basically what it would do here is instead of saying insert xit 02 it would say ah okay I now know that I got rid of an index to the left so I need to insert X at index one and that is a concept called operational transformation and that's how I think uh Google goes about again the concept here is as long as we have this state on the server then at least have kind of that one single

source of truth that we're going to get out to all the clients awesome yeah go ahead yeah I was just going to say I think the core idea here is server is maintaining its own state of the document and it's doing so um using a Q and so to I think that's a great explanation and and really great detail like love the diagram I'm curious to push it a little further like what happens when an operation can no longer be performed um like P perhaps it was a delete like two deletes right like I deleted

do and you deleted D um or you know there's a couple other cases where there may be cases so you're you're saying we're transforming the operation into a new operation but what happens when we can't do the operation at all that is a good point um so right let's say um we are both okay so you delete do and I delete D um okay give me a second to think through that one sure so first you delete do the server processes that request that is part of its state of Truth so all that's left on

the server is a g and then I go in and delete try to delete the D um so I think my first inclination is if it turns out to be a no a no operation after um we process that second request we could just invalidate it so if you deleted do and I go to delete D but we see that D is no longer there so on deletes I think we could end up having a no up right I go to delete something it's already gone um inserts I think would be different um because if

I go to insert an X there's no way that you went I guess theoretically you could have inserted an X in the same place but we can't tell if you intended to add the same X that I intended to add so I think safest way to do this would be if their overlapping deletes invalidate the second one but if they if we both add an X at the same time in the same place I think you have to process both um and render both so that users can then determine uh what to see and actually

the good thing about another thing I wanted to mention about this queuing system is it gives you almost like a history of sorts right so I could then see Stephen did this Ethan did this I could show that in a history module somewhere I could use it for undos command Z right I could just kind of go back to the last operation um so yeah that's my first inclination invalidate deletes and do a kind of super set of any inserts cool I I think it's a great response I'm I'm curious are there any other edge

cases um that we need to worry about and then taking that question a little even a little bit further like given that there are probably some weird cases or you know maybe I wanted to delete only the D and I'm really shocked when the do got deleted you know um how might you communicate some of these ER or potential like conflicts to the user um so the first part of that question is are there other edge cases the second part is how do we communicate some of these conflicts that may emerge from these edge cases

to our users and when do we decide to do that yep great questions um okay so uh I do want to take a few seconds educ don't take your time of course it's a great uh to to the listeners watching in while while Ethan is thinking too um it's always great to pause during interview questions it's always recommended and one of the biggest mistakes um in addition to that if you guys are watching right now um we love it if you could like us or subscribe or just hit that like button down below um it

really gives us a positive signal that these are really helpful videos and helps us encourage whether or not to make more of these and how to best spend our time so if you're enjoying watching this video we would really really appreciate it for you to like and comment below so so um yeah I'm trying to think about um what other so I think everything does boil down to either an insert or a delete um whether you're copy pasting you know bulk deleting all these various operations still break down to an insert or or delete um

so yeah I'm actually um are there any edge cases that that you were thinking of I'm really not seeing to be honest I didn't have one in my mind I just wanted to kind of probe you to think about it further um but like the main question that I actually wanted to ask was a follow-up where it's like let's say that we have a con a delete conflict or something or like you know something kind of goes weird where what I expected really really was changed um how like when would you communicate that to the

user what tools would you offer the user to navigate sort of that you talked a little bit about control Z but I'm just curious like what else might you think about in terms of Designing that product with these technical constraints in mind okay great um so yeah I think um so we've talked about the real time collaborative aspect and that's what we're focused on here so really I'm I'm just trying to come up with um some cases that I might want to communicate to the user and see if I can kind of pull a bigger

communication strategy out of that um so I like the case you offered the kind of delete D and delete Doo um so I'm gon to think through that from the perspective of each user um so Stephen goes in deletes do I had just deleted D on my side or been attempting or yes I had just deleted D um and now what I get back is just the G um so uh one of the ways I think Google it didn't occur to me immediately but now of course how does Google handle this uh they show you

where the other users are typing right where their cursor is um so I would in that case hopefully see Steven's cursor blinking right there I would see uh you know I I think I'd still be a little confused but I might get uh Stephen deleted the D and the O but let's say I didn't how would I then understand you know this isn't a bug this isn't an issue somebody else actually deleted DM the O um again I think um a history of some sort like a change log an audit history um that updates live

uh using you know some kind of server side technology which we can speak about in a little bit um the cursor um the live audit log and yeah the only other thing I can think of that you might want to communicate or or method of communicating to the user you might want to use uh might be like uh no so one thing you can always do when a user tries to do something and it fails is notify them right um error messaging something like that but I don't think this is a good place for that

for a couple reasons one because it's not an error right it is actually collaborative editing um the the fact that we couldn't process the request is an error but from a ux perspective we don't want to tell the user something went wrong right because nothing went wrong um so that could detract in confidence in the products and all these things that we don't want when when nothing went wrong um I I guess we could say something like somebody already deleted what you're trying to delete um but again you know I don't think I think if

we do the kind of the cursor plus the audit log correctly um I I don't think you want to distract the user is primarily there to write content um so I don't think you want to distract them too much you know have things pop up all over the screen I think you want to allow them to write and I think if we do a good enough job with those other two features we shouldn't need a warning notification cool love it um yeah I think the cursor point was something I was a little bit trying to

get out there with that with that sort of question which is just like yeah the in and product we also we have to consider the technical issues but we also have to consider the UI um elements that can help operate around those technical constraints and help like clarify communicate to the user so it's great you picked that up on your own one thing I would like to do here I just add um you know whenever uh I'm juggling kind of a technical challenge um it's oftentimes technical challenges seem a lot worse on the back end

than they are to the user uh so this is definitely the sort of thing I would love to experiment with C users with it Hands-On see if there actually is any friction there and if there is a problem to solve because if not we won't solve it yeah it's a good point like I mean what we're talking about is technically a very small case where like you and I are maybe editing at the same time and we happen to be editing the same word like it it definitely happens at the scale of Google docs is

operating at but if we were starting Google Docs from scratch I'm not sure that we would worry about that feature so much in the very beginning you know or maybe we would find another way to operate around that technical constraint that's like much easier and we don't have to worry about it um cool well I do want to touch on um so this is great I do want to touch on the other two topics you mentioned about storage and permissions and just maybe briefly go through them maybe we can spend about five to 10 more

minutes on on this part um and then we can kind of do the feedback and wrap up and have the tips at the end sound okay sounds great um okay so for storage um I'm just going to kind of hit some highlights of uh you know things I think Google Docs does and why I think it might go about to end in that way cool um so first of all um in terms of storage first thing I want to think about is like what do we have to store right almost an informal DB schema um

so we definitely have to store um you know for for each record let's say for each each document as a record we've got like a user ID um all the the unique identifier um we've got but the part I really want to get to is the content so I'm going to kind of skip the other columns um how do we store the content um so my first thought would be uh plain text right um it's words uh at the end of the day that's what a user is writing words text that's what they care about

but um as soon as I jump into Google Docs and play with it I start to realize there's also formatting right um so and Google definitely preserves formatting right if you bold something you leave the the page you come back to the page it's still molded so they are uh persisting that uh uh Beyond in memory they're persisting in in persistent storage somewhere so um my thought would be probably to use markdown uh to store uh you know I think there there are many different ways you could retain knowledge of this formatting and these sort

of metadata pieces about the text but I think markdown would be the best one uh you know just think about what Google offers Bolding italics underlining um those are generally covered by markdown so I think you could kind of have a column which is the text plus the markdown um and then you can basically serve that column uh as a markdown document uh in the browser to the user um another thing I want to say with respect to storage is um you know I I do think this n this data I'm not going to go

so far as to take a stance on if we should use a normalized or denormalized database um I do think this data is relatively denormalized um there aren't and what I mean when I say that there aren't a bunch of joins and linking tables we're going to have to do to get kind of the The Logical data that we want Al together uh so I think we could go with kind of a document based storage which tends to be more performant at scale fetch that data more quickly Etc I I think the only other thing

maybe we'd want to store some sort of file structure so we remember folders files that sort of thing um but yeah it'll it'll essentially be marked down with some sort of file file path [Music] metadata cool and uh yeah keep going if you you wanted to keep at it more um that that was kind of is there anything else you wanted me to touch on with storage no I think it's good I I think what what I I I'll give you feedback at the end about that one I thought it was great uh short analysis

given like we were trying to be a little brief so that was great yeah cool and then the last one um uh access control and permissions um I'll kind of talk about how I was going to approach this one in the interview at the end as well but uh I think what you're trying to do here is essentially another column in that database is something like um what users have access to this right um so uh I invite Stephen when I invite Stephen we go record his ID in a column in the database that says

yes this user can access this document um and maybe you even have another column for permission level View suggest edit um but yeah you know again I think uh that that kind of goes to storage we don't need to create some huge users table that we link to you know I think we could do this through through a denormalized data set just putting it in another column cool um all right I I don't have any further questions for you about that question so I'd love to kick it to feedback so we can fit in um

also your general tips at the end too um I overall thought this was like a pH phenomenal answer and you clearly know your stuff so really really great job shows how you got that Google PM interview so overall like really great congratulations on on this interview and everything um I wanted to comment on some of the things that I thought you did really well um and in throughout that I'll also comment on opportunities and improvements as well and for those listening in and watching this is a good time for you to comment ask further questions

um we'll do a little bit of Q&A too so feel free to chime in there um and we'd love to kind of hear from you as as well um so the diagram was amazing so that was a really really great visual way to explain what was in your mind and one huge error for a lot of people is that they don't use the Whiteboard and this clearly begged to for the Whiteboard too so it's I'm really glad that like despite this video chat stuff you like held up the the paper too um so and I

think that that just made your answer so much more clear and crisp and one thing that I liked about using that example is that you made it very personable so you were just like you and me like we're the two people and we're using a word dog right so you're not talking in the abstract you're using concrete clear examples with visual cues to identify and communicate to the interviewer what's in your brain because part of the whole problem is communicating what's up in here to the interviewer um the fact that you paused was really great

um I love that you even started off the whole interview by defining what work means so like we're kind of starting off the definitions like so how does Google Docs work or like how does whole thing function is that what we're trying to answer and and kind of checking with me I think you could have asked me more follow-up questions about that too so you know you you could have instead of assuming you could have even taken the time to be like oh so what do you mean by that like what aspects of Google docs

um are important and I know you did ask that to me at one point um but just I always really encourage like asking as many questions in upfront as possible y um I love that you handled the follow-up questions really well and you really did a good job of kind of thinking through the user perspective I remember there was one point where you weren't sure how to answer something and you did a really really good tactic that I encouraged all you listening to do as well which is like okay let me think so if I'm

sitting there and I type in doog what and I get this back what and you're kind of walking through your thought process with the interviewer that is like super super good and super skilled um and so that sort of uh explaining your brain to the interviewer and really thinking from the user perspective is a really great way to think is just a PM in general um I another couple comments I had was that I loved that you talked about the UI aspect of it I think we could have brought that in a little bit earlier

um so I know I prompted you for it but you know it's interesting because PM technical questions are never truly just technical like what they're really assessing is how can you operate understand and deal with technical constraints in a way that can relate to the product overall so adding a cursor is like a really simple thing that adds a lot of safety to the user in terms of knowing what what's going on um there's version history there's error messages which you mention also you eventually mention a lot of these things but these little cues really

do matter and it's really cool to talk about them mpm interviews because they're sort of inspired by the technical feasibility issues that we might have with Version Control um also thought that um you you yeah I think bringing up edge cases on your own is also just makes it really strong too so that's just further on that point um and then on the last section just the last piece of feedback I thought you did an excellent job of kind of discussing trade-offs and I loved especially with the markdown uh part you started like the naive

approaches to doing plain text and then what do we like okay so you know does plain text work okay no we need these things so then what do we add to it right um and I thought that was just a super excellent way to kind of walk the interviewer along with you and I think that was something you you're really really good at um so overall like super positive feedback this is a stellar interview thank um so yeah just wanted to congratulate you and do you have any reactions or thoughts sending that feedback yeah I

do um so one thing um I've actually noticed about myself uh in these interviews interestingly like if I get a question and I feel like I know it or I feel like uh I know how I want to go about approaching it I almost have more difficulty structuring my answer uh because you want to get to like what you know so quickly right so I think uh that's one of the reasons I think I skipped over some of the clar find questions here um I almost move too quickly when uh I know where I want

to go from the start so that's one thing I'd say U to the viewers is uh you know if you and this is one thing I want to talk about a little later you know ask your question and you feel like you know where you want to go um you've got an advantage right like you're kind of winning already at the interview so you kind of want to hold on to that and make sure you Pace it right and uh don't jump into something that maybe they didn't even want to hear about uh that's a

really good tip yeah so that's my first my first kind of reaction and then uh my second reaction um I was another thing I wanted to bring up like I almost um when I defined the kind of things that I thought we might want to talk about real-time collaboration storage access control um I did so kind of knowing that I was going to be stronger in the first two than the third um so you know that that's that was kind of you know I I intentionally used most of the time talking about realtime collab because

I think um you know this is one of and then I'll just kind of dive straight into my my tips and maybe we can maybe we can cue it off just so that uh we can separate the video but and so now you know just want to let everyone know that we're now gonna kind of transition a bit into you know we just did this awesome interview with Ethan um where he answered how Google Docs works and now we're really excited to have Ethan talk and share a little bit about his tips for interview