3 ms·

Let me give a cautionary tale in the form of an ad (my email is in my profile). Full disclaimer: it's both, but the value to the discussion is the cautionary ta

Let me give a cautionary tale in the form of an ad (my email is in my profile). Full disclaimer: it's both, but the value to the discussion is the cautionary tale part. Feel free to ignore the ad part. Edit: I tacked on a perspective how I started to like leetcode questions, I hope that helps people find some inspiration to get through the leetcode grind. If I can do it during the evenings, then so can you! ;-) I'm looking for a FAANG internship and/or entry level job opportunity. Years of experience: 1.5 years Academic degree: bachelor + master computer science. Interview preparedness: 100 leetcode questions, 30 easy, 50 medium, 20 hard (my opinion on them: I like them). Average solving time: 30 minutes for leetcode medium (not quite FAANG level yet). It may seem I aim the bar a bit low. Here is why: after graduation, I took a gap year and because of that missed the graduate loop. Before I knew it, I couldn't apply to FAANG anymore because I was not a current student (for internships) or a recent graduate (due to gap year). I also didn't realize that being from Europe would hurt my chances somewhat. It took me quite a long time to realize this, and now even more time had passed (after many rejection emails and 0 phone screens). So, it is possible that you may get top marks at your master program. It is possible that you did a bachelor + master and have TA experience during your degree (that I'm not counting here as experience). Yet, FAANG can still completely ignore you, because you didn't know you should be applying for internships when you're in your second year of your bachelor. If I could redo it, I would: * Get a real developer job as soon as possible * Start leetcoding in my 3rd year bachelor while applying to internships * More leetcoding during my 2 year master + applying to internships + getting actual developer work experience (actual dev experience trumps TA jobs) This is why I'm open to internships and/or graduate positions. I'm not good enough at systems design. However, with coding, I think I have a clear shot. To the leetcode naysayers: I used to dislike leetcode questions too. However, I've noticed simply by practicing it, it does become easier over time. More importantly, you have to own it in a way that suits your personality. In my particular case, I view data structures as organisms. I use plants a lot to visualize linked lists and trees. An array + linked list is a brick wall (array), and a vine (a node looks like a vine leaf). Traversing that linked list is dying the whole vine a certain color. Stacks are actual stacks, queues are queues of people, a set I need to iterate through (like an array) looks like my laundry basket, etc. I love visualizing data structures like this and it gives me a sense of wonder. That sense of wonder translates into motivation, and that's how I'm owning it with my personality. Currently, my only real weakness is dynamic programming, but I'm confident that I can master it over time :) Full disclosure: recently I have been rejected by all the FAANGs again (outright, no phone screen), except for 1 and I've finished their onsite and am awaiting their result. I'm horrible at systems design though and wish I could interview for a graduate position. If someone could help me apply for a graduate position (internship or job) despite my unusual circumstances, I'd appreciate that.

frfl 5y ago
If it helps, I didn't really start to grok system design and architecture until more than 2 years full time. Before that it was just a bunch of functions/methods, classes that used each other. Slowly though, you start to notice the patterns, you see what failed badly and how it failed (bad design). You get burnt having to solve problems in badly designed code. You get stuck trying to test badly designed code. You slowly see the bigger picture, how to put together these small pieces into that complete application that isn't a tangled mess and unmaintainable (bad design = maintainability being inversely related to time * functionality, or some equation of that sort). Of course this has nothing to do with what system design questions (most) interviewers care about. But this is the system design that matters on the job. Read books for the real system design after you land the job, they won't really stick before you get expeirence - refactoring legacy applications, pragmatic programmer, clean coder, clean code, clean architecture (all clean books are by 'Uncle Bob'). For interview system design (I'm not speaking from too much experience here), youtube has some good videos "software system design interview", I've seen "grokking the system design interview" book being mentioned. Good luck. Hope this helps somewhat.
- makmanalp 5y ago
  > Of course this has nothing to do with what system design questions (most) interviewers care about. But this is the system design that matters on the job. Sigh. I just think it's so absurd that "system design" is now an interview category that's expected of new grads. I'm talking about the fanciful form of this, where the bright eyed and bushy tailed new grad is somehow working on a problem that is the equivalent of the Large Hadron Collider or the Apollo space program. I've sat on the other side of these interviews, and what I'm hoping for, especially from beginners, is just some common sense, and some reassurance that they can identify at least the main design tradeoffs and make appropriate decisions based on the information available. And then we look at what should happen to the design of our system if I modify our assumptions, or add new use cases that create new forms of stress on the system. What I get instead is stuff like "I'll use a key value store", and when I ask why, I get "because it scales better", and when I ask "compared to what, why, under what conditions", I get blank stares, because they've barely used either. Then I learn that they said a thing because they read some github repo with 100 system design questions that said so. Or they read a prep bible that told them this is how Google does things. Or they read an actual book about a subject (a bit better) but didn't really absorb the ideas (which is fine! happens to me too!), but wanted to use the thing they learned about anyway. What I actually wanted was "because the data is simple and non-relational and this will suffice for the foreseeable future, and features XYZ help remove complexity from the app" or "this is a single-purpose system designed to do one thing very well, and we can pack a lot more storage / throughput per node this way" or "Never mind, the requirements and the future are fairly vague, I'll just use something I understand well, is flexible, well supported and easy to migrate out of" or ANY sort of sense that we do things because of reasons, and we don't do things if we don't have good reasons to do them. I remember being a beginner too - not knowing things and inexperience is perfectly fine, the point is we want you to do your best with what you have. It's fine to be honest about your knowledge and capabilities. You can look silly otherwise. What are fairly nuanced, philosophical or "it depends on ..." questions to me after two degrees and almost a decade and a half into my career, for some of these folks is "of course it's X", and I'm just flabbergasted at the level of confidence that's projected. Please just a) exercise judgement b) based on the facts available c) leveraging your existing knowledge of core software concepts. Try a design, say why you did each thing this way, say what you like and don't like about it, say what you're uncertain about, what a few alternatives would look like, what you don't like about those, and what you'd change if you had a bit more information. This is the kind of "how do I do this" thing everyone building anything should be doing every day. It's not impressive for you to be able to regurgitate the X types of cache policies according to wikipedia. It is, however, impressive when I point out a potential problem with the way you set up your caching scheme, and so you look at what you designed, actually think about what that means, and are able to tweak it to better fit the requirements. I don't mind whether you're aware that you just re-discovered a thing that already has a name. My plea to whoever is posing and judging these system design interview questions in this way causes young interviewees to think they need to participate in a kind of veteran staff engineer cosplay tech-braggadocio circus: for god's sake, just test what's required for the job, please and thank you.

frfl 5y ago

If it helps, I didn't really start to grok system design and architecture until more than 2 years full time. Before that it was just a bunch of functions/methods, classes that used each other. Slowly though, you start to notice the patterns, you see what failed badly and how it failed (bad design). You get burnt having to solve problems in badly designed code. You get stuck trying to test badly designed code. You slowly see the bigger picture, how to put together these small pieces into that complete application that isn't a tangled mess and unmaintainable (bad design = maintainability being inversely related to time * functionality, or some equation of that sort). Of course this has nothing to do with what system design questions (most) interviewers care about. But this is the system design that matters on the job. Read books for the real system design after you land the job, they won't really stick before you get expeirence - refactoring legacy applications, pragmatic programmer, clean coder, clean code, clean architecture (all clean books are by 'Uncle Bob'). For interview system design (I'm not speaking from too much experience here), youtube has some good videos "software system design interview", I've seen "grokking the system design interview" book being mentioned. Good luck. Hope this helps somewhat.

makmanalp 5y ago
> Of course this has nothing to do with what system design questions (most) interviewers care about. But this is the system design that matters on the job. Sigh. I just think it's so absurd that "system design" is now an interview category that's expected of new grads. I'm talking about the fanciful form of this, where the bright eyed and bushy tailed new grad is somehow working on a problem that is the equivalent of the Large Hadron Collider or the Apollo space program. I've sat on the other side of these interviews, and what I'm hoping for, especially from beginners, is just some common sense, and some reassurance that they can identify at least the main design tradeoffs and make appropriate decisions based on the information available. And then we look at what should happen to the design of our system if I modify our assumptions, or add new use cases that create new forms of stress on the system. What I get instead is stuff like "I'll use a key value store", and when I ask why, I get "because it scales better", and when I ask "compared to what, why, under what conditions", I get blank stares, because they've barely used either. Then I learn that they said a thing because they read some github repo with 100 system design questions that said so. Or they read a prep bible that told them this is how Google does things. Or they read an actual book about a subject (a bit better) but didn't really absorb the ideas (which is fine! happens to me too!), but wanted to use the thing they learned about anyway. What I actually wanted was "because the data is simple and non-relational and this will suffice for the foreseeable future, and features XYZ help remove complexity from the app" or "this is a single-purpose system designed to do one thing very well, and we can pack a lot more storage / throughput per node this way" or "Never mind, the requirements and the future are fairly vague, I'll just use something I understand well, is flexible, well supported and easy to migrate out of" or ANY sort of sense that we do things because of reasons, and we don't do things if we don't have good reasons to do them. I remember being a beginner too - not knowing things and inexperience is perfectly fine, the point is we want you to do your best with what you have. It's fine to be honest about your knowledge and capabilities. You can look silly otherwise. What are fairly nuanced, philosophical or "it depends on ..." questions to me after two degrees and almost a decade and a half into my career, for some of these folks is "of course it's X", and I'm just flabbergasted at the level of confidence that's projected. Please just a) exercise judgement b) based on the facts available c) leveraging your existing knowledge of core software concepts. Try a design, say why you did each thing this way, say what you like and don't like about it, say what you're uncertain about, what a few alternatives would look like, what you don't like about those, and what you'd change if you had a bit more information. This is the kind of "how do I do this" thing everyone building anything should be doing every day. It's not impressive for you to be able to regurgitate the X types of cache policies according to wikipedia. It is, however, impressive when I point out a potential problem with the way you set up your caching scheme, and so you look at what you designed, actually think about what that means, and are able to tweak it to better fit the requirements. I don't mind whether you're aware that you just re-discovered a thing that already has a name. My plea to whoever is posing and judging these system design interview questions in this way causes young interviewees to think they need to participate in a kind of veteran staff engineer cosplay tech-braggadocio circus: for god's sake, just test what's required for the job, please and thank you.