I disagree with this resume advice actually. He for example removes that he was in the military sniper team and won best shot, but keeps high school education? I would totally say the opposite, keep the cool the side thing that's a conversation starter, but remove irrelevant educational experience.
Including the number of stars on the github projects they worked on seems so.... narcissistic? Promotional? Idk but its distasteful and I would probably throw out the resume at that.
I really think all of the resume changes, other than the incoming intern at bytedance were extremely bad changes. It went from someone who is smart, with a breadth of experiences, to someone that is obsessed with social media likes.
I would modify the cool side thing (being a sniper), if it highlights leadership skills, collaboration, and determination. There are many opportunities to develop these and many more in military and other roles before you get a first real job.
Depending on whether you took advantage of the opportunity and who you are interviewing with, it can be a strong differentiator and set you onto a quicker path to promotion.
The stars part is flawed because it's set against the 19 commits which don't really quantify anything. Both these miss after some good build up around the adoption of the Docusaurus. It'd be better to have a description of the impact of the 19 commits.
I think a better quantifier than just "X commits to Y project with Z stars" would be something along the lines of "Implemented A, B, C in X project". Stars don't seem very useful.
It would only be that if it wasn't something everyone did. For most it's more of a reluctant necessity rather than being something they relish. And imo reflecting that in its tone is of value.
I don't mind the stars, I wouldn't discount the resume based on that, but the changes themselves seemed useless. Having looked at many resumes of candidates, I scanned both with my "looking to hire" hat on and quickly determined, 1) is a grad and seems smart 2) is involved with open source projects and seems to enjoy creating software, on that basis I'd bring them in for an interview
It is widely suggested that resume should be as metric oriented as possible so I wouldn't think anything bad about the stars. It is similar as to "I built X to increase Y by Z.". It does show impact.
Definitely wouldn't throw a resume out for something like this even if it for some reason is a pet peeve for you.
However I agree that cool things like the military sniper thing should stay.
To me the stars seem more similar to likes, follows, and subs.. a popularity metric for social media. And unless it spells that they're big, it actually gives me a rather negative vibe. Assuming I'm hiring for a technical role, I'd be unimpressed to see someone attempt to flaunt the 10k karma they scored on HN or the 150 followers they got on twitter.
Also as others point out, if you don't see what their contribution is, it seems even more flaunty. "Talked to a guy with 100k karma"? It's pretty easy to sneak a few low-impact commits into big and popular projects.. (speaking as someone who's got a commit or five e.g. in Mozilla Firefox)
Github stars show the developer is either good at creating a project that serves a real need or at least decent at marketing their project, which in a startup role might be useful when you need somebody doing multiple things
Maybe it's just me, but contributed to X with no more information does not strike me as compelling. My initial assumption would be that they didn't do anything. It did not say created it, it did not say primary maintainer, or wrote X feature in Y.
I know of a company that requires (or at least did a few years ago when I interviewed with them) new grads to have a GPA in of at least 3.0 out 4.0 to even be considered for the position (US-based aerospace company). A classmate of mine had circumstances (mostly out of their control) that caused their GPA to be lower than the threshold so they couldn't hire them despite them having glowing recommendations from current, highly respected employees. The hiring manager wanted to hire them but couldn't. So they were brought in as an intern and was hired as an "internal hire" in order to bypass the hard GPA requirement.
I never put my GPA on any resume. I had a garbage GPA because the only classes I went to were CS classes so I got horrible grades in all my required electives. I was worried someone would ask and no one did.
Back in 2004, I had a phone screen with the folks at Time, Inc., for a systems admin position. Now, I'd been out of school for about 10 years at that point. The interviewer's first question was "what was your GPA in college?", and I was forced to confess I honestly didn't remember.
He stammered a bit, apologizing, and then hung up on me. I've always considered that dodging a bullet. It's a weird thing to ask someone with many years of professional experience. The only thing I could infer was that all of their staff were very young, and this was still relevant to them.
I remember an interview with a French company (in the UK) a few years ago - when they realized I had arrived in tech via a vocational route it got very frosty.
What can people even do with that info though? You can’t compare universities as each course is different. So I guess you can compare two people at the same university? Not very useful is it.
Another data point to back this up: we've had hiring managers provide resume reviews for over 1000 students at CodeDay and "remove your GPA" is the most common feedback. I don't recall ever seeing someone say to add it.
As a new grad I didn't have my GPA on my resume and it never actually came up except for the occasional transcript request. I had a fine GPA, but not high enough for it to be a nice datapoint.
I had plenty of interest with lots of companies, including many FAANGMGOEWVIOPJW companies.
Maybe things have changed, but when I went to career fairs as a uni student in the 00s they all asked for my GPA. Less than 3.5 was pretty much an instant no.
I'm talking like 2012-2015ish here. I was never asked for it specifically, or asked why it was not on my resume. A few big companies asked for my transcript, but that's all. I don't even know if they looked at it.
I had about a 3.5, so nothing to write home about. Got offers from a few big tech companies.
I really think they didn't care, unless my barely 3.5 GPA just made the cutoff when they looked at my transcripts.
That's not true. Projects, internships, and interviewing skills are how you get into companies as a uni student. GPA is maybe required for some, but it's definitely not the only thing a uni student should be showing.
It sure is a great way to discriminate against those from working class families though - the kind of people who won't have had much access to private tutoring.
The last time I interviewed, I did it full-time for about a month. Was kind of fun actually: you're solving isolated little coding problems, talking with companies about their engineering and business challenges, meeting smart and friendly people, and at the end of it all you get a big pay raise. The downside is mostly that it's a ton of scheduling calls and on-sites (back when those were in person).
At the end of that month, it really did feel like I was a professional interviewer.
Except for all those stories of people who have been interviewing for months but can't seem to land anything. Much better to realize you have developed some behavioral problems and seek treatment for them while you are employed rather than after you leave your job.
The inability to listen to people judge you for not knowing the answer to arbitrary and contrived problems?
I’ve been a valuable professional for years, and then this little snot tells me I don’t qualify for his position because I don’t know what happens when you sum two arrays in Javascript? Fuck off.
Yeah, that really happened (well, similar in nature if not exactly the same).
These are the kind of questions I do not know the answer to because no sane person ever does that.
I tried explaining as such, but I think the interview was on a downward trend after that.
I think we were supposed to discuss their take home assignment, which I thought was actually great fun, but the interview was a JS pop quiz instead because they probably didn’t inform their interviewer correctly.
Did you get visibly pissed off with the question? That might be why the interview went poorly. Whenever I get pop quiz questions, I just say I don't remember and if it came up in a real codebase I would test it in a REPL to see what it does. The interview carries on normally after that in my experience.
Except that experienced devs could well have forgotten (at least to the point of it not being in immediate recall) more than they currently "know".
I couldn't remember what happens when you sum two arrays in JS, just that it's weird and you probably shouldn't do it. So I remembered the useful part, but not the trivia.
(FYI, array1 + array2 casts the arrays to strings and then concatenates them).
i mean no sane company/ interviewer weighs the entire interview on a pop quiz question. But imo they are fine to be used in the process (in tandem with other stuff). you can't claimed to be expert on the language without getting any one of them correctly
also, the way the interviewee handles the stuff they dont know
The hell with the person's ability to learn new stuff, navigate JS's epic ecosystem, and keep himself on par with new developments and the trends. Summing js arrays is where it's at and tells the interviewer the whole story of the candidate's understanding of the language.
about tech interviews, the way you handle stuff you dont know is also important. I didn't say he deserved to be rejected because he didn't know what summing 2 arrays results in, but the interviewer was fair to ask that (if the position was about javascript). and yes if you were the interviewee with this kind of attitude I'd reject you on the spot
Of course it's fair and by the rules - at least technically. It's the practicality of it that is questionable. But you have to experience the hot seat yourself and get thrown at tons of tricky and obscure things one interview after the other in order to understand that frustration.
I was like what's so offensive about Array concat()? Oh you mean "+". Yeah that's basically trivia night at the pub. When is trivial pursuit coming out with the JS edition?
I've been an interviewer with Karat for 2.5yrs, it's genuinely great. https://karat.com/
I know you made the statement in jest, but trying to improve on the interview process is not a bad idea. At the very least, it's less engineering time wasted conducting interviews.
I had an interview with Karat, it was nice: very fast and professional. Only thing that was slightly frustrating at the time was that you guys insist on completely correct solutions. Also, the behavioral part at the beginning felt kind of forced.
There are no behavioural questions, the intro bit at the start is just there to not abruptly start asking questions, help you relax a bit, and also nice in case the client wants to look at the video to find out more about you. We do insist that your code works correctly, that's true. We're not overly anal about the format of your solution, but we do expect to cover all edge cases.
If your question is specifically referring to the leetcode style coding interviews, this is exactly how Silicon Valley engineering careers work if you want to change jobs.
I've worked for some very big name companies that millions have heard of. I have only had to do a coding challenge once, and that was not for any of the big fish.
I imagine we operate in very different geographic regions of the USA.
I do. I used to reject recruiter's advances the moment they described the interview process as a leetcode-hazing ritual (my words, not theirs), but as I've become even more grumpy/depressed over the poor state of things I might take it step further and start wasting their time (interviewing and then running the interviewers in circles for a while).
I wouldn't want to work with someone that doesn't have their fundamentals down. Most people spend at least 4 years studying CS, they should know their stuff.
You'd probably be surprised how many people you've worked with who are quite competent if not really great at what they do and have gaping holes in what you might consider fundamentals.
I studied CS for 4 years and have used exactly none of it since leaving college. Our devs all help with hiring and agree as a 20-person team that academic "experience" means almost nothing unless you have no other job experience. How little academia prepares you for anything in real software engineering has become a cultural meme.
For myself at least: absolutely yes. That's actually some of the first stuff they taught us. Would I want to be interviewed on whether I can implement a linked list from the top of my head in an arbitrary language and 100% correctly in a high stress interview situation? Absolutely not. (and a linked list in the end is something really really easy if you ask me)
Does that in any way relate to what I'm doing right now? A little! This will differ depending on who exactly you work for and in what role. It certainly helps to have learned this stuff. I can honestly say that it was fun seeing how regular expressions actually work, how you implement a parser for it etc. But then you learn as well (right there in university) that you better use a parser generator after just having defined the grammar instead of writing it yourself. How many jobs are out there that require you to write a grammar for something? To create a new language? Very very few. There's a market for "boring business software X" software developers.
Is it the most important thing I consider when hiring? Absolutely not. We also don't pay FAANG salaries where I work. Do I want capable software developers? Smart guys for sure. People that are curious, willing and able to learn, writing maintainable code. Guys that if I tell them that there's a hidden n^3 algorithm in what they just wrote and it _does_ matter for the (relatively small but large enough) volumes of data this will run on can look up/ask for what that means.
EDIT: interesting down votes. I hope someone will reply to explain. I certainly don't see why we can't have a civil discussion especially given that we seem to agree on it having been good to get a solid university education. FWIW I have a Master's in Computer Science. From a country that values non university education (Germany - where you can do vocational training to become a programmer. Just like you can become a master carpenter through that system).
Fully will back you up on this. One does not have to be a metallurgist to be the best welder. In fact, your metallurgist might get a bit too clever playing with alloys when they need to focus more on getting the weld clean.
It’s also really downplaying how much one can learn when they need it for an application - yes it’s true you have to know about something to go after learning it, but there’s nothing stopping someone picking up a book when they get stuck to learn about what they don’t yet know.
Much of a CS course is nice to have knowledge for many programmers, and can be plenty beneficial. But a CS degree is there to show you theory not teach you how to program - the amount of people with degrees that are very poor at even basic programming is not as low as you’d think.
I've learned over and over again that Big O is a nice theoretical model, but often doesn't translate. The famous case is std::list looking better than std::vector but almost always being worse, but I've seen plenty of others.
I work on a very large system, but spend far more time chasing down poor performance due to emergent behavior than I do worrying about Big O on some small piece.
Algorithms? yes, basic algorithms and sorting and Big O, none of which I've needed in 10 years of professional and hobby dev work. But to say "well you learned data structures and you use hashmaps and arrays so obviously it helped" is a very strange defense of academia. I can also learn "datastructures" online in a few days of studying as a new dev, so that's not really a good defense of 4 years of study.
Fortunately for all the productive engineers out there, solving leetcode reflects absolutely nothing about how much they know their fundamentals or “stuff.”
Fifteen years of industry experience and a top uni Master’s and I can assure you leetcode doesn’t predict anything reliably.
It predicts how much time they spent solving leetcode, and biases towards recent graduates. If you’re hiring senior talent it’s mostly a wash and a waste of time. But it’s deep in valley culture so we’ll likely waste our time with it for another decade or so before we wise up.
Depends a lot on the companies and positions you’re interviewing for. I work in technical security these days and did very little in the way of actual code quizzes compared to when I was a straight up software engineer.
I think it also helps to remember that interviews are two-way. If you see a company with an insane interview process, do you really have confidence in the quality of a team you’d be on when you got to the other side of it?
These days I generally look for and focus on a few things when I interview with a company I’m interested in:
1. How do they make money?
2. Do they understand how they make money? Alternatively, do they understand their market, customers, and product value?
3. How mature is management? Good managers make or break your job satisfaction and dictate how good a company is at hiring & retaining talent, as well as dealing with adversity like professional adults.
4. How much of the work I’m doing is driven by planning as opposed to circumstance. E.g. am I working off a roadmap or expecting to spend the majority of my time handing incidents and fighting fires.
Your mileage may vary, but I suspect these good or bad interview practices will only exist as long as hiring managers allow them to.
> I think it also helps to remember that interviews are two-way. If you see a company with an insane interview process, do you really have confidence in the quality of a team you’d be on when you got to the other side of it?
Exactly this. As someone who works primarily on frontend, I immediately disqualify any company whose frontend interview process for seniors+ doesn't involve actually building a frontend app/page/component/etc.
If I was ok with the prospect of working on a team with senior frontend engineers whose only competency was cramming leetcode, I might as well work at one of the tech giants.
I usually ask this question multiple ways with different wording as I go through an interview panel. They're generally along the lines of:
1. What does your roadmap look like? Do you have a roadmap?
2. How reliable is the team about hitting deadlines? Why or why not?
3. Who handles incident response? How frequently does this responsibility rotate?
4. For a given week, how much work is planned vs interrupt driven (e.g. someone needs something by the end of this week and we only learned about it days prior).
5. How much firefighting does this team do? Is this driven by the team's own work or issues in other parts of the organization?
Your mileage may vary, there are a lot of ways to get a sense of how a team/org works and what may be important to me may or may not be as important for you. Cheers!
This is really skewed to recent or new graduate and elite universities. When I was out of college, 15 years ago, some of the internships listed were hard or near impossible to get into. Take for example Goldman Sachs. They should be listing more regular internships and not those who managed to matriculate into the elite of the elite (hint: not a meritocracy). If anything it creates disillusionment that STEM careers are a straight path to being the next Bezos. It is like golfing: pick up golf to play golf not to play on the PGA tour.
This is a pretty garbage take. Goldman Sachs is easier to get into as a software engineer than any FAANG. And every FAANG I know takes the majority of their new grad hires from public universities which, at least in California, are banned from affirmative action and legacy admits. Despite the UC administration's best efforts to remove merit from the equation by not counting standardized test scores admissions into a top UC is still merit-based.
Software engineering is not investment banking or law.
this is the cancer in our industry. seems interviewing is geared towards whatever mega tech companies. yet this on hacker-news. a place filled with seed-stage companies, and early series * who probably just want someone who can get shit done.
anecdote: honestly, I have had more problems regarding visa status more than anything, in picking up jobs.
The worst interviews I’ve ever experienced, hands down, were from startups. They asked the most ridiculous whiteboard problems, and that generally just identifies the candidates who crammed most the leetcode.
The mega tech companies interviews, by comparison, were surprisingly more reasonable.
The startups have probably adopted this approach because it’s all they know, but nobody is forcing them to.
That's because startups (by no means all, but far too many) are often run by people with very little experience (technical or business) and so they cargo cult their practices from the big players. They lack the acumen to filter and fine-tune these practices to their actual needs and means.
At startups recruitment beyond getting a body in the door/Zoom is largely an afterthought.
I remember interviewing a staff researcher candidate when I was 22 at a startup (<50 employees). I was pulled away from my work the day of and thrown in a room with someone with 15 years more experience than me. I actually asked him questions that were not lawful, but I didn't know this because no one bothered giving me guidelines.
I recently interviewed for a hands-on manager position at a startup, and it went south. The recruiter set up the appointment with the VP of eng and told me what the technical topic would be. Two days before the interview the interviewer was changed to a staff engineer. I emailed the recruiter to confirm that the topic would still be the same. She said it would be. Come interview time the interviewer throws a different topic at me, for which I didn't study. I ended up with the correct answer, but it took me the full time to get there. They weren't impressed, but neither was I.
As a hiring manager I take all the these experiences and ensure that I never put a candidate in such a shitty situation.
I disagree about having an Objective Statement. I replaced mine with a Summary long ago.
Also, talking about your interests should happen during an interview or even a phone screen. You don't list "Film Noir" when applying to a flowers shop.
The typical "Looking for a challenging position juggling chainsaws in a hard-driving..." OK I exaggerate but I never liked anything along those lines. I was usually pretty fluid about what I was looking for and mostly stuck it in a cover letter or was having a conversation with someone I knew anyway.
My comment is going to come across as mostly a nit - I'm definitely the target audience here as I'm just coming off of a short break and diving into interviews. I'll update my post with more thoughts as I go through it, as I'm sure it'll be a decent resource to brush up on my DS&A.
There's kind of a focus on education here in the "skills section" that I don't find to be true after a certain level of experience.
> "Must have" — Typically, most of the must-haves include a degree (or not) in a relevant technical field, some years (or not) of experience in a particular programming language or technology
I'm not sure I agree with any of this - there are some domains like say embedded where having no C experience is an absolute must have, but to my knowledge almost nobody is thrown out of a pile for not using the specific key language a company is using, like say C# vs Java vs Cpp. Of course there's some red flags as in if you're doing modern frontend work and the resume only notes PHP4.
Also I have always treated degree requirements as optional, unless the role focuses in a specific area of research rather than general SWE. All of my positions in my career have required a degree which I don't have and I don't feel held back by it at this point. IMO at least, accomplishments > YoE > degree is much better outside of entry level.
As someone who has interviewed techs in my time, I can tell you that what the employer wants more than anything is to see YOU.
Don't treat employers like idiots. They can smell the stink of a massaged CV/Resume a mile off. They can equally tell if the person on the other side of the interview table is attempting to stick to a polished script.
The best thing you can do for yourself is be YOU. The employer wants to see the real person. The person that will be expected to work with their colleagues, customers and suppliers. They want to see the same person today that they will see a year later in the work environment, not some Jekyll & Hyde double personality.
The last thing the interviewer wants is a polished turd, i.e. someone who interviews well and then is utterly useless in the job because they are incapable of working with others or don't have the skills they promised.
The best hiring outcomes I've ever seen was a program manager who hired entirely on attitude. As long as you had programmed something/anything in the past, if you could sit through a 45 minute interview and have a great attitude you were hired. That company went from years of stagnation to doubling over the next two years.
It makes sense. If you have a great attitude about your work you'll learn and do whatever you need to.
The other key was this program manager wanted to be known as having the highest paid tech staff in the area.
Forget the Hunger Games, here is the dystopian shit right now:
For a medium level leetcode problem here is the time split (for which 20 min are given typically):
1. 4 min => Read/interpret/parse the problem statement
2. 5 min => Formulate the solution.
3. 8 min => Actual code
4. 3 min => Edge cases/review
---------------------
Notes:
* #2 You should think of various algos, DS and lock on to a particular one. If you cannot improve upon the time complexity, you need to make a split decision to either 1) continue to think more or 2) choose the next best and move to #3
* All you can do is steal one min from other phases but at the cost of less time in that phase.
* Think aloud in #2, #3 & #4
* At times even less time is available in case follow-up questions are to be accounted for.
* Code structure & consistency is important. You will be penalized if you write big monoliths.
* Additional conditions when GTFO is triggered: ["Solved the problem in 23 min instead of 20", "Did not think about that 1 scenario even though you took care of most of the important ones", "Solved the DP problem in top-down instead of bottom-up.. loser"]
----------------------
Optimizations:
* #3 should be reduced as much as possible. Choose a lang, know its standard lib by heart. This gives more time for #2
* Think of edge cases while writing code in #3
* At #2 one, you should be able to describe a solution (in your mind) detailed enough to convert into a code e.g Do DFS. Keep a max_val variable. Update max_val on values from left & right sub-tree.
* Develop intuition of doing some #2 work while in #1
-------------------------
What actually happens (or should happen) when someone practices leetcode a lot?
1. Reduce #1 time.
2. #2 => Quick recall of high level patterns already encountered
3. Able to generate multiple solutions.
4. #3 => Translate that pattern as fast as possible. E.g. There is a standard template for BFS, DFS, two pointers, etc
--------------------------
So the entire prep can be divided into two parts:
1. How soon you can zero-in a solution and convert into an outline?
2. How fast you can vomit that into a code?
Once you are comfortable in writing any code fast, you do not have to code every problem in leetcode. I see a problem and only solve it in mind and then check whether the approach was ok or not. I know I can code it fast
Edit: So for me if I have solved 200-300 LC problems, what it really means is I have actually coded in like 40-50 and remaining are just mind puzzles. If I do daily 5 mind solves, I can easily cover 200 in 40 days. I finish this daily routine in 30-45 min. (Hey .. I said this is dystopian)
------------------------
High level view:
* Practice incrementally and not in 2-3 months sprint. Think of it as daily exercise.
* This is just the way it is. May be I will do my part to change the system from inside when I am in an influential position. If you are able to find companies which do not do this shit, really good for you.
* Know that as senior dev, the margin for error is even less. So more important to practice incrementally.
--------------------------
I do not approve of this. Its bad. I am just a guy dealing with the "system".
The very first bit of advice is a cover letter? I've never seen one when interviewing, and last time I sent one was applying for an internship 18 years ago.
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.
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.
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.
> 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.
> 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.
In my experience and from what I have heard from other people, this is just how people generally are.
It seems rare that people consider things rather than regurgitating them.
As a young guy who doesn't like to cargo cult like that it's sad to hear, but on the other hand it's less competition for me. Though a lot of experienced people are also like that so...
I mean, I have 10 years of experience in the field and when someone asks me that in an interview I still go like ‘duuuh?’. They’re like asking me to package up 10 years of experience into a 3 sentence package.
How many ways are there to tell you that a caching mechanism is better for a site that barely ever changes than using database replication (yes, answering that question probably gave me some form of trauma).
I do a lot of stuff intuitively, and don’t consider the exact reasons behind them every single time.
It’s like when my maths teacher asks me to write out the steps to arrive at the solution. “But the answer is 30, right?”, “Yes, but I need to see how you arrive at that solution.”, “I look at the problem. The answer is obvious.”
Do I really need to stop and unwind the steps my mind takes to arrive there.
I’m not in school anymore, and I don’t have to graduate any more, so my patience for that kind of shit has gone down correspondingly.
I've had a very different experience. Being able to explain my thought process well is a key part of my job, whether its mentoring juniors or building consensus for larger architectural changes.
It’s really about approximating the experience as a why to a decision. Usually I try to think through questions and talk out their benefits and things start to get more “obvious” to me as I go.
Admittedly, I don’t struggle near as much in system / software design questions, it’s my “niche” (tldr thinking in systems changed my life as a teen) but data structures and algorithms still kill me, in much the same way. I have the correct intuition but can’t for the life of me correctly describe it in Big O notation and I sometimes “freeze” on questions because it’s not something I do every day and I can just well…look things up sometimes, or work through a problem iteratively until I have a solution
Here are some psychological tricks that will help you ace a job interview.
Tailor your answers to the interviewer's age.
Generation Y interviewers (between 20 and 30): Bring along visual samples of your work and highlight your ability to multitask.
Generation X interviewers (between 30 and 50): Emphasize your creativity and mention how work/life balance contributes to your success.
Baby Boomer interviewers (between 50 and 70): Show that you work hard and demonstrate respect for what they've achieved.
--
Are you kidding me? Maybe insert a joke about 'millennials' if you get interviewed by a boomer, am I right? Really tailor your material for the crowd.
One thing that always blows me away (literally) is candidates that will eat like a tunafish sandwich with onions five minutes before they come in for an interview.
If you’re going to melt my face when we are talking you should at least bring me a sandwich too. I’d hire that guy for sure. Hasn’t happened yet, but I’ll still hold out hope.
Including the number of stars on the github projects they worked on seems so.... narcissistic? Promotional? Idk but its distasteful and I would probably throw out the resume at that.
I really think all of the resume changes, other than the incoming intern at bytedance were extremely bad changes. It went from someone who is smart, with a breadth of experiences, to someone that is obsessed with social media likes.