Tech Interview Handbook
techinterviewhandbook.org
techinterviewhandbook.org
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.
The way it is phrased make it sound like he's trying to pull as fast one and make his contributions sound more significant that they where.
That being said, he would almost certainly still end up in my 'interview' pile.
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 don't know about the stars particularly, but what is a resume besides you being somewhat narcissistic and especially promotional?
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.
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)
No, it does not, unless you're a recent graduate. Absolutely nobody pays attention to your GPA, if you're more than a few years in your career.
I had plenty of interest with lots of companies, including many FAANGMGOEWVIOPJW companies.
This was years ago though.
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.
At that point that was the only thing you could possible show.
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.
But then, every organization has it's quirks.
At the end of that month, it really did feel like I was a professional interviewer.
To get a software engineering job, step 1 is to quit your software engineering job to study full time to get a job doing something very similar.
Doing your job as a software engineer is an impediment to interviewing as one.
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.
I dont know what really happened though
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).
also, the way the interviewee handles the stuff they dont know
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.
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
> Doing your job as a software engineer is an impediment to interviewing as one.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.
If anything, I guess I like the leetcode ones without an interviewer better since at least you’re judged by a completely impartial system.
Is this how Silicon Valley engineering careers work?
Software engineering is not investment banking or law.
That wasn't the case 15 years ago, as the post you're responding to stated.
The world has changed.
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.
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).
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 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.
Many of the best programmers I've worked with haven't.
Would I be a good CS researcher? No, not even close.
Am I a good software engineer? Damn straight I am.
Would I work with you? Sounds like we wouldn't be a good "culture fit."
I don't like it, but it's just the way it is now.
I imagine we operate in very different geographic regions of the USA.
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.
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.
What question(s) do you ask the companies to get information for this?
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!
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.
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.
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.
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.
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.
You have to get through the gatekeepers first...
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.
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".
Now I have a pitch style CV and have dumped the chronological for well over a decade.
However writing a guide like this you need up front to show that you have actually done a lot of recruiting.
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.
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.
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.
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...
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.
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
> Do I really need to stop and unwind the steps my mind takes to arrive there
If the other person can't tell whether you're regurgitating it or you actually know what you're talking about then yeah probably.
Hence it’s frustrating that the skills necessary for passing an interview do not align with those necessary to do the job.
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.
I bounced immediately.