https://www.pramp.com - 1 hr online interviews where you interview someone and they interview you back. Go through ~20 of these to get really comfortable solving problems while talking through them. They also give you the optimal solution at the end. This will prepare you really well for the initial technical phone screenings.
https://leetcode.com/ - collection of 700+ interview coding challenges. You should be able to solve any random medium difficulty question within 15 minutes if you want a shot at the companies you listed. Keep doing a couple of these per day till you get really good.
"Elements of Programming Interviews" or "Cracking the Coding Interview" - Read through either one of these to get an overview of the interview process and what companies expect.
Polish your resume - This is only important to get the interview. Once you are interviewing onsite the resume doesn't matter much. Here is mine to give you an example. http://joshcockrell.com/joshua_cockrell_resume.pdf Feel free to send me yours if you want some feedback.
Any specific tips on getting the most out of Leetcode?
For example. Should I do the questions on paper first, then the editor?
Should I have multiple solutions to each (n2 and nlogn) if it exists?
How do you guard against just memorizing the questions? I feel like if i can't do a problem and look at the solution, then going back to it later will be useless since I already have memorized the answer but not the methodology to solve it.
I don't think you need to worry about this. A simple search for "binary search" shows 20 different questions. If you can't do the 1st bst problem and you look at the solution then that's okay! You have 19 more to try it on. Even if you do all 20 then come back in a month and try them again. There's no way you're going to be able to memorize that many variants. And that's just 2% of their entire set of questions.
To really answer your question, I prefer to just hit the "random problem" button and see if I can solve it in 15 minutes with an optimal solution. If I struggle, then I just go read the solution (to understand how I should have solved it) and try a couple related problems to make sure I'm not just memorizing it and I actually understand the methodology behind solving it.
I went through the whole process with Google and Amazon, just to get rejected at the end. I prepared by cramming Cracking the code interview in 2 weeks and reading classic algorithms books; it wasn't enough to meet the bar (anecdotally I remember Google being much harder than Amazon).
Fast forward another couple of years and I got contacted by Microsoft and Amazon recruiters, went through and got offers from both companies. Recently I also got approached by a Google recruiter but I politely declined since I recently started a new position.
What changed in those couple of years?
This time around I prepared by solving problems in leetcode and other platforms a longer time. For about 2 months I spent almost all my free time writing code out of the office.
But that's only half of the story. I noticed that as you apply to more senior roles, the interviews focus more on behaviour and experience rather than hardcore programming. I would say that the weight of these factors was between 2x and 2.5x this time around.
Finally, I myself changed during that time. I adopted an 'abundance mindset', where opportunities are plentiful instead of single chances that we can't let get away. Now I see interviews as two way streets where companies need you as much as you need them. Lastly, when I go to an interview I don't see it as 'I practiced x days for this interview', but as 'I have 10 years professional experience, if that didn't prepared me for this job, no amount of cramming in a few days will'. That doesn't even touch the
So my advice is to just relax, do your best and don't get discourage if you are rejected. If your goal is to break in one of the big 4, continue accruing experience and improving yourself and try next time, it will just get better.
P.S.: In my comment I don't mention luck, but personally I think that it also plays a huge role in getting a job. One time recruiters from a company got in touch with me; two years later they wouldn't even read my CV for the same position. Get to the right position at the right time, and the right set of people can be the difference between an offer or none. It's hard to come to terms with the idea than something other than yourself can dictate your future, but the sooner you do it, it will save you a lot of grief.
I hope that it takes me 3~4 months to be prepared, but I guess I never plan on stopping practicing (doing LeetCode questions for example). I realize that interviewing is a skill that needs to be kept sharp throughout ones career, so even if I get rejected on the first try, I'll keep practicing and keep applying!
Thanks for the advice!
1) My current company is a startup so things can go sour rather quickly. I want to keep my interviewing skills sharp in case I need to switch jobs.
2) FAANG is great for a career advancement. I'll learn a ton working for the best tech companies in the world and working with extremely smart people. Interesting technical problems and also upwards mobility later on. Also applying to any other job after that will be much easier as smaller companies don't screen nearly as hard as the big ones for their software positions.
3) Great for networking. You meet tons of other smart people who know tons of other smart people. In the Bay Area when you say you've worked for Google doors open much easier and you gain other people's respect much faster.
4) Lastly, FAANG companies will pay more than what I'm currently making.
I've heard a lot of success with this method:
1. Start with https://www.firecode.io/ - it's a gentler intro than most of these resources.
2. Once you can manage FireCode, move onto LeetCode as others have suggested. More specifically, the ones that have been flagged as interview problems. If you can get through the Hard ones in 30-45 min, you're good.
3. Once you feel confident in steps 1 and 2, use https://interviewing.io to take a bunch of mock interviews. The interviewers are generally from these companies, so if you do well, you'll automatically skip the phone interview and land right in the main interview space. And if you don't, no worries, you're getting practice in an interview setting, and not just in answering problems.
3b. As a supplement to #3, Google and Facebook actually hold info sessions on their interview process. My friends used those and landed at both places, respectively. They both said the info sessions were pivotal for them.
The average time my friends spent on this process was roughly 90 hours total. So if you worked on this full time for 2+ weeks, you should be prepared, or 2-3 months if you did a little bit every night while working your current job.
Best of luck!
That seems much shorter than I had expected, considering there's so many questions on Leetcode. Do you recommend focussing only on the marked interview questions on LeetCode or start at the beginning and work my way up to the hardest?
It's all about practice! Good luck!
Also, if you can get in touch with a recruiter at those companies, they'll give you tons of helpful tips (mostly just how to practice and what to practice)
I've heard really good things about CTCI so I'll pick that up. Having a Github checklist and a study plan would be super useful (I'm sure there's other people asking this question). I wonder if something like this exists already?
To get my first job as a software dev, I prepared by doing algorithms (using cracking the coding interview book). You really don't need any other resource, I did every the problem in the book at least 5 times. The most important lesson I learned here is to constantly redo problems you struggle with until you know it like the back of your hands.
In my first job I realized that I like building tools that people use so I focused on learning front end development.
I recently interviewed for front-end roles and I've noticed a shift from algorithms to practical tasks (building x app). Out of the 9 onsites I did, I don't remember doing any complex algorithms, but instead there were alot of hands-on coding to make sure I can code up challenges on the spot. For front end engineers, I think algorithms is no longer a point of focus. I don't think there are any practice resources that focuses on front end development, but my friend is building https://jsstation.com to address this.
Dropbox, Amazon, Facebook offered separate interview tracks for front-end development and generic software engineering.
I ended up receiving a few offers and I was quite surprised by the numbers. The top 3 are all between 250k - 310k total compensation packages, the lowest base among them was 180k and the highest base was 210k. I'm quite surprised at the big difference between what Glassdoor shows and what my friends and I are making, perhaps someone here could shed some light.
I think you graduated 4 years after me, I hope you find some value here. Good Luck!
I met Parker at MicroConf a couple years ago and was really impressed with Interview Cake.
I can't speak firsthand but it might be exactly what you're looking for...
Interview Cake should be your first stop - the questions are the closest to what you'll actually see in a tech giant interview, so the effort to reward ratio is good.
LeetCode is your bread and butter. With any remaining time, grind these problems.
Cracking the Coding Interview is both too easy and too difficult, very few questions hit the sweet spot. Read the section on behavioral questions though. Elements of Programming Interviews is too challenging, I'd skip it.
Optimize for number of problems solved, which means coding in the site's online text editor. I wouldn't code in your own personal text editor because you do want to avoid autocomplete. If you feel like you need practice actually writing on a whiteboard, you can do that a few days before the onsite.
Aside from this, getting accepted is merely about convincing your interviewers that you have what they're looking for. Build a rapport, be confident, don't be nervous, be funny if possible, but don't come off as arrogant or annoying. Most companies prefer experience over technical mastery, so don't focus on explaining technical details - though obviously you should fully explain it when they do get technical. Answers you give should touch on every topic that the subject would typically involve, with as little detail as possible, and if they ask more specific questions, dive into it. You have to show a broad understanding as well as minute attention to detail. While not being too serious. Don't voice any negative opinions, nor any preferences.
Obviously ambition is important to you, so definitely get some books on management and business so you can rise up in the ranks quicker. Being able to speak to the business side will endear you to managers and executives, and if you can impress them in an interview you're basically a shoe-in, because politics. Yay for big companies.
Big companies generally think all they need to do is follow trends in order to lower costs and increase productivity, so study up on every modern trend that tech companies latch on to. Big data/machine learning/automation have been in vogue for a while, as is obviously agile methods, devops processes, product lifecycles, etc.
At the end of all this you may realize, hey, this sounds like I have to support ideas or practices that I don't agree with. And that's because you're trying to work for a company, rather than trying to work for yourself. Eventually you may realize you'll be a lot happier not trying to get hired by a specific company, and simply try to be hired by the people who value who you are, rather than who they want you to be.
Google has also created some interview videos you can pick up on YouTube. They are (obviously) staged, but are quite interesting and informative.
Way more useful than other theoretical classes that were required but only probably needed in grad school.
Software engineers (myself included) have this deep resentment for technical interviews, but they are part of a software developer life and the more comfortable we get doing them, the better off we are in long term!
From my point of view University should be entirely about learning academic material for the sake of self improvement. To become a more enlightened and educated individual.
Having a "Technical Interview" course isn't about furthering student's knowledge, but about furthering student's future finical gains. I believe strongly that any improvement of a student's position in the labor market should be a secondary effect, and not a primary concern, of a University.
I think that if Universities start competing on student's success in the labor market post graduation then the centuries long tradition of improving student's knowledge will suffer.
Colleges very much care how well their graduates do in the workforce, as it’s a key way they’re measured. It’s a tough balance to mix mind-expanding academia and direct preparedness though.
1) Select a category such as "stacks and queues" from the Cracking coding interview (CCI) book and read all the questions. This will give you a sense of the type of questions being asked.
2) Sign up for the algorithms 1 and 2 courses (https://www.coursera.org/learn/algorithms-part1, https://www.coursera.org/learn/algorithms-part2) in the audit mode(free). Pick the correct modules such as "stacks" and "queues" and watch all the videos.
3) Come back to the questions in the book CCI and try to solve the problems yourself. If you get stuck, look at the solutions for hints but still try to do them yourself.
4) Do the same for all major topics such as strings, linked lists, recursion etc.
Unfortunately, you are not going to remember all of you've learned. You need spaced-repetition so repeat the above method 2-3 times for each topic.
Once you have the foundation, you will be able to tackle the harder questions that you may find somewhere else or in the interview.
• I was reached out to, rather than applying for a job. In the past I'd tried applying for jobs at some of the companies but didn't hear back - so I focused on going as far as I can without a job somewhere like this. Start a blog, create some great side projects that receive some attention, etc - eventually companies might start approaching you (and even if not, your resume will look more appealing, and you've grown/learnt a lot which is helpful for any job you're in).
• There's a lot of resources out there on interview type programming questions. Yeah, they're helpful, and you should do them - even if just to learn more and become a better developer. There's much more to the interviews than a binary yes/no whether you solved the question or not though: being able to share your thought process, quick thinking, showing creativity and good intuition etc are all just as important.
• Experience, great social skills, and in depth knowledge is worth more than a few days cramming for a coding interview. It shows during the interview process (especially architecture or cultural interviews). I think interviewers are looking for those things as much as they're looking for someone that's smart and can solve a few tough questions on the spot.
Summing that up - focus on being a better developer, learning more, and becoming an expert at what you do. Don't make your end goal a job at one of those companies. If you don't get a job at one straight a way, it's no big deal - who knows, in a few years you might, and if you didn't, you learnt a lot which will help you anywhere you are.
This is one of the drawbacks; No, it does not. The judge has a timer so you have to write code that is reasonable in runtime and space, but nothing telling you if the answer is the most optimal one possible.
IMO, the ideal way to use it is to get a subscription, and then use the best feature: sort by company. At first glance, you'll notice that facebook asks very different problems than google. Once you select a problem, try solving it, and then make sure you click through to the forums and read the highly voted discussions. In many cases, I didn't find a more optimal solution, but picked up a lot of python tricks that made the solution elegant, etc.
Although you hear of Google hiring thousands of developers a year, and those that do get hired having a 5% chance of success or whatever, that doesn't mean that Google are guaranteed to offer you an interview. I've applied a handful of times, and despite having a Computer Science degree, startup, and small/large agency experience I've never managed to get past the application stage at Google or Microsoft. Microsoft and Amazon contacted me in the past, but neither actually resulted in an interview. Google rejected me within days of applying on both occasions I applied.
With that in mind I would recommend that you follow a loose curriculum, and just focus on becoming the best developer you can be. I'm currently working through John Washam's repo on getting a job at one of the big four, and it was good enough to get him through the door at Amazon.
In general I think it's a good idea to rethink what your aims as a developer are every now and then, regardless of what company you want to work for. Recently, I was a senior .NET developer at a large agency working for big-name clients, but I often felt like I wasn't a "proper developer" because I worked on the .NET stack, and because for the past few years I've felt complacent in a senior-level role. To combat this, I started learning some new languages on the side, and eventually moved to a new job where I've switched from being the go-to guy for .NET to the goes-to guy for working on a Linux stack, and I hope that over the next few years I'll pick up enough knowledge that I can throw an application in again and not get immediately rejected.
My only gripe with C# and .NET is that it's tied to Windows, a fact that immediately locks you down to a single tech stack. Sure, you could write any mainstream language on Windows, but no one does because the language and frameworks aren't optimised for Windows. You're writing code as good as what's written by others on the Linux stack, and your development environment is largely as good as what everyone else is using, but you feel isolated.
For me, it's this perception that leads people to think less of .NET at a platform. You're the guy that drove a Ford to a Volkswagen convention, and even though your car is as good (and in some ways better) than what everyone else has, you'll still feel like an imposter.
I guess my other question would be how did you end up at your latest job?
I always find that - for non .NET jobs they are mostly looking for Sr. level folks for jobs. Any advice on transitioning?
1. Push the salary limits where you can, but accept a full-time role with limited progression, limited pay, but less stress.
2. Be a lead developer, and ultimately move away from code and into management.
3. Go contracting, because you'll earn 2x what you earn as a salaried employee.
Having been on the other side and having to look for a senior-level candidate to join a team, I'd say that you could probably still send a speculative application, and essentially explain that while you're not the finished article they're looking for, you're interested in the company and you're actively looking to learn. For my interviews, I essentially went in with full honesty. I said that my main experience is C#, but that I'm looking to move away from web development on the Windows stack and am looking to give something new a try to build my skills as a developer. Some companies will appreciate your honesty, and some won't, but I'd argue that the companies that are merely looking to fill a defined role won't offer you the progression you're after anyway.
It's still early days where I am at the moment, and there's every chance that things might not work out, but so far I've been enjoying being the newbie again. For me, it's been less about moving to a new stack, and more about getting over that imposter syndrome of being a one-stack man. If it all goes to shit, and I get made redundant/sacked, at the very least I can go back to my old stack, and that alone takes a good bit of stress off of me.
Cracking the Coding Interview: 189 Programming Questions and Solutions
The actual questions I got at the interview were nothing like what was in the book. They weren't questions like "how does algorithm X work?" but "how would you model/implement as system that does X?".
So, shrug. My one data point says that this book is a mostly useless distraction.
Besides the coding part you should also think about your non-coding interviews. There will be interviews where you'll be asked about troubleshooting and technology in general. I don't have a good source for that but you should think about that side that is just as important as your coding interviews.
Yes, it's annoying, especially for old timers like me that really know their tools.