Regardless. I refreshed all that and more. But still there always seems to be a guy somewhere in this long way that will throw the odd question (open 'the Linux programmer interface' at a random page and shoot). I mean it is very easy to find a quirky question to ask and then use my flawed or 'I don't remember this off hand (but I can damn sure find it and understand it in 5 mins if you let me) to throw me out of the window.
I've seen the same play at least 6 times (wannabe startups emulate this hiring process - if google does it then it must be correct).
OTOH dunno - perhaps I just don't cut it. Perhaps the competition has been turbocharging while I was working. Dunno.
Because they matter. Basic level complexities, algorithms, data structures, are all important for being a developer. That's why it's part of the undergraduate curriculum! You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do.
> open 'the Linux programmer interface' at a random page and shoot
Yeah, the heck with that interviewer. I mean, if you're interviewing for a low level systems dev job then I can see making sure the dev has some basic familiarity with important functions, but it's hard to see that making sense on a general developer interview. I hope that wasn't my company.
That one time a year when it's critical, I would want someone who is likely to engage on the rest of the team to come up with a solid solution together and spend at least a day thinking about it.
This isn't how interviews work so if you think you're selecting for that one time a year when its critical at the expense of the rest of the year, I don't think you're getting what you think you are.
For quick workarounds to deal with a critical error while allowing time to solve it properly, I think an experienced person may have an edge.
It's not about "Can the candidate solve this mission critical problem we'll spend a week on, in an hour?". It's more like "Can the candidate recognize a graph problem?". If they can't even tell that this is a graph problem, how are they going to know that today is the day we need to ask someone for help, and think about this very hard?
An example: Many times I've asked something like Word Ladder[0] to a candidate, and they can't tell that this is a shortest path problem, nor use the common tools to solve such things. Even with hinting and helping as much as I can, sometimes they just don't have those tools in their toolbox. And my job is to find out whether they do or not.
[0]https://leetcode.com/problems/word-ladder/ and no, I don't use this exact question.
I downvoted you because it's unreasonable to expect people to memorize something they use once a year. Learn it, understand it, then look it up again when you need it.
Interviews should reflect the experience and knowledge you expect a candidate to use on a regular basis. Asking comp sci questions they don't need to know to do their job biases your hiring process to new grads rather than experienced industry veterans.
SRE btw has come to mean "you must know everything...in order to do on-calls" but that deserves a whole post in itself.
---
I'm OK with complexities, etc. I get why they're so popular in interviews. I don't agree but I get it. They were an annoyance to review and keep in my RAM since I don't really use them in day-to-day work but I swallowed that pill.
"I'm a really good developer, shipped software, why do I need to know how to invert a binary tree on a whiteboard?"
Well, first of all, it's all out there, and you have all the time in the world to prepare. Know how to invert a binary tree.
Aside from that, the things you actually need to know for these interviews (from my experience interviewing at several FAANGs) are basic dynamic programming, BFS, DFS, and basic tree algorithms. Nobody's going to ask you to implement Edmonds-Karp from memory. This is something a smart non-academic who learned ReactJS should be able to easily learn.
Theory matters. If you care about theory, and applying theory to problems you face, you care about making your abstractions correct, which leads to code that has fewer edge cases and is more maintainable.
I downvoted you because this is terrible reasoning. If you don't use knowledge on a regular basis you have no reason to remember it, and won't.
Interviews shouldn't require studying. They should test the knowledge you're expected to use on the job.
I don't spend hours every week studying comp sci in the off chance I might need it at work. If I need to do something I don't remember or never learned I look it up.
Theory matters if you're deeply involved in complex comp sci problems. If you're building simple web and mobile apps like 90% of programmers theory is irrelevant.
Again, ask interview questions directly relevant to the position.
Precisely this. That's one of the key things from our "experience" and "seniority". We've seen things, we know how to be pragmatic and learn/relearn X to finish Y and deliver value.
I'm yet to see an interview that covers this. I'm clinging to my current job because I'm not sure I can face the job market in my current age.
Other than basic filtering questions so I can see if someone is trying to fake their way through an interview, I never ask functional specifics. Even then it's usually just to make sure they at least basically know everything they claim to on their resume - if you don't claim to know JS, I'm not going to ask you about what bind() does, but if you rate yourself a 10/10 JS expert, you should probably have a good answer.
Interviews should be about your thought process and how well you can solve real world problems, not trivia about how well you've memorized an API. I don't understand why so many other interviewers (Even at companies I've worked for) ask coding "gotchas" and reject candidates because they don't remember the semantics of some obscure language feature.
Yet, if the string of interviews is too long (and it is) the probability of hitting a "reef" is really big. And it seems that either you get a unanimous "yes" or you fail.
1) Utilize leverage and numbers. Reputable 1st party company recruiters as well as hiring marketplaces like Hired[1], and TripleByte[2] and AngelList[3] could become trusty tools for you. It'll be hard to get in front of recruiters at BigCos there, so you'll also want to make sure your LinkedIn[4] is up to date. Get a premium account and actively get in touch with BigCo recruiters. Connect with them and see how many are willing to have an unstructured conversation with you about your location in your career, your goals, and the possibility of working at BigCo. I know recruiters get a bad rap, but the competent ones are worth their weight in gold and most importantly are paid to put you into the process. You want to get in front of as many companies as possible. There is very likely an upper limit on the amount of "nos" you'll have to hear before you get at least one yes. But, it takes a lot of time and energy to go through the ringer with more companies, even if it does work to your advantage. The most recent time I went through the process, there were a good 50 companies I had initial conversations with, maybe 20 were I got to the phone screen stage, 5 that I got to on-site and 2 offers. And, this time was easier than last time, which was even worse. The drop-off there was brutal, and I knew that for any given company, there was probably a 96% chance I was spending my time on something that ultimately wouldn't pan out. But I was also honing my interviewing technique and "was going to miss the shots I didn't take". Keep at it. Even with a 96% failure rate, after 50 shots, there's only a 12% chance that you don't get at least 1 offer.
2) BigCo FAANG recruiting processes reflect BigCo processes in general in that they're meant to minimize false positives, not false negatives. The upshot of this for you is that there can be a lot of luck involved with your interview. But another upshot if this is that your interview is so structured and well known that it is very doable to prepare directly for the interview -- even if you're preparing[5][6] in a way that is a little synthetic and doesn't really reflect your job experience. Try doing a mock interview with someone who works at a FAANG that covers an algorithm section and a system design section. See how well you genuinely do. Every time I'm back on the market interviewing, I'm surprised at how hard this stuff is and how much I need to ramp up my interviewing skills again. I don't expect that to ever change.
2) It's normal to have interviews completely tank because of bad luck. Sometimes this can happen across every BigCo you apply to. It happens. It took several years and stages of being on the market for me to finally end up at one after wanting to be there for a while. Don't give up.
3) Behavioral interview performance becomes increasingly important. One technique I used was to put all of my major projects I did on a spreadsheet, left to right over time, and then figure out the company values and add snippets top to bottom for the relevant projects about the ways that project reflected a specific company value. This sounds corny and artificial, but it made it much easier for me to give prepared, pointed, real examples of my proven ability to add value to the company.
4) Startup interviews are more freeform than big company interviews for better and worse. At worst, you'll have the worst part of BigCo interviews with none of the competence. At best, you'll have a process that feels thoroughly modernized and personalized -- you'll probably work through some kind of a problem or collaborative design exercise together with one of the few engineers at the company (or the CTO), and based on how well you gel, you get hired. You'll be as much interviewing them for whether you want to work with them as vice versa. Or, you'll be hired to consult and if that goes well they'll want to bring you on full time. These kinds of gigs can be great because you are likely to be the most quality, experienced talent that they can get access to by a long shot, and the door is open for you to take a leadership role here. From that role, the door is open for you to take on a leadership role at a BigCo if that's what you want long term. BigCos love hiring talent that has been proven by the crucible of success at startups that they otherwise would have passed on when that talent wasn't necessarily "proven" to that level yet. You can probably guess why.
5) Consulting is a great play for those who are very experienced. You can sell your experience and not your fungible labor. But it does take the development of sales and positioning skills. I've never had success here but I've seen friends who have. My take? The pattern I see with friends who are successful on this route is they don't do it alone. They take on opportunities with other folks they've worked well with in the past. Companies love this because they thoroughly cut out an organizational integration risk, which is of putting together two otherwise productive individuals that clash destructively rather than coordinate.
Let me be the first to say please don't undersell yourself. Having been a hiring manager at a seed stage startup before my current role, I absolutely would have jumped on any candidates that fit your profile. In fact, I tried to, multiple times, and saw my firm passed over for a competing offer from another firm.
Ref this classic: https://training.kalzumeus.com/newsletters/archive/consultin...
