On the other hand, someone willing to 'work' unpaid overtime and jump through unreasonable hoops to just get a job is more likely to continue doing the same once they get the job.
This is a after-it-therefore-because-of-it argument/survivorship bias.
Inversely, not knowing the technical questions doesn't mean that alone is the reason the interview "failed". /r/cscareerquestions had good discussion yesterday about the realities of interviewing: https://www.reddit.com/r/cscareerquestions/comments/68czkl/w...
Sure, but just as these big tech companies have processes that's optimize for removing false positives, candidates end up having to study for interviews to optimize for being excluded as such.
I agree that there are many reasons why someone can "fail" a technical interview (I wrote about some of them here[0]). It's just as important "how" you solve the problem and that you come off as someone people will want to work with.
Neither of which can be solved by 'studying' for an interview. I'll argue that the required skills are on the interviewer, not the interviewee. As an interviewer I'm trying to assess a skillset, be it social, be it technical. All the points you listed (except #5) I deem to be a failure on the part of the interviewer:
1. You didn't make enough progress on the problem.
The interviewer didn't properly explain the scope of the problem.
2. You were too slow and didn't get through all of the problems.
Again, a scoping issue on the interviewer's part. When I interview, I have one _single_ problem that I pose. I interview largely for embedded security folks, so I write this on the board:
And I will ask them to explain what's wrong with it. Most people can answer that question fairly easily. With this simple problem on the table I now have a base to start more questions from:
- How would you fix this problem?
- In a large codebase, how would you find this problem?
- What's really happening here on a machine level?
- What sort of system-level mitigations can I implement?
These are all branches I can take, and once I feel like the interviewee is out of his depth in any one of them I jump back up. I'm trying to assess the skill-level of the person, not whether they meet some minimum bar (though I can do this afterwards, of course).
3. Your solution is complicated.
There's a little bit of shared blame here. The playing-field isn't level in an interview as the interviewee is naturally going to be nervous. You as an interviewer can help level it a little by giving some broad strokes help. "That solution looks like it might end up a little complicated. Do you think there's a better one?". I have given no technical guidance, but have given the interviewee a chance to step back and think.
4. You didn't communicate well enough with the interviewer
Everyone works differently. When I'm solving a problem, I like being alone in my head to focus. Some people more naturally are drawn towards collaborative problem solving. An interviewer that doesn't recognize this is a poor interviewer.
You as the interviewer can solve the problem by occasionally asking "So, what direction are you thinking?" or "Can you write me out on the whiteboard where you're going?".
There is a wide disparity between "embedded" type software dev interviews and "crud" type software interviews. Amazon, Google, FB are CRUD type. Their interviews are exclusively Algos and data struct memorization and slapping perfect code on the whiteboard in 20 mins.
I'll be honest with you, I've conducted some attrocious interviews. It's taken me a long time, and a LOT of interviews, to get to the point where I feel like I'm not horribly butchering them most of the time.
I found that I really like the "pick one problem/question and go deep and/or wide" approach. The above example I can go anywhere from compilers (Q: "What's the smallest function a compiler could legally output given this code?" (I love this one :P)) to C (Q: "How is 'buf' allocated?") to static analysis (Q: "How would I statically find all instances of this pattern?") to exploits (Q: "How would I exploit this vulnerability?") to mitigations (Q: "Given a stack overflow, what can I do to make it harder to exploit for the attacker?"), etc. etc. etc.
That still leaves more than a few decades worth of an active programming lifespan out. Assuming you're in your early 20's, your parents are likely in their early 40's; retirement age is still in the late 60's.
It's a young field, there will be more and more people who code into their 70's and 80's as the first batch of gen-X matures.
For whatever it's worth, I appreciated his use of English. In this case I don't think I would have had trouble parsing 'post hoc ergo propter hoc', but about half the time when someone uses the Latin phrase for a logical fallacy (or other concept) I have to look it up to make sure I haven't misremembered its meaning. Trivial inconvenience, sure, but multiply that by everyone else in the same boat and surely it outweighs the extra effort/space taken to type out a slightly longer, easily understandable English version.
"I got a tech job after doing these things, therefore these things helped me get the tech job."
There is a lot more nuance to tech job interviewing (including luck that you got a good interviewer/interviewer was not in a bad mood), despite the changing landscape which emphasizes trick coding.
As a counter anecdote, I had someone tell me they did an interview loop where the guy interviewing had social anxiety problems so he would talk to a hand puppet instead of the interviewer. He got all the technical questions correct and was hired, apparently, so there's that.
Interesting. I dropped out of a CS degree so I thought the theoretical knowledge was preventing me from getting jobs. If a Stanford Grad has trouble with interviews it seems that CTCI and tools like Leetcode are the way to go.
I know two people that didn't finish their degrees (not even in CS!) and had offers from Google, FB, Airbnb, Square... all from being really good at technical interviews. It happens.
And this is how another smart person dedicated their life to solving puzzles, just so that they could get a job on an obscure feature in a giant company.
You have a pretty naive view of what a Stanford grad has available to him/her outside of grunt tech jobs. This Amazon job sucks by most measures. The next job that this candidate looks for will suck even more because this candidate will have to memorize and regurgitate the same crap again.
This candidate is probably going to frustrate themselves to death. Tech industry is not at all great for engineers these days.
> Tech industry is not at all great for engineers these days.
Plenty of jobs outside the 'Tech' industry bringing stuff into other companies, it's not as 'glamorous' but it pays the bills and you get through the door a lot easier.
I'm from the UK and consciously stay out of the local start up scene because I think the culture was/is toxic and have for a long time but there are solid and interesting programming jobs out in the wider world.
Americans are particularly suckers to money. It's cultural. For a lot of folks here, life is about that rat race. Said companies capitalize on that.
It's the same in India and China as well. Too much competition for fewer and fewer resources, chasing money is the norm...until suddenly they're in a hospital death bed, trying to get out of medical debt.
"For example, I would stumble on simple questions like generating all permutations of a set by writing a recursive program that wouldn’t even terminate (even though it was something you would learn how to code by the second intro to CS class)."
Does that mean second course, or second class? Because second class would be pretty intense. Although second course is pretty intense too.
Puzzle based interviewing isn't that common. The only places that do that are out of touch. Most technical interview questions for in person interviews are word problems in the form of a requirement.
It's because they're not programming tests, but IQ tests with CS concepts as their medium. They want smart people so they test for it the best way they can (i.e. in ways that won't run afoul of employment laws).
I think its reasonable for the likes of google and facebook to consider the most important trait of their hires to be their intelligence. Even if most people at these companies are really just CRUD developers, you never know who the next big idea will come from. Consider how many products came out of google that were side projects of one of their engineers. Hiring smart people is an investment in these companies' future.
The problem is when the random nothing-but-CRUD companies/startups think they need google-caliber engineers.
I totally agree. I'm interviewing someone tomorrow morning, and I plan to give them a simple finite state machine problem in C. Full open book (i.e. access to the web), and they're free to compile and run as many times as they want. You’d be surprised how many candidates can't implement something as simple as fizzbuzz.
The Big N companies have way more applicants than jobs; By my count these companies employ only about 2-3% of developers in the US, and a big chunk of those come from overseas.
So, to the extent that smart people want to work with other smart people, rather than just anyone who can get the job done, they introduce a completely arbitrary bar that is hard to clear in addition to all the normal job requirements. This leads to lots of people being overqualified for their jobs.
I have no explanation for smaller companies doing this, except to ape the big guys.
They are puzzles, if some spent many years coming up with solutions for them. Surely if you know the solution for the puzzle, it's easy. But if you don't - you won't be able to solve it in reasonable time. So what is the point of the interview? To know if you memorized tons of puzzles in advance?
"A. On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart."
I don't study for interviews any more. I figure as I continuously improve my Computer Science and Mathematics fundamentals it will just happen naturally. So yeah I've been to final at Google, Amazon, and now Facebook, but I probably won't get a job offer for another year or so. Their loss though :)
I've never studied for an interview but I don't see any correlation between being able to smash the technical tests and getting hired.
In fact I think that often scoring 100% on the technical has hurt me because they believed my ability outscopes the role they're hiring for. (though they won't hire me for a senior role because I'm too young, eurgh.)
EDIT: In fact I think the best correlated factor has been applying for jobs where I'm apparently not qualified enough, the companies that decide to interview me anyway are:
Serious Advice: Remove the graduation date from your resume. Most companies at an institutional level don't care when you got your degree so long as you have one. Specific people might care if it comes up but not enough to make a point of it. They're generally perfectly happy to hire you based on your interview performance.
Source: Have been involved in hiring at giant software corp
It appears the OP describes his experience as a college student (presumably full time) at Stanford. As someone with a bit more atypical college background, who now works, the idea of devoting so much of my free time to studying boggles my mind. Programming 9-5 everyday makes me much less likely to want to do any coding when I get home.
And it really sucks that being a full time programmer isn't remotely sufficient experience for any kind of technical job interview. I'd be laughed out of the office if I suggested we write BST algorithms on whiteboards.
This doesn't even get into the fact that exceedingly few programming jobs need to know anything resembling advanced computer science theory. Probably less than 5% in my limited experience.
I do believe we need a better system for interviewing candidates.
However, I strongly disagree with your statement!
I work on distributed systems day in and day out, and more and more I find that I'm using or building distributed data structures analogous to BST, HashTable, etc.
Not knowing the foundations of my field in and out would be a mistake!
How many programmers work for Facebook, Google, Amazon, etc and how many work for non-web scale companies? As a professional programmer in financial services I have never had to use a red-black tree, min heap or do anything more advanced than properly using a HashTable.
Ok, I'll try and use an example from financial services:
Disclaimer: Never worked in financial tech, I have thought about this problem for 5 mins. This is unlikely to be an optimal solution to keeping a sorted set of distributed data. I'm just trying to show how basic knowledge of data structures helps in the field of distributed systems.
Lets say you need to keep a sorted set of sooooo much data that you cannot keep it all on one machine. I would imagine all financial services firms have some custom datastore which has "potential buy orders" and need to keep them all sorted by profitability to efficiently search/insert/remove from that datastore.
In such a situation, my instincts would be to create a distributed, redundant Heap. Now, how do you build a distributed, redundant Heap, without understanding how a Heap works? How do you even know what to look for if you don't know what a Heap is?
Now, lets say you've built it such that each node in your distributed network acted like a node in a Heap, and the left "pointer"(i.e. url to other computer) meant "less than" and the right "pointer" meant "greater than". Now you have this data store in production and all of a sudden you realize performance worsens over time... "WHY is this happening? Is there some memory leak?". You investigate and realize that all of your data isn't being distributed evenly! "Do I need to like.. shuffle the data around? How do I get it so that the data is evenly distributes?"
At this point if you do not know what a red-black tree is, what do you even google look for? Lets say you dig around for a while and find out about re-balancing trees. Now you have to implement it, and eventually you figure out that one of the best ways is to color your nodes. When a future colleague/manager asks, "What is this system, please describe it to me?" wouldn't it be nice to just say "Oh visualize it kinda like a distributed red-black tree. It holds XXX data, and ensures that it is always sorted and re-balanced for optimal performance."
FWIW finance normally uses big relational databases (because you absolutely need strong transaction support), something else off-the-shelf, or Microsoft Excel.
Of course there's some sort of B-tree somewhere in the stack; that's not the question.
With dozens of database stacks to choose from, many companies won't have anybody actively and regularly working in the database's code, nor in the OS kernel code either.
If, then, an individual can successfully contribute to the company without ever hearing of a red-black tree, what's the value in testing for it, past "this is how we've always done it"?
(How long it would take someone who doesn't know CS lingo to string together "tree" and "balance" and plug that into Google, I don't know, but I suspect it's not impossible to find.)
> Of course there's some sort of B-tree somewhere in the stack; that's not the question.
You've misunderstood me. I'm literally talking about building a distributed B-Tree or Heap. As in, a Heap which cannot fit in memory or storage of any one node.
Think: S3/DynamoDB is a distributed, highly available HashTable; _____ is a distributed, highly available Heap.
As a counterpoint, I work in high finance and one of our core systems that I'm expected to know extremely well uses Paxos for consensus.
Just because those topics show up infrequently doesn't mean that no one's using them. Plenty of companies outside of Google, etc. are doing complicated things that require a solid CS background.
My point was not that they do or do not exist, merely the magnitude. I would venture a guess that for every software engineer working on a blockchain there are 100 working on crud-style applications. If a job on your team requires a solid understanding of these concepts, then by all means filter on knowledge of algorithms. My point is that many companies don't do anything remotely as complex and yet use the same filters to screen job applicants.
exceedingly few programming jobs need to know anything resembling advanced computer science theory
There's "need" and there's "need". The person without the solid computer science background may very well be able to solve all the problems at hand, but the person with the solid CS background is far more likely to come up with the fast elegant solution that doesn't fall over in obscure corner cases.
To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.
You don't need to know how to implement a parser to recognize it as a solution to a problem. And there are already libraries and tools for building parsers anyway.
The hard part isn't building the parser, the hard part is recognizing that a parser would be a good solution to the problem and distilling the problem into a form for which the solution works. One of the main purposes of a college degree is to come out knowing a lot about what you don't know. That is, knowing a lot about what sorts of things exist, even if you don't know much detail about any of those things.
> the fast elegant solution that doesn't fall over in obscure corner cases
This can go both ways, though. Sometimes the fast elegant solution is too elegant for the nasty corner cases and a much bigger, uglier, but ultimately straightforward procedural block of crap is better.
The examples I've seen are from established businesses that occasionally slipped up in refactoring out hacks that were introduced to support deadline-driven requirements. A year or two later, that hack is powering the reporting for a huge portion of the traffic, and you have to be able to balance between (a) writing maintainable code that supports the hack for the short term and (b) working with the rest of the business to clean up the requirements so you can improve the system for the long term.
(b) is a skill that most interview processes I've seen completely ignore. And (a) often is downplayed (as "simple" or "easy") compared to more clever tricks - but knowing how to do the clever tricks might turn into a temptation to use them more than you should.
>There's "need" and there's "need". The person without the solid computer science background may very well be able to solve all the problems at hand, but the person with the solid CS background is far more likely to come up with the fast elegant solution that doesn't fall over in obscure corner cases.
I know the plural of anecdote is not data, but I'd say that the typical PhD that I have interviewed has generally poorer useful coding skills than the person from a similar background who stopped at a masters or even BS and then wrote a lot of high quality code during the time the PhD was doing a whole bunch of theoretical work.
>To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.
It's MUCH easier to come along after someone has already spent days exploring the problem and can demonstrate the dead ends, then say "oh, you need a custom parser" than to start at the beginning and do the same thing. USUALLY writing a custom parser is overkill and it takes a decent amount of digging into a system to know when it's not. If you start out writing one every time something looks like it can be solved by an "if" statement, you'd never get anything useful built.
Having basic algorithmic competence (and yes, BSTs + BFS/DFS are basic) is like knowing how to swim.
Maybe you aren't near water or writing performance-sensitive code 95% of the time, but the 5% of the time you're in over your head, being able to implement (or identify when to use) basic algorithms will save you a whole lot of time, money, and headache.
It's kind of how things work in our industry and I find it very frustrating. Once I became a "Front-end Engineer" I had to work like crazy to be "Backend" and then lucked into "Operations". Now I'm "Full-stack" but only a "Web Developer" so I can't do any cool ML stuff or data engineering or embedded or whatever. I have to do it in my free time and I'm exhausted most evenings. I do sacrifice my weekends! Yay!
From the management perspective, how else would you handle this? I.e. Allocation of resources? It's very difficult to reason about global resource allocation.
In addition how do you deal with resource mapping and best fit during allocation?
I think the multi-level allocation model works better than anything anyone else has suggested.
When I am a manager I will develop my people. I will hire them by getting to know them. I will encourage conference attendance and networking as well as outreach to study groups. Let's lift each other up and build welcoming communities of practice. Not sure what your reference to multi-level allocation model means.
I'm not sure conference attendance does anything worthwhile. It doesn't harm, but in my experience conference attendance only serves to pique interest in new/different technologies, not in actually learning it.
> And it really sucks that being a full time programmer isn't remotely sufficient experience for any kind of technical job interview
I won't name names, but at least one large tech company in the bay actually runs evening classes for people interviewing (classes that are run by somebody very well known in the interview prep field: these aren't cheap sessions run by somebody internal).
When I found this out I could only laugh: I assume the HR department looked at the number of people flaming out of the interviews and thought "what could we do about this?"...and rather than treating the symptom (changing the way that they interview) they treated the problem instead (even more prep).
Sounds like something Facebook would do. When I interviewed they told me that even though I was an industry candidate, they always try to make sure everyone gets two weeks before the interview to study. I don't know how this didn't set off BS detectors internally but there you have it.
Interviewing is stupid simple. It is your ego moment. You get to sit in a room and talk about yourself. Although you don't control the conversation you can steer it in creative enough directions to keep it fun and positive.
Maybe if you are a college grad with 0 real life experience then maybe interview prep is necessary... don't know. I could be biased though. The last place I interviewed at they knew who I was, something about my software, and some of my online controversies before I even walked in the door.
The best preparation for interviewing at large companies is having a second part-time job somewhere in management. I held my first management position in a part-time job at age 24 and was once a director. I have never held a management position in the primary full-time career, which is a weird inverse of power-distance in some work meetings. Being a parent is also good experience for dealing with people.
What they need to provide education on isn't dominating the interview process... but drilling down on the proper information necessary for new candidate retention.
I have worked at places that are awesome and really work hard to ensure you are happy and constantly engaged in the work. I have also worked at places that completely suck full of benchwarmers with a million layers of abstractions so that code monkeys can feel a bit more confident. It is helpful to know if you are going to be miserable in the organization.
The candidate really does share some of the burden of figuring out if they will be a good fit for the organization, but this is often really hard to interrogate out of the interviewers even for experienced people.
"Interviewing is stupid simple. It is your ego moment. You get to sit in a room and talk about yourself. Although you don't control the conversation you can steer it in creative enough directions to keep it fun and positive."
That would be a nice improvement as a first filter, IMO, but this isn't always the case. For Google, for instance, the very first step might be a 45-minute phone conversation with a bored engineer who just wants you to code up whatever tree-based structure and methods tickle their fancy. They might not even tell you what team they work on, or what they do. They have a script, and they run it from memory, and your experience and past accomplishments are out the window.
Google has the privilege to treat you like an ape, because they know people will take it to work there. "Dance monkey"! If being spanked like a monkey doesn't tickle your fancy then don't interview there. Interview prep isn't going to make that better.
As someone who recently ran the interview gauntlet, the parent comment seems pretty accurate. It matches my experience with interviews at a wide variety of companies.
Meanwhile, a bunch of non-Google companies think that this must be the right way to do it, so they copy it, and teaching people how to game the system like in the original article give them no reason not to, it just acclimates everyone to playing by stupid rules.
If you are a afraid of asking valid questions for fear that you will be rejected god help you. It doesn't hurt to simply ask a question.
Now I know there are a lot of weak and timid personalities in the world of development, but once you put that blood into the water usually it doesn't take the sharks long to swarm on it. I have never walked away from an interview feeling dejected for asking the interviewer reasonable questions or attempting to qualify their assertions.
Heck, I've walked away from an onsite mid-loop because I didn't like the process and it was stretching out and I had a flight to catch, but that doesn't mean I want things to be a "only the don't-give-a-fuck survive."
The first phone interview I got with them was with an interviewer asking questions that were given to them by someone else - ranging from how does DNS work to inodes in filesystems and estimating 2^128... at 6:30AM in the morning.
Interviewing is stupid simple. [...] Maybe if you are a college grad with 0 real life experience then maybe interview prep is necessary... don't know. I could be biased though. The last place I interviewed at they knew who I was, something about my software, and some of my online controversies before I even walked in the door.
Yes, this is bias. Most candidates aren't being hunted by employers. It's the other way around.
It's quite the opposite of "simple." It's a soul-crushing experience of being denied at every interview because you can't think out loud or do whiteboard coding and don't have a social media portfolio presence to fall back on. The only simple part is how simple it is to reject a candidate based on the personal prejudices of just one of the five different interviewers you have to meet with.
> Most candidates aren't being hunted by employers.
I call this the talent gap. When you are a newb or completely lack either experience or confidence in your skills life is harder. You have massively increased competition for lower paying jobs filled with more menial tasks. I have been there too. If a candidate doesn't want to be there they will invest in themselves outside the office. I spent as much time as I could writing open source software and language parsers while on military deployments.
Most developers I know are frequently hounded by recruiters because the demand for senior developers is stupid ridiculous.
Most developers I know are frequently hounded by recruiters because the demand for senior developers is stupid ridiculous.
Yes, but the next step is actually interviewing at companies.
It's obviously the best strategy to coax an employer into being interested in you, rather than the other way around. But most employers typically have an interview funnel, which I think is what people are talking about here. It sounds like you're referring to an employer actively seeking out a specific candidate that they're interested in. While that does happen, it's probably not the typical interview experience.
Talking to people is a life skill. That is what interviewing is. You aren't going to learn this from inside a CS textbook. Whether you are seeking the job or they are seeking you is largely irrelevant. Being an extreme introvert isn't an issue here either, although it did cause me to pass out in the taxi to the airport once after a 6 hour interview.
Just be honest (immediately so), be humble, and have confidence that you will do your very best. What ever happens after that you don't really control. It is okay to be nervous, but keep it in context. Nobody is shooting at you. You aren't drowning. Your housing isn't burning down. It is just a conversation.
You seem to be talking about a very different kind of interview than what anybody else here is talking about. The kind that is "just a conversation" is still more difficult than you're making it out to be for a lot of people, but it's definitely easier than the full day of whiteboard coding and no open ended conversation style that every big company uses and every wanna-be big company parrots.
I agree, though it can be a little jarring going into what you expect to be a whiteboard interview, and just answering questions verbally. Its nice, certainly, but if you're not expecting it (and why would you, given the odds) it can take a bit to get your footing.
Maybe it is because I have a ton of code online for anybody to read that nobody wants to waste their time watching me write code on a whiteboard for hours. Sure, I will get asked to write some code in an interview but it is usally something quick and dirty just to validate thinking through a problem with a bit of pressure.
Honestly, in my experience, most application problems can be reasonably talked through without writing any code.
Lots of people have lots of code online. Lots of companies don't take that into consideration when interviewing.
I share your experience that most problems can be reasonably talked through without writing code, but most people here are talking about a specific kind of interview that does not work that way.
Actually, I just finished a couple of weeks of interviews looking for a new job. I actually found that a lot of time I would talk through my solution to their whiteboard problem and by the time I'd talked it through--really just planning for myself before writing it out--they wouldn't wait for me to write it out. I'd explained it with enough clarity that actually writing it out would have just been a waste of time.
A different characterization is that we are looking for those that think well. Both talking and code on whiteboards are only proxies for that, and neither are completely reliable proxies.
But really, if someone can describe the detailed psuedocode for an algorithm and explain its runtime characteristics, are you going to make them write out what they have just said?
Personally, I think the talking is a lot more valuable than the whiteboard. I rarely have to hand-write complete algorithm on a whiteboard, but I regularly need to communicate technical ideas accurately and succinctly. That's what I'm really trying to demonstrate anyways: of course I can code, but I can also organize my thoughts well and communicate them clearly to others.
> Most developers I know are frequently hounded by recruiters because the demand for senior developers is stupid ridiculous.
Maybe in your bubble. My experience is that very few recruiters are hounding me, because most of them don't know I exist. I don't live or work in a tech hub, I don't work for a famous company, and I haven't published anything. I don't think that's a particularly unusual position to be in.
It's absolutely nothing to do with talent or experience, though.
" I haven't published anything"
Don't want to be rude but this is 100% your own fault and problem. What are you doing about this? I have two github profiles with code, I've spoken at conferences and I've got an active linkedin profile(yes I hate linkedin believe me), but this is the art of promoting yourself. If you are not writing open source code or talking on mailing lists or even IRC then how do you expect people to know who you are?
> the idea of devoting so much of my free time to studying boggles my mind. Programming 9-5 everyday makes me much less likely to want to do any coding when I get home.
I can sympathize, but I suggest long term you figure out a way to get over this sentiment. If you plan to work in the industry for any length of time you absolutely must study to stay employable.
With few exceptions almost every segment of the industry changes how it does things about every six years. What you do now will be pretty out of date in mid 2020. I've been working as a programmer since the late 80s. If I step back in six year increments and look at the technologies I was using, here's what I get:
At every stage of my career people I've known said there was no need to go learn new stuff. What they're doing will always be in demand. I'm talking about people doing things like ANSI 77 COBOL, RPG/3, and system 36 assembler. They were probably right, I'm guessing there's some orgs out there still using that stuff. But the options get smaller every year.
If you want to have your pick of the best opportunities available and be in control of your own destiny, and want to work in the industry more than 5 years, you're going to have to train yourself.
It'll help if you figure out a way to enjoy the experience and have fun with it.
I'm not attributing anything to either of your claims, but I'll claim that there's a big difference between staying fresh on CS interview stuff and staying up to date with production stacks. Both are probably necessary for maintaining employability at the interview stage to some extent, but the latter is a lot more reasonable than the former. You'll use modern stacks in most new jobs, but you won't use CS minutiae in most new jobs.
That's different though. Its like comparing learning Angular 2 or MongoDB with grinding through Cracking the Coding Interview. Sure they both involve doing stuff in your spare time, but the former can be (or made to be) much more interesting than regurgitating algorithms.
To each his own I guess. When I find time to get on those hackerrank type sites, I find the algorithm practice and refreshers to be both enjoyable and time extremely well spent in terms of maintaining fundamental CS skills. It doesn't matter if my job doesn't have me implementing graph algorithms every day, it affects the code I write (and decide not to write) all the time. Learning how to weld a few 3rd-party APIs together just isn't enough to be a truly good professional.
You're right, but the window dressing is the platforms we use to build production software. Other people responding to this comment seem to think that the CS fundamentals aren't worth getting good at. I think both the CS fundamentals and modern frameworks are both worth knowing well.
But then again, it goes back to the question of time. It is already hard enough to keep up with modern frameworks on one's free time. Adding CS fundamentals to the mix makes it worse. All of our free time will be eaten up.
Unless you like to be immersed in that world 24/7, something has got to give.
True, but you don't write merge sorts anymore. A lot of the fundamentals are valuable to know but not actually used in most situations. It's good you know how TLS works, but you really ought not be writing a TLS library yourself.
You'd be surprised how often tricks used in implementing those fundamental algorithms can be useful in day to day work.
Recent example I can think of was using GLPK to implement a dynamic allocation strategy for some spot instances for a pool of heterogeneous servers. I did not implement my own solver for the integer linear constraints but just knowing that allocation problems can be expressed as integer linear programs helped me tackle the problem in a way that others did not think of.
So I don't really buy the argument that knowing merge sort is useless knowledge because you never get to implement it. The value goes beyond just knowing the implementation. Same goes for other kinds of fundamental and timeless concepts and results.
Sure, but you're the guy who writes the library that I use because I have no clue what the hell you just said! It'd be downright dangerous if I hand-roll anything like it.
I hope that's not the lesson here. I was trying to get at the fact that understanding the fundamentals means understanding and exploiting the connections between seemingly different concepts and that learning and understanding merge sort is not time wasted and will come in handy in all sorts of situations.
When in doubt just remember this Feynman quote
“Right. I don’t believe in the idea that there are a few peculiar people capable of understanding math, and the rest of the world is normal. Math is a human discovery, and it’s no more complicated than humans can understand. I had a calculus book once that said, ‘What one fool can do, another can.’ What we’ve been able to work out about nature may look abstract and threatening to someone who hasn’t studied it, but it was fools who did it, and in the next generation, all the fools will understand it. There’s a tendency to pomposity in all this, to make it deep and profound.”
– Richard Feynman, Omni 1979
The point I'm trying to make is that what you're describing as "fundamentals" aren't actually fundamentals; that it's a spectrum, and the "things that need to be known to excel" are not what they used to be. Maybe they never were those things.
There's a heavy bias towards the belief that CS, as it is currently taught, provides the "fundamentals" of software development and design. It does not, at least not as completely as the common belief seems to be. This can be reinforced by the current state of our interview processes. One has to re-prove one's understanding of such fundamental concepts, when the degree should, in theory, be enough, as it is in many other professions.
Conversely, a failure to understand fundamental CS concepts (invert a binary tree) doesn't preclude someone from being a successful software engineer (create homebrew).
Actually the rest isn't window dressing, unless you're working on a very narrowly scoped glorified CS project. Actual engineering-scope projects may or may not require a deep understanding of "the fundamentals" but certainly not to the extent that the focus on them for interviews suggests.
You don't necessarily need to study for hours in your spare time to do this. Usually when people talk about studying to pass a Big 4 interview they're talking about brushing up on the algorithm stuff and not learning some new tech. For the sort of thing you're talking about, finding your way into jobs working on cool stuff will often provide the boost that you need.
IMO all but the most serious of side projects tend to not build enough experience to pass an interview for Technology XYZ anyways so unless a company is willing to deal with a newbie, and many are, it doesn't matter that much.
You can be sure that they want more supply in the market to drive down cost! I think it's safe to say that developers are pretty expensive as far as individual contributors go. Especially good ones.
Companies are perfecly happy paying their sales staff huge bonuses for 'value delivered', the fact that programmers are at the beginning of that value chain in many cases and bad at negotiation actually makes them cheap. Even the good ones.
Good ones are spectacularly cheap. 10x developers are a real thing, but I've only very rarely heard of anyone who makes 10x salary as an individual contributor. Those folks are names most in this community would know.
Now i am realizing this. Once you accept that the only way to remain in the industry is to work after work you just get used to it, although it still sucks :) .
If employers can get away with the bullshit that they do, it's a buyers market.
In my personal experience, I've rarely had problems hiring qualified candidates, and my employer doesn't pay particularly well, and isn't located in a particularly large market. A company like Google who does pay very generously needs to narrow the funnel just to get the pool down to an actionable number.
Transitioning to working full-time has made me realize how much more freedom I had with my time as a college student.
That being said, you don't need to spend too much time studying for interviews (~30 minutes a day for a few months is more than sufficient).
Really? I have the exact opposite experience, I feel much more free to study and work on whatever I want now that I graduated. I would always feel bad for working my own stuff instead of just working on the class project or homework.
It's really unfortunate that motivated people spend so much time matching themselves to what companies look for. Gives the top companies a lot less incentive to reevaluate their own processes.
But it gives you a great opportunity if you're a less well known company without the same name recognition. If your process is the same as Google's, you'll have candidates picking between the resume stamp that is a stint at Google and your offer. If your process is intentionally somewhat different than Google's, but tailored to your own immediate needs, you'll have a wider pool.
I'm currently studying to find a new job. I intend to memorize all the algorithms I can, all the tricks, and completely fake like I'm figuring out the answers on the spot when I interview. I will dedicate the next 3-4 months on this. That's just how things are these days unfortunately.
You're supposed to act like you're figuring it out in real time during the interview. They're "seeing how you think". When really you're just trying to recall.
Learning what? In most cases you will be strictly forbidden to use basic algorithms in your job. No one allows you to write quick sort or hash-table or crypto from scratch.
Something else that you might try, instead of doing 'practice problems', consider taking each algorithm or concept you want to learn and putting it together with a project that can use it. Everyone learns differently and for people like me, things 'stick' better in my head when I can relate them to a project rather than just as a bare concept unrelated to the real world.
As someone who is already in Amazon and moved teams, I recommend you to keep your interviewing skills sharp, specially if you see that the project you're working on is going nowhere and might be cancelled. You wanna be ready to interview so that you don't get moved to a random team. I was in that situation and it really sucks. I had to start over getting used to interviewing, failing 2 or 3 interviews before I landed a job with another team. A really complicated time for me.
Agreed, some teams at amazon are hire/fire fast. Not all but some. Keep going to interviews, even if you are only mildly interested. Keep your skills sharp. Enjoy the interviews. Make sure the companies pay for everything.
I'm not sure if I understood this correctly - you had to interview for another team within the company, even though you've already went through that same process once? If true, that's ridiculous.
Hell, it's what Microsoft was doing fifteen years ago, and I have no reason to think it has changed. Change teams? You have to go through the same loop and same hazing as a new-hire candidate. There might be a little less paperwork, I don't recall.
This is strictly for those in college with the TIME to study and interview. I'm a year out of a top-10 college; just signed a new job offer recently. Let's just say that difference is day and night. College is very much a cushion for your job search process. Grown ups have to deal with the emotions of failing startups, working over time to push through deals/compliance issues. Try having the stress of a family and dependents, yikes...
This makes sense if you're still in college and learning but if you're already a professional you should not be studying. If you get asked pointless CS questions in an interview walk out. That is a terrible way of finding good employees. Employers should be asking questions relevant to the position.
What would you say are examples of meaningful vs. pointless CS questions? Anecdotally speaking, I've heard of senior engineer interviews where the candidate has an impressive resume but has difficulty coding solutions to "basic" problems.
For a senior role - "Basic"/pointless problems are those algo questions you would ask at the big 4. Rarely will you find a senior level engineer knowing the best solution to inverting a binary tree or any other text book problem you know because 9/10 times those are not used at all in any of the most common real world cases.
However, what meaningful questions will cover are advanced architectural problems, particular inner workings of a tool/framework, how to squeeze in the last few drops of optimization etc. Conversation should flow without any major breaks and the most experienced engineers will talk about edge cases of edge cases, thus continuing the conversation themselves. You can discuss different types of architectural patterns, ins and outs of each one and how it can be applied to a particular problem.
You should not waste the engineers time on textbook questions if you value yourself or the interviewee, and as the parent comment stated - the engineer should walk out if they start asking "basic" questions. Someone that worked in the industry for 10-15 years should not be bothered with them.
Do you want employees who when they need to sort something their first thought is "I'll write this from scratch"? Pretty much every language and framework out there has it's own optimized sorting algorithm provided by the standard library of the language. In the rare cases where for whatever reason that isn't the right answer you'd be better off with someone who knows how to properly research a problem and find a solution based on the particulars not repeat some standard line from their University CS classes.
That's a great way to find yourself without any hopes of a job. Companies (including all of the big ones) pretty much all conduct interviews this way and there's no way they're going to change their practices in light of one person's crusade when there's an endless supply of candidates who want that job.
> Companies (including all of the big ones) pretty much all conduct interviews this way
I've interviewed for developer positions in Pennsylvania, with companies ranging from well-known Fortune 500s to local shops. Not one of them had a whiteboard, asked me to write code, or asked me to develop an algorithm or solve a puzzle.
The interviews were largely the same as those I've heard about for most other jobs: you go over your resume, talk about what you did at past jobs, answer cliche questions like "how do you handle disagreement" or "where do you see yourself in 5 years", talk about the position they're hiring for and their culture, and maybe about compensation.
So maybe it's more accurate to say something like "tech companies (primarily the big ones in Silicon Valley) in the handful of high-tech startup hubs in the world pretty much all conduct interviews this way".
If this comment gets more popular, the Philly and Pittsburgh tech scenes are gonna suddenly explode with devs who are sick of both SV interview practices and rent prices.
Amazon recently opened new office in Boulder (i believe) and started hitting up a lot of folks in the surrounding states. I live in CO, but my company is in KS and I started hearing a lot of chatter among our interns that they're grabbing kids left and right from schools in the area with mediocre to below average computer science programs. In fact, one of the kids who interviewed at our place ended up taking an offer from Amazon, which i kid you not was around $100K more than what my company was offering for a new grad with no prior experience and a degree from a school that doesn't even make it to the top 100 in the nation.
100k more for a new grad? That can't be right. Five years back, the new grad offer was 90k, plus 45k of stock over four years. If they're up that much, things must be getting desperate.
I'm sure $90K is a thing somewhere on the coasts. A typical starting salary around here (MO/KS) is $60-65K considering you have some internship experience. Otherwise it's usually in the mid 50s. Amazon offered $160K (bonus included).
I would guess the fact that most starting developer salaries are 60-65k in your city is the reason Amazon opened an office there.
I moved to the Toronto office not long after I joined, and that office existed for similar reasons. Lots of talent, but generally low wages in the city. Made recruiting easy- they went from 25 people five years ago to 500+ today.
It's a good strategy. The best engineer I've ever worked with went to a school I'd never heard of. I've worked with plenty of people from Cal/Stanford who couldn't code their way out of a wet paper bag.
I'd be careful about being so infatuated by school name - for example, I went to a state school in undergrad that most not from NY probably heard of. My peers in my majors went on to finish PhDs in math, physics, economics, and attend prestigious programs at schools like MIT. In addition, one of the smartest people in my PhD program in math at UIUC graduated from Cal State Long Beach - he was smarter than just about everyone else in the PhD program. I also have another smart friend who is a college dropout - he currently is a standout at Google.
Don't use any metric other than performance to judge people. You will find many surprises in the world, and smart people who have many unique stories to tell.
I'm not infatuated with any particular school. I myself graduated from a low-ranked CS school. I was just making a point that a degree from a fancy school like Stanford where the OP graduated from no longer limits you from getting into companies like Google and Amazon. If anything i'm actually happy that these companies aren't stigmatizing or stereotyping graduates based on which school they went to.
I failed every coding interview as well. I'm not a great programmer - no industry experience, only academic, (but I passed all of the "coding riddle" problems my friend who is a senior programmer kept failing), and I made it through triplebyte's interview (I can write a bloom filter from scratch in under an hour). When whiteboarding though I have problems like, "doesn't default to hash", "has trouble remembering how to BFS", etc.
Eventually I got a programming job doing data science at a startup in "emergency hire mode". Didn't have to whiteboard, was hired on reputation and friend network alone. They even forgot to ask me to send a link to my GitHub. Most of my day to day in the first few weeks has been literally "debugging shellscript".
TLDR; Lots of practice, at least one problem every day from CTCI.
The reason this article is interesting is entirely because author is actually CS student and that too from Stanford. Most CS majors anywhere in the world have to take algorithms classes and even more advanced compiler design, distributed computing, parallel programming, graph theory etc (for example, Stanford has CS161). Its hard to imagine CS student who hadn't had Introduction to Algorithms as textbook and did not had to do at least few assignments from that book.
So given all that, I'm wondering how author got through those classes because those classes are usually much more demanding than tech interviews and questions are more harder (try yourself doing CS161 final exam [1]). While CTCI does have lot of material that is not covered in typical CS classes, I would think pretty much all fundamentals such as permutations and basics like checking correctness of recursive algorithms or runtime complexity etc is very well covered. In fact I would argue that anyone heavily relying on CTCI as only source would be much weaker on these fundamentals and a competent interviewer would be easily able to identify them.
195 comments
[ 3.0 ms ] story [ 199 ms ] threadBut I find that concept silly since since whole point of interview is to find how good you are as a developer. Not how good you are at interviewing.
Adaptability / self-teachability / willingness to jump through hoops
Inversely, not knowing the technical questions doesn't mean that alone is the reason the interview "failed". /r/cscareerquestions had good discussion yesterday about the realities of interviewing: https://www.reddit.com/r/cscareerquestions/comments/68czkl/w...
[0] http://reginaldlong.com/i-failed-my-tech-interview-and-i-don...
1. You didn't make enough progress on the problem.
The interviewer didn't properly explain the scope of the problem.
2. You were too slow and didn't get through all of the problems.
Again, a scoping issue on the interviewer's part. When I interview, I have one _single_ problem that I pose. I interview largely for embedded security folks, so I write this on the board:
void func(char* arg) { char buf[128]; strcpy(buf, arg); }
And I will ask them to explain what's wrong with it. Most people can answer that question fairly easily. With this simple problem on the table I now have a base to start more questions from:
- How would you fix this problem? - In a large codebase, how would you find this problem? - What's really happening here on a machine level? - What sort of system-level mitigations can I implement?
These are all branches I can take, and once I feel like the interviewee is out of his depth in any one of them I jump back up. I'm trying to assess the skill-level of the person, not whether they meet some minimum bar (though I can do this afterwards, of course).
3. Your solution is complicated.
There's a little bit of shared blame here. The playing-field isn't level in an interview as the interviewee is naturally going to be nervous. You as an interviewer can help level it a little by giving some broad strokes help. "That solution looks like it might end up a little complicated. Do you think there's a better one?". I have given no technical guidance, but have given the interviewee a chance to step back and think.
4. You didn't communicate well enough with the interviewer
Everyone works differently. When I'm solving a problem, I like being alone in my head to focus. Some people more naturally are drawn towards collaborative problem solving. An interviewer that doesn't recognize this is a poor interviewer.
You as the interviewer can solve the problem by occasionally asking "So, what direction are you thinking?" or "Can you write me out on the whiteboard where you're going?".
5. You ignored the interviewer's feedback
Yeah, ok, that one is on you.
I'd much rather solve this one - and talk about maintaining legacy systems, than any of the other interviews I've done.
I found that I really like the "pick one problem/question and go deep and/or wide" approach. The above example I can go anywhere from compilers (Q: "What's the smallest function a compiler could legally output given this code?" (I love this one :P)) to C (Q: "How is 'buf' allocated?") to static analysis (Q: "How would I statically find all instances of this pattern?") to exploits (Q: "How would I exploit this vulnerability?") to mitigations (Q: "Given a stack overflow, what can I do to make it harder to exploit for the attacker?"), etc. etc. etc.
It's a young field, there will be more and more people who code into their 70's and 80's as the first batch of gen-X matures.
There is a lot more nuance to tech job interviewing (including luck that you got a good interviewer/interviewer was not in a bad mood), despite the changing landscape which emphasizes trick coding.
As a counter anecdote, I had someone tell me they did an interview loop where the guy interviewing had social anxiety problems so he would talk to a hand puppet instead of the interviewer. He got all the technical questions correct and was hired, apparently, so there's that.
This candidate is probably going to frustrate themselves to death. Tech industry is not at all great for engineers these days.
Here's some food for you to chew: https://sites.google.com/site/thefaceofamazon/home
Plenty of jobs outside the 'Tech' industry bringing stuff into other companies, it's not as 'glamorous' but it pays the bills and you get through the door a lot easier.
I'm from the UK and consciously stay out of the local start up scene because I think the culture was/is toxic and have for a long time but there are solid and interesting programming jobs out in the wider world.
It's the same in India and China as well. Too much competition for fewer and fewer resources, chasing money is the norm...until suddenly they're in a hospital death bed, trying to get out of medical debt.
It's not so much about marginalizing a job as much as an examination of the value of education from a good school.
Either education isn't valuable anymore or companies suck at allocating bright minds. You choose!
Does that mean second course, or second class? Because second class would be pretty intense. Although second course is pretty intense too.
It's hard for first years, but the prof is really good though
Sounds like some good Koolaid
I hope you like it and find it useful. I think it's still relevant today.
I'd love to get in touch with you. My email is reggylong at gmail.com
The problem is when the random nothing-but-CRUD companies/startups think they need google-caliber engineers.
So, to the extent that smart people want to work with other smart people, rather than just anyone who can get the job done, they introduce a completely arbitrary bar that is hard to clear in addition to all the normal job requirements. This leads to lots of people being overqualified for their jobs.
I have no explanation for smaller companies doing this, except to ape the big guys.
That's the sad thing really. What works for the big companies don't necessarily work for the small ones.
Big companies can afford a lot of false negatives.
No one asks historical foundations of arithmetics during basic math exam. You don't need to know how to multiply roman number.
"A. On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart."
http://www.nytimes.com/2013/06/20/business/in-head-hunting-b...
In fact I think that often scoring 100% on the technical has hurt me because they believed my ability outscopes the role they're hiring for. (though they won't hire me for a senior role because I'm too young, eurgh.)
EDIT: In fact I think the best correlated factor has been applying for jobs where I'm apparently not qualified enough, the companies that decide to interview me anyway are:
- Willing to assess me not $YEAR - $GRADUATED
- Struggling for candidates
Source: Have been involved in hiring at giant software corp
And it really sucks that being a full time programmer isn't remotely sufficient experience for any kind of technical job interview. I'd be laughed out of the office if I suggested we write BST algorithms on whiteboards.
However, I strongly disagree with your statement!
I work on distributed systems day in and day out, and more and more I find that I'm using or building distributed data structures analogous to BST, HashTable, etc.
Not knowing the foundations of my field in and out would be a mistake!
Disclaimer: Never worked in financial tech, I have thought about this problem for 5 mins. This is unlikely to be an optimal solution to keeping a sorted set of distributed data. I'm just trying to show how basic knowledge of data structures helps in the field of distributed systems.
Lets say you need to keep a sorted set of sooooo much data that you cannot keep it all on one machine. I would imagine all financial services firms have some custom datastore which has "potential buy orders" and need to keep them all sorted by profitability to efficiently search/insert/remove from that datastore.
In such a situation, my instincts would be to create a distributed, redundant Heap. Now, how do you build a distributed, redundant Heap, without understanding how a Heap works? How do you even know what to look for if you don't know what a Heap is?
Now, lets say you've built it such that each node in your distributed network acted like a node in a Heap, and the left "pointer"(i.e. url to other computer) meant "less than" and the right "pointer" meant "greater than". Now you have this data store in production and all of a sudden you realize performance worsens over time... "WHY is this happening? Is there some memory leak?". You investigate and realize that all of your data isn't being distributed evenly! "Do I need to like.. shuffle the data around? How do I get it so that the data is evenly distributes?"
At this point if you do not know what a red-black tree is, what do you even google look for? Lets say you dig around for a while and find out about re-balancing trees. Now you have to implement it, and eventually you figure out that one of the best ways is to color your nodes. When a future colleague/manager asks, "What is this system, please describe it to me?" wouldn't it be nice to just say "Oh visualize it kinda like a distributed red-black tree. It holds XXX data, and ensures that it is always sorted and re-balanced for optimal performance."
With dozens of database stacks to choose from, many companies won't have anybody actively and regularly working in the database's code, nor in the OS kernel code either.
If, then, an individual can successfully contribute to the company without ever hearing of a red-black tree, what's the value in testing for it, past "this is how we've always done it"?
(How long it would take someone who doesn't know CS lingo to string together "tree" and "balance" and plug that into Google, I don't know, but I suspect it's not impossible to find.)
You've misunderstood me. I'm literally talking about building a distributed B-Tree or Heap. As in, a Heap which cannot fit in memory or storage of any one node.
Think: S3/DynamoDB is a distributed, highly available HashTable; _____ is a distributed, highly available Heap.
Just because those topics show up infrequently doesn't mean that no one's using them. Plenty of companies outside of Google, etc. are doing complicated things that require a solid CS background.
There's "need" and there's "need". The person without the solid computer science background may very well be able to solve all the problems at hand, but the person with the solid CS background is far more likely to come up with the fast elegant solution that doesn't fall over in obscure corner cases.
To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.
This can go both ways, though. Sometimes the fast elegant solution is too elegant for the nasty corner cases and a much bigger, uglier, but ultimately straightforward procedural block of crap is better.
The examples I've seen are from established businesses that occasionally slipped up in refactoring out hacks that were introduced to support deadline-driven requirements. A year or two later, that hack is powering the reporting for a huge portion of the traffic, and you have to be able to balance between (a) writing maintainable code that supports the hack for the short term and (b) working with the rest of the business to clean up the requirements so you can improve the system for the long term.
(b) is a skill that most interview processes I've seen completely ignore. And (a) often is downplayed (as "simple" or "easy") compared to more clever tricks - but knowing how to do the clever tricks might turn into a temptation to use them more than you should.
I know the plural of anecdote is not data, but I'd say that the typical PhD that I have interviewed has generally poorer useful coding skills than the person from a similar background who stopped at a masters or even BS and then wrote a lot of high quality code during the time the PhD was doing a whole bunch of theoretical work.
>To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.
It's MUCH easier to come along after someone has already spent days exploring the problem and can demonstrate the dead ends, then say "oh, you need a custom parser" than to start at the beginning and do the same thing. USUALLY writing a custom parser is overkill and it takes a decent amount of digging into a system to know when it's not. If you start out writing one every time something looks like it can be solved by an "if" statement, you'd never get anything useful built.
Maybe you aren't near water or writing performance-sensitive code 95% of the time, but the 5% of the time you're in over your head, being able to implement (or identify when to use) basic algorithms will save you a whole lot of time, money, and headache.
In addition how do you deal with resource mapping and best fit during allocation?
I think the multi-level allocation model works better than anything anyone else has suggested.
I won't name names, but at least one large tech company in the bay actually runs evening classes for people interviewing (classes that are run by somebody very well known in the interview prep field: these aren't cheap sessions run by somebody internal).
When I found this out I could only laugh: I assume the HR department looked at the number of people flaming out of the interviews and thought "what could we do about this?"...and rather than treating the symptom (changing the way that they interview) they treated the problem instead (even more prep).
The company is Google and the interview prep person is Gayle from cracking the code interview.
My reaction was the same as yours.
Maybe if you are a college grad with 0 real life experience then maybe interview prep is necessary... don't know. I could be biased though. The last place I interviewed at they knew who I was, something about my software, and some of my online controversies before I even walked in the door.
The best preparation for interviewing at large companies is having a second part-time job somewhere in management. I held my first management position in a part-time job at age 24 and was once a director. I have never held a management position in the primary full-time career, which is a weird inverse of power-distance in some work meetings. Being a parent is also good experience for dealing with people.
What they need to provide education on isn't dominating the interview process... but drilling down on the proper information necessary for new candidate retention.
I have worked at places that are awesome and really work hard to ensure you are happy and constantly engaged in the work. I have also worked at places that completely suck full of benchwarmers with a million layers of abstractions so that code monkeys can feel a bit more confident. It is helpful to know if you are going to be miserable in the organization.
The candidate really does share some of the burden of figuring out if they will be a good fit for the organization, but this is often really hard to interrogate out of the interviewers even for experienced people.
That would be a nice improvement as a first filter, IMO, but this isn't always the case. For Google, for instance, the very first step might be a 45-minute phone conversation with a bored engineer who just wants you to code up whatever tree-based structure and methods tickle their fancy. They might not even tell you what team they work on, or what they do. They have a script, and they run it from memory, and your experience and past accomplishments are out the window.
Now I know there are a lot of weak and timid personalities in the world of development, but once you put that blood into the water usually it doesn't take the sharks long to swarm on it. I have never walked away from an interview feeling dejected for asking the interviewer reasonable questions or attempting to qualify their assertions.
Yes, this is bias. Most candidates aren't being hunted by employers. It's the other way around.
It's quite the opposite of "simple." It's a soul-crushing experience of being denied at every interview because you can't think out loud or do whiteboard coding and don't have a social media portfolio presence to fall back on. The only simple part is how simple it is to reject a candidate based on the personal prejudices of just one of the five different interviewers you have to meet with.
I call this the talent gap. When you are a newb or completely lack either experience or confidence in your skills life is harder. You have massively increased competition for lower paying jobs filled with more menial tasks. I have been there too. If a candidate doesn't want to be there they will invest in themselves outside the office. I spent as much time as I could writing open source software and language parsers while on military deployments.
Most developers I know are frequently hounded by recruiters because the demand for senior developers is stupid ridiculous.
Yes, but the next step is actually interviewing at companies. It's obviously the best strategy to coax an employer into being interested in you, rather than the other way around. But most employers typically have an interview funnel, which I think is what people are talking about here. It sounds like you're referring to an employer actively seeking out a specific candidate that they're interested in. While that does happen, it's probably not the typical interview experience.
Just be honest (immediately so), be humble, and have confidence that you will do your very best. What ever happens after that you don't really control. It is okay to be nervous, but keep it in context. Nobody is shooting at you. You aren't drowning. Your housing isn't burning down. It is just a conversation.
Honestly, in my experience, most application problems can be reasonably talked through without writing any code.
I share your experience that most problems can be reasonably talked through without writing code, but most people here are talking about a specific kind of interview that does not work that way.
That might be an unfair characterization. But only just.
But really, if someone can describe the detailed psuedocode for an algorithm and explain its runtime characteristics, are you going to make them write out what they have just said?
Personally, I think the talking is a lot more valuable than the whiteboard. I rarely have to hand-write complete algorithm on a whiteboard, but I regularly need to communicate technical ideas accurately and succinctly. That's what I'm really trying to demonstrate anyways: of course I can code, but I can also organize my thoughts well and communicate them clearly to others.
Maybe in your bubble. My experience is that very few recruiters are hounding me, because most of them don't know I exist. I don't live or work in a tech hub, I don't work for a famous company, and I haven't published anything. I don't think that's a particularly unusual position to be in.
It's absolutely nothing to do with talent or experience, though.
I can sympathize, but I suggest long term you figure out a way to get over this sentiment. If you plan to work in the industry for any length of time you absolutely must study to stay employable.
With few exceptions almost every segment of the industry changes how it does things about every six years. What you do now will be pretty out of date in mid 2020. I've been working as a programmer since the late 80s. If I step back in six year increments and look at the technologies I was using, here's what I get:
2011: Python, Django, MySQL, Jquery, Mercurial (not Git).
2005: PHP, CakePHP, MySQL.
1999: AIX, PowerBuiler, VB6, FoxPro, Access
1993: DBase 3, 8 bit embedded systems (68HC11)
At every stage of my career people I've known said there was no need to go learn new stuff. What they're doing will always be in demand. I'm talking about people doing things like ANSI 77 COBOL, RPG/3, and system 36 assembler. They were probably right, I'm guessing there's some orgs out there still using that stuff. But the options get smaller every year.
If you want to have your pick of the best opportunities available and be in control of your own destiny, and want to work in the industry more than 5 years, you're going to have to train yourself.
It'll help if you figure out a way to enjoy the experience and have fun with it.
Unless you like to be immersed in that world 24/7, something has got to give.
Recent example I can think of was using GLPK to implement a dynamic allocation strategy for some spot instances for a pool of heterogeneous servers. I did not implement my own solver for the integer linear constraints but just knowing that allocation problems can be expressed as integer linear programs helped me tackle the problem in a way that others did not think of.
So I don't really buy the argument that knowing merge sort is useless knowledge because you never get to implement it. The value goes beyond just knowing the implementation. Same goes for other kinds of fundamental and timeless concepts and results.
When in doubt just remember this Feynman quote
“Right. I don’t believe in the idea that there are a few peculiar people capable of understanding math, and the rest of the world is normal. Math is a human discovery, and it’s no more complicated than humans can understand. I had a calculus book once that said, ‘What one fool can do, another can.’ What we’ve been able to work out about nature may look abstract and threatening to someone who hasn’t studied it, but it was fools who did it, and in the next generation, all the fools will understand it. There’s a tendency to pomposity in all this, to make it deep and profound.” – Richard Feynman, Omni 1979
There's a heavy bias towards the belief that CS, as it is currently taught, provides the "fundamentals" of software development and design. It does not, at least not as completely as the common belief seems to be. This can be reinforced by the current state of our interview processes. One has to re-prove one's understanding of such fundamental concepts, when the degree should, in theory, be enough, as it is in many other professions.
Conversely, a failure to understand fundamental CS concepts (invert a binary tree) doesn't preclude someone from being a successful software engineer (create homebrew).
IMO all but the most serious of side projects tend to not build enough experience to pass an interview for Technology XYZ anyways so unless a company is willing to deal with a newbie, and many are, it doesn't matter that much.
In my personal experience, I've rarely had problems hiring qualified candidates, and my employer doesn't pay particularly well, and isn't located in a particularly large market. A company like Google who does pay very generously needs to narrow the funnel just to get the pool down to an actionable number.
But it gives you a great opportunity if you're a less well known company without the same name recognition. If your process is the same as Google's, you'll have candidates picking between the resume stamp that is a stint at Google and your offer. If your process is intentionally somewhat different than Google's, but tailored to your own immediate needs, you'll have a wider pool.
Death would be better than working at Amazon.
Poor guy.
I don't think it's ridiculous. After all, different teams may have different hiring bars and specific skills you have to be proficient on.
Some teams can have harder interviews than others. I can confirm that first hand.
This makes sense if you're still in college and learning but if you're already a professional you should not be studying. If you get asked pointless CS questions in an interview walk out. That is a terrible way of finding good employees. Employers should be asking questions relevant to the position.
However, what meaningful questions will cover are advanced architectural problems, particular inner workings of a tool/framework, how to squeeze in the last few drops of optimization etc. Conversation should flow without any major breaks and the most experienced engineers will talk about edge cases of edge cases, thus continuing the conversation themselves. You can discuss different types of architectural patterns, ins and outs of each one and how it can be applied to a particular problem.
You should not waste the engineers time on textbook questions if you value yourself or the interviewee, and as the parent comment stated - the engineer should walk out if they start asking "basic" questions. Someone that worked in the industry for 10-15 years should not be bothered with them.
I've interviewed for developer positions in Pennsylvania, with companies ranging from well-known Fortune 500s to local shops. Not one of them had a whiteboard, asked me to write code, or asked me to develop an algorithm or solve a puzzle.
The interviews were largely the same as those I've heard about for most other jobs: you go over your resume, talk about what you did at past jobs, answer cliche questions like "how do you handle disagreement" or "where do you see yourself in 5 years", talk about the position they're hiring for and their culture, and maybe about compensation.
So maybe it's more accurate to say something like "tech companies (primarily the big ones in Silicon Valley) in the handful of high-tech startup hubs in the world pretty much all conduct interviews this way".
http://paulgraham.com/pgh.html
https://www.slideshare.net/perlcareers/how-to-prepare-for-an...
I moved to the Toronto office not long after I joined, and that office existed for similar reasons. Lots of talent, but generally low wages in the city. Made recruiting easy- they went from 25 people five years ago to 500+ today.
Don't use any metric other than performance to judge people. You will find many surprises in the world, and smart people who have many unique stories to tell.
Eventually I got a programming job doing data science at a startup in "emergency hire mode". Didn't have to whiteboard, was hired on reputation and friend network alone. They even forgot to ask me to send a link to my GitHub. Most of my day to day in the first few weeks has been literally "debugging shellscript".
The reason this article is interesting is entirely because author is actually CS student and that too from Stanford. Most CS majors anywhere in the world have to take algorithms classes and even more advanced compiler design, distributed computing, parallel programming, graph theory etc (for example, Stanford has CS161). Its hard to imagine CS student who hadn't had Introduction to Algorithms as textbook and did not had to do at least few assignments from that book.
So given all that, I'm wondering how author got through those classes because those classes are usually much more demanding than tech interviews and questions are more harder (try yourself doing CS161 final exam [1]). While CTCI does have lot of material that is not covered in typical CS classes, I would think pretty much all fundamentals such as permutations and basics like checking correctness of recursive algorithms or runtime complexity etc is very well covered. In fact I would argue that anyone heavily relying on CTCI as only source would be much weaker on these fundamentals and a competent interviewer would be easily able to identify them.
[1] http://web.stanford.edu/class/cs161/final-autumn16.pdf