https://www.amazon.com/Cracking-Coding-Interview-Programming...
Two years ago, I ran out of money. So, I started interviewing. One example was interviewing for the Apple Watch team. My experience included the design and code lead of an Apple Watch product, which was featured by Apple. But, I failed the Coderpad. Why? The interviewer wanted me to use a new Swift generic syntax, which I had never seen before. With an unfamiliar code editor. In under 10 minutes. Did it matter that I had an Apple Watch product, which he could download from the AppStore and ran super fast on a Series 0? Nope. Did it matter that he could download a 29K Swift based functional ontology that I wrote? Nope.
The point is that there are two skills: writing code and getting past the interview. The latter is often conducted by a 20-something, just out of college. So, there is more emphasis on tacit knowledge of the tools and techniques. It feels more like passing a finals exam.
A few years ago my CEO hired Gayle Laakman to prep the team for an acquisition by a FAANG. I loved the puzzles and read her book [1] cover to cover. But, I hated the premise of avoiding "false positives". A famous false negative is Max Howell [2] (who went on to write Apple's Swift Package Manager)
So, how did I get a gig? I kept trying. Learned new frameworks. Focused on jobs interviews which had a take home. During the on-site, I insisted on using my own laptop. An often overlooked factor in achieving a coding flow-state is muscle memory.
I've been told that some companies are shifting from whiteboard to take-home -- particularly during covid. Post covid, if the option is available to you, try moving to the Bay Area or Austin and attend every single hackathon that looks interesting. If you don't want to leave HI, maybe contribute to an open source project in some way.
Or perhaps, start a company. Maybe there's an opportunity in refactoring Aerospace code? I dunno. Now, I'm guessing ...
[1] https://www.amazon.com/Cracking-Coding-Interview-Programming...
And as cliched as it sounds, as a fairly targeted, short-term thing, you might consider jumping on leetcode and grind through some of the exercises there. How useful that would be depends a lot on the nature of the company(s) you wind up interviewing with, of course. Some companies are really big on these kinds of exercises, others less so.
Also, depending on what language(s) you currently know and work with, you might find value in spending some time learning another "trendy" language. Given the next 3 months to work on it, you could probably make real progress on learning a given language to a usable level. For example, if you don't use Go today, maybe spend some time learning it, since it's very popular and seen as "modern" and "trendy".
Or if not a whole new language, maybe just a "trendy" library/framework (for example, React if you're a Javascript person, but don't currently do React).
(Note: Go and React are just examples I picked to make a point. Please don't take this as saying specifically "learn Go" or "learn React".)
[1]: https://www.amazon.com/Cracking-Coding-Interview-Programming...
I think you're overstating the time needed. Passing those interviews for someone who reads HN is basically just reading Cracking the Coding Interview [1] or Programming Interviews Exposed [2] and doing the ~50% of the exercises.
Source: Worked at 2 of FAAMG and got rejected from 2 of them (because I forgot to read those book before the interview)
If your are familiar with PHP, you can checkout my library based on CTCI: https://github.com/doganoo/PHPAlgorithms
[1]: https://www.amazon.com/Cracking-Coding-Interview-Programming...
[2]: https://www.amazon.com/Algorithms-Parts-1-4-Fundamentals-Str...
[3]: https://www.amazon.com/Algorithms-Part-Graph-3rd-Pt-5/dp/020...
[4]: https://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena...
Triplebyte (https://triplebyte.com/iv/afyYdFu/cp , referral link), if you can make it to their final video interview, will also give you full feedback whether or not you pass, for free. They don't do whiteboarding but they do live coding and debugging.
There are a few general tips though... the biggest of which is to talk out loud. They're not necessarily wanting a full solution to the problem (although it helps); the interviewer wants to know how you think, whether or not you can code decently, and if you test. (You prove the last part by running an example through your code while talking about it to find and fix any bugs.)
Check out Cracking the Coding Interview (https://www.amazon.com/Cracking-Coding-Interview-Programming...) for more of this. It's a very good book. Pairing its problems with an actual whiteboard and a timer is a close approximation to a real interview.
1. Algorithm and data structures trivia: which includes the classic CtCI [1],
2. In-house problems: where you have to analyze and propose multiple solutions to a problem that has been faced by the current development team in the company that is executing the interview,
3. Homework-like projects: which usually take 3-7 days to finish.
After an exhausting 2016 full of interviews I do not know which one is worse.
On one hand, having a common set of problems like the ones proposed in CtCI is good because you just prepare once (kind of) and can apply to multiple companies at the same time. On the other hand, in-house problems are good if you really want to work for a specific company and want to know what are the problems that your future co-workers are facing, the problem is that you have to be well versed in a wide range of concepts to give at least one answer that pleases the lead developer. And finally, the take-home projects, I think they are the worse in comparison, you are expected to work for free for at least one day in a problem that is either very basic or too complicated but they always expect you to have a perfect solution just by yourself. How many times have you done this in your own job? Do you start working in a solution to a problem without asking questions? Without a discussion with your colleagues? Without full specifications? Without multiple attempts? Take-home projects are really not suitable for an interview.
I understand the point of these tweets but I doubt they will change anything. Much of the craziness of nowadays interviews comes from the recruiters who have no idea about these problems, they don't know algorithms and/or data structures, they don't know what are the problems that the company is facing, they only care about the money that the company will give them if the candidate is hired. Now you know why websites like Hackerrank [2] are so popular, recruiters love to have a standard set of questions and if your answer is not the exact same that is in their sheets you lose.
From now on I will just resort to colleague's referral. With this I know that at least one member of the team will vouch for me to join the company and make the interview process as painless as possible because they already have an idea of how good of an engineer I am.
PS: Just to clarify, I haven't been hired by any of the "Big 4" yet, but that is because — again — I have been studying for only two weeks, if I invest more time on this, maybe in 5-6 months I can guarantee an offer in one of those popular companies that appear featured on HN all the time. And as the parent comment says, even if you have no intention to work for Google or any other of the big corporations, this still is a good list of resources to improve your skillset.
[1] https://en.wikipedia.org/wiki/Applicant_tracking_system
A couple that come to mind are Project Euler [1] and CodeKata [2].
The problem with most courses is that they teach the very basic types of data structures, a couple search algorithms, etc but not enough. They didn't give me the intuition I was looking for.
Alternatively, the most recommended books I've seen for your use case are _Programming Interviews Exposed_ (PIE) [3] and _Cracking the Coding Interview_ [4].
[1]: https://projecteuler.net/
[2]: http://codekata.com/
[3]: https://www.amazon.com/Programming-Interviews-Exposed-Secret...
[4]: https://www.amazon.com/Cracking-Coding-Interview-Programming...
I've seen tens if not more people from my unknown middle EU university nail the interviews, ending up with jobs at Google, Facebook, Microsoft etc. and I've cooperated with some of them, knowing that their programming skills and knowledge, teamwork are lacking. But they can solve some simple dynamic programming problems, or maybe a silly breadth-first-search, and they'll get the job.
I, personally, wouldn't like to be hired at a firm that evaluates me that ridiculously. Yes, I'm a fresh graduate but thinking that knowing Dijkstra's algorithm evaluates my abilities makes me believe the whole culture is entirely deformed and I do not want to be fascinated by these ridiculous puzzles when I'm working with others.
Give them a week to implement something of larger complexity and they are drowned by so many concepts they decided to skip to earn an internship/full-time position at their beloved giants.
But I guess giants can afford having engineers that aren't that productive, or aren't doing projects that matter. I wouldn't like to be one of these engineers.
So, the real question is do you want that, or is the cash blinding you? :D
Books like these below can increase your chances significantly:
http://www.amazon.com/Elements-Programming-Interviews-Inside...
http://www.amazon.com/Competitive-Programming-3rd-Steven-Hal...
http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/...
It's got plenty of practice questions, plus great guides on the type of questions interviewers ask and the answers that they're looking for.
[1] https://www.amazon.com/Cracking-Coding-Interview-Programming...