Good piece, but misleading title. There is a big difference between "cramming" and preparing. Like the author says: "Preparing by learning about a company and its product makes sense. But preparing for an interview by cramming/studying material that is supposedly needed for the job makes no sense."
When I get a candidate who has no sense of the job they are applying for and is not able to ask meaningful questions, it tells me they don't care or don't understand.
If you are completely unqualified for the job, you will be found out, but if the difference in skill/experience is small enough, it's probably best to be honest about the gap. In that case, "studying up" may be a risky investment of your time, but at best it may show your commitment and at worst you will have picked up some new skills :)
The issue is that companies like Google EXPECT you to cram on algorithms before the interview.
They will even give you a study guide!
Being really good at programming on a whiteboard is the name of the game. And studying for this is absolutely useful, and not "cheating" because everyone does it and is expected to do it.
How does one become really good at programming on a whiteboard? Should you rent a conference room and hire a couple of people to play the part of the interviewers and just practice?
I don't know about the US, but in India there are coaching institutes where you can pay money to be taught exactly that, how to clear interviews of Google, Amazon etc. They make you practise all sorts of algos on whiteboards.
This is only useful to the interview as a process and to the company since it believes that the best hires are the ones that study the hardest.
I don't see how this process is useful to the candidate. I mean it is useful if he is actually hired but is there any other usefulness beyond this? Does it improve your skill? Makes you a better person? Is it fun? I don't think so.
I don't think companies necessarily think that. I think most companies resort to algorithm style interviews because they can't think of anything else that is better. You've got a candidate for probably an hour, probably in a room without a computer, what else can you do to exercise their programming knowledge besides toy algorithm problems?
Studying to interview with a big company definitely improved my skill and knowledge of Computer Science. Not fun, certainly, but to some degree useful outside of the interview.
Most companies aren't like Google. It makes sense for Google to encourage cramming on algorithms because the type of programmer Google does not need is one who "doesn't do algorithms" and so the cramming expectation filters against those. The type of programmer Google wants is one who can cram for algorithms in the sense that when there is a problem, the programmer can sit down and research algorithms and distinguish between them and perhaps even come up with a new twist.
The other day, I read a rant about an algorithms interview question at some big company (it might have been Google, but I'm not sure and it doesn't matter). Essentially the rant was that the candidate had been asked to implement an obscure version of some widely known and well described function that has O(n) time where all the standard and widely studied and likely to be crammed versions have O(n log n) time -- more or less the question was based on an algorithm of the sort that probably appears in a research journal or conference proceedings and no where else. Essentially, the question was uncrammable.
That's what makes it a great interview question. It identifies true genius when the candidate can figure it out on the fly. It identifies ordinary engineering talent when the candidate starts with what they know [an O(n log n) solution] and reasons from there (and perhaps asks for help!] and it identifies people candidates who are applying at Google because it is Google and not because they enjoy challenging problems.
Peter Norvig is Director of Research at Google. This is one of his essays: http://norvig.com/21-days.html For some people six months spent learning algorithms has value independent of Google's hiring process. Other people maybe not.
There is a difference between learning algorithms at leisure for enjoyment versus rigid thorough preparation for particular interview at particular company... Many can't afford the latter, especially during mid-career.
I used to work at Google. I didn't study for the interviews, I just showed up. It went well enough to be hired. I did study CS and know my algorithms and data structures though.
It would be really interesting to do a study of Googlers and see how much time on average they spent preparing for the interview. Would also be interesting to compare that with average preparation of people who interviewed but didn't get the job.
And finally, it would be fascinating to plot career performance at Google vs time spent interviewing. Intuitively I would expect those who got an offer without studying to do better (higher latent intelligence), but I could also see it going the other way (lots of studying correlates with willingness to work hard on boring problems, which is what most Google engineers actually have to do day-to-day).
Yeah, same here - this "cramming for the Google interview" concept is strange. It's not like the interviewers asked lots of exotic trick questions; they were just making sure I understood CS fundamentals and knew how to solve problems. The interviews did add up to a solid, tiring day of engineering work, but it all seemed like reasonable stuff - they were questions about concepts anyone working at Google ought to be comfortable with.
And some people don't have to cram for there intro to data structures CS class.
Other people do though.
Perhaps you are one of those people who could just walk in and Ace the final exam for an intermediate data structures and algorithms class taught at colleges.
Can you explain how you kept the algorithms/data structures knowledge in your head fresh enough to pass Google interview on the spot? Were you a fresh grad?
Absolutely. As long as there are rules (cramming algorithms) I will practice the hell out and beat you (Google, FB, Amazon,MS) at your own game while playing by the rules. That's my attitude.
It matters to us, because we are a very small studio where teams are given a high degree of freedom. In our experience, lack of inquisitiveness or interest in the business is a good predictor for a bad fit. Also, I believe interviews should be a two way street, so I expect to be challenged by a candidate, because it's also up to them to decide if they want to work with us.
I do have to note that I mostly do the last interview rounds, after initial screenings and assignment (from home, no whiteboard coding), so I talk to candidates who have had plenty of exposure to things to ask follow-up questions about. Why should it not matter?
When interviewers ask you all sorts of minutiae that are outside of your experience and also not at all required for your job, and when those companies have extremely lucrative compensation and benefits package with "dream" work cultures (for most), not preparing for that interview puts you at a disadvantage for someone who has.
If you're trying for stretch roles that your experience doesn't cover for whatever reason, not preparing for those interviews will put you at a significant disadvantage.
Most interviews are set up to be an unnatural setting that is, unfortunately, often set to work against you. This is changing slowly, but it is what it is. Not having the skills to navigate that environment isn't bad per se but does worsen your position against someone who has.
An example: if I'm a Rails developer that wants to become a SRE at Google, and my current workplace is too small to give me the experience I need to coast through their notoriously tricky interview, what do I do? Do I take this author's advice and go in blind and wait for the beating that is about to come? Or do I learn what I need to learn to get through it, fail once or twice and iterate?
I would not be where I am today without having prepped for my interviews. I also won't ever ding someone for prepping for an interview. Quite the contrary, prepping shows that they care at least somewhat.
> Or do I learn what I need to learn to get through it, fail once or twice and iterate?
There's a difference between trying to _learn_ to get through and cramming as much "knowledge" as possible just to spit it out in the interview, and what usually happens is the second case, specially regarding algorithms.
> if I'm a Rails developer that wants to become a SRE at Google
Of course, you're probably not qualified for the position. Thus it's normal to have troubles in the interview.
This sort of transition used to be done by joining a "junior" position and getting trained on the job, without having to pretend to be a wizard.
Unfortunately it's hard to accept for one's ego that he has to continue as a not senior when changing fields, and it probably makes no sense on a financial perspective since an experienced ruby dev might earn more in his niche.
>But preparing for an interview by cramming/studying material that is supposedly needed for the job makes no sense. A candidate should have the experience to do the job well.
I think it is a good ideological stance. However, what about the scenario when you are applying for a junior position and don't have that much experience?
Moreover, as it has been demonstrated time and again, technical hiring is broken. Some folks like to talk about high-level concepts; some folks like to ask trivia and some others like to ask you to whiteboard the algorithms. If a company expects you to use a whiteboard and you are not used to it, you are not going to do well even if it is a topic you are familiar with (We don't realize how much we rely on editor/autocomplete).
I am happy that he was able to find another job without preparing, but this advice will not work for the majority of people.
>this advice will not work for the majority of people
That sums it up, the advice is good but since technical hiring is broken it doesn't work. This is why having a good interviewer is pivotal for a company. Someone who knows the company well and is good at reading people quickly and accurately
This was my first thought also. There are two issues here: One is: do you need to cram to prepare for the job? But the other is: does the interview measure your job preparation?
Most technical interviews don't. Even good ones that discern strong candidates often depend on knowledge and memorization way outside the actual job scope. (Often, way below the job scope. O(N) palindrome search is not a professional skill.)
So it's great to say that you should know what you need for the job, but conflating that with what you need for the interview is an unproven leap.
I think most devs would not be doing themselves a favor if they didn't "cram" before a Google / Amazon / Microsoft style interview, even if they are quite senior and very qualified to succeed in those companies. Assuming of course they want such a job.
Unfortunately I don't think interviews are a good tool for working out someones suitability.
Interviewers have so many biases and pet interests. If you happen start talking about something technical(Some side project using x technology) you both enjoy, you instantly get on, and its great.
If start talking about a side project the interviewer has no interest or knowledge in, not so great. It becomes hard work.
There is an element of luck about who is interviewing you.
For me, preparing for an interview for weeks (or maybe months, I've even heard of interview preparatory courses) by reading exam-like stuff that won't have any effect to your job but are interview preparation only is an insult to my personality. I would never do it and of course I don't want to work on companies that don't respect me. The most important perk for a job (for me) is to feel respected.
What world does this guy live in where he is being asked relevant questions to the stuff that he would be doing at work?
Sure, if we live in this fantasy world, where the person who passes the interview is by definition going to be good at the job, then his advice makes sense.
Unfortunately, the world we live in is one where you have to program algorithms on a whiteboard to get a job in web dev.
And for THAT world, it absolutely makes sense to study this material that you don't use in your job, but are being judged on.
There's a big difference between software development job interviews and job entrance exams that is often not evident on people who aren't deeply immersed in software culture.
Interviews happen in every industry. An interviewer asks about your interest in the company, your background, your leadership skills. Your technical skills may be investigated here, but in a discussion format. You may be asked questions about your knowledge of a database or perhaps a programming language, but you won't be tested specifically on that language.
Then there's the technical "interview" that is really an exam. Google's interview is a good example of this. You go up to a whiteboard, and the interviewer says "write a method to convert an integer to binary. Now add and subtract in binary. How would you square a binary number". You should be writing code on the white board, in either a real language or very tight pseudocode, to do this. Alternatively, the interviewer might ask you to find your way out of a maze, probably through some kind of graph traversal algorithm. Again, you really do need to write code that solves the problem.
This style of interview is indistinguishable from an exam. I think it exists because programmers don't have an actual exam in their field. It might be similar to asking a senior actuary to find the linear span of a vector space. There was almost certainly a time when the actuary could do this, since the actuary took an entrance exam on vector calc and linear algebra, but it isn't something a senior actuary most likely walks around ready to do. It would require re-studying.
As a few others have pointed out on this thread, there's a difference between studying for an exam and prepping for an interview. I've resolved not to do the latter anymore, but I really may simply not have that choice. The practice is deeply entrenched. But the former, of course I'd prep for an interview.
And also, you know, I actually think it's a good thing that lawyers take the bar, that actuaries take math exams. I don't think it's outrageous that people who hire programmers would want to know that these programmers have, at one time, passed an entrance exam on data structures and algorithms, binary operations, and so forth. The problem is that because we don't have such an exam in our field, we have to take a random and often unexpected version of it, under conditions of secrecy, with no feed back, evaluated by people who may not be qualified and who can be captious and arbitrary in their assessments.
I've had software engineering interviews that started with a written exam on general math, linear algebra, pseudocode and a little system design. It was quite enjoyable and refreshing compared to most verbal interviews.
I actually kind of enjoyed studying for and even taking my google exams. My day job often involves a lot of very intense and intricate work, but not necessarily fun concepts. I actually enjoy trying to figure out how to find all matching subtrees in a general tree, or all the permutations of a subset and whether they can be reassembled to enclose a different set, and how to do this efficiently. It actually is sorta fun.
Unfortunately, getting sharp enough at this where I can handle new questions like this in 45 minutes at a whiteboard was a bit much for me. I might be able to do it with several months of intense study. I was surprised with the amount of process they really do expect you to make at the whiteboard in 45 minute (the reason given for the no hire was that I analyzed problems well but just didn't make enough coding progress. who knows what that really means, they may have just been being nice).
Honestly, it may be a good filter. It shows that I either 1) am not quite sharp enough to get to this level within a couple of weeks, or 2) am unable or unwilling to invest the amount of time necessary to get myself to this level over a greater period of time (i.e., I have other life demands that prevent me from doing so, or am otherwise disinclined to do so).
That may give a tech employer some key information about my ability to devote myself to the job to the extent they would like.
The one time I crammed for an interview, it worked, but it was an unusual case. The job was to work with Peter Norvig at the search startup where he was chief scientist, back in the 90s. So the day before, I took his book AI: A Modern Approach and reread the chapters on natural language. An upcoming interview concentrates the mind, and I noticed several mistakes, including a bug in the pseudocode.
(They did offer the job, but for not enough money after I naively answered the salary history question. Oops.)
I always "prepare" for interviews, I learn about the company, what they do, their stack if it's public, etc. I don't bone up on my knowledge of programming or how to implement an N(x) sort or anything like that. If I don't know it then I don't know it and cramming to try and show off that yes I listened in my CS classes back in college seem disingenuous and misleading. I will succeed or fail on my own merits and I will not pretend I'm something I'm not. I know what I know and if that is not the person they need then it's better for both of us to walk away and look for something that better fits our needs.
people who depend on salary have to pretend to get the salary. if you can afford not to have job, then you can take more idealistic approach
imagine you have low savings and you support your wife and small child at home, can you afford to sit at home for months until you find good match without pretending and cramming when it obviously work for some companies?
But if you learnt how to implement quick sort before an interview and it proved useful in your interview, then you are succeeding on your merit. It's not like you are cheating during the interview. At the time of interview you do know how to implement the algorithm and that is your merit.
Cramming for an interview, especially in the early stages of one's career is actually a great advice that helps you grow your technical skills.
If you can learn over the weekend just enough about some technology to pass the interview , then, after you get accepted you'll have another month before you actually join (standard notice period)
After that month of learning and another month of "onboarding" in the new workplace no one would be able to tell the difference between you and someone that has 1 year of actual experience in the given technology.
"Fake it untill you make it" - that's how I got my first 3 or 4 jobs :)
> A candidate should have the experience to do the job well.
I feel like this is the least true statement in the article. A candidate should have the willingness and ability to learn the skills required to perform the job duties, and improve those skills over time. They should have some basic building block skills required in advance, like understanding how code languages work, and how to learn them, or how to communicate with teammates and get difficult questions answered. But experience is probably not what they need, unless only experience can build a specific skill (i.e. product/market vision based on intimate domain knowledge.)
I agree. Everyone who now has the experience to do the job well was once a novice who had the willingness to learn and put in the necessary effort to do any job well.
I tend to agree. The article resonated with my experiences for the most part, but some lines felt out of place, such as:
> Taking one of them would have set me back in my career since I would not have the skills I would have needed to do the job well.
There's a massive disparity in most jobs between experience demanded for, and (potential) experience on offer to be gained from, the particular role.
When I've sat on the recruiter side of the desk I've always been a bit wary about people who have a superset of the skills required for a job -- they're going to be very bored, very quickly. When I've sat on the other side of the desk I've had trouble verbalising, to the panel, the benefits of considering a candidate who has 70-90% of the skills or experience they're looking for.
>Cramming may get a candidate a job. But they won’t succeed at the job if they don’t have the skills and experience needed.
Nothing any of us can do about it. It would mean avoiding all mid size/larger tech companies. I am looking for a change, and I am preparing heavily. Algos, data structures, design stuff.
>Granted, all of this implies that companies have actually created an interview that actually tests the skills needed for the position they are hiring for.
I think he meant "assumes" not implies, but this is the crux. They test what they test, and if it possible to game it, people will do so.
Hi-scalability. That's all they seem to ask these days, "How would you design twitter?" etc.
The only other resource is questions from actual interviews that people put up. To be honest, I find it hard to prepare for this part too. Algos are easy, once you do crack the coding interview and a few online questions.
> But preparing for an interview by cramming/studying material that is supposedly needed for the job makes no sense.
Usually people prepare for job interviews by cramming sorting algorithms, balanced trees, answers to questions like "why are manhole covers round?", and similar things unrelated to job.
>Cramming may get a candidate a job. But they won’t succeed at the job if they don’t have the skills and experience needed.
This is a fallacy, you'll encounter things that you are not "qualified" to do on the job all the time, not to mention that if you are applying for an engineering job, or any other job that effectively requires you to solve problems; then learning new things, performing studies and research and finding a solution to the problem is your job description.
If the role is such that a candidate can have 100% of the experience and knowledge needed to perform that role during it's entire lifetime than that role is effectively the burger flipping of the tech world.
This role is also the easiest to automate since apparently all the answers and knowledge needed to fulfil are known.
That objection could be seen as compatible with the original thesis in the title, though. Equate the need to work with unexpected things on the job, with improvising a job interview. In both cases, you need to expand beyond your knowledge, but you also need a baseline of knowledge and ability to even get started.
At a job interview you're typically not allowed to use the web and also typically expected to answer a question within seconds instead of within days, so the environment is very different from working with unexpected things on the job. You could design an interview process where neither of these were true, but I think it's pretty hard and comes with its own downsides.
I have done live coding exercises with candidates, allowing them to use the web, etc. This is actually even more enlightening... you should see some of the things people google, copy-and-paste, etc.
Using a mountain or pile of stuff as a metaphor (and ignoring its potential lopsidedness for now): At the base, you've got some knowledge that might be kind of dusty, but that you can reacquaint yourself with quickly. Then you've got a mass of experience, layered on top of that knowledge, that further colors how you'll approach problems, the solutions you'll choose, etc. You can reach further from there by doing a little research, and put another layer of experience on the pile you already have.
If the job doesn't require any reach, it's "burger flipping". If the job requires more reach than you can get, even from the top of your experience-pile, and building the pile up to extend your reach enough to achieve the goal will take more time than you have, then you're unqualified for the job. So, you want something in the happy middle: not trivial for you, but not out of your grasp.
Your reach should be small, compared to your experience, unless you're just starting out.
The author makes the implicit assumption that success in a software interview means success in the workplace, and vice versa. This may be true for some interview processes, but this idea can't be generalized across the industry.
The author is giving way too much credit to the interview process and way undermining his abilities. Interviewers are humans just like the interviewee and the process can be (and is in fact) screwed up. Interview performance has little correlation with actual job performance. You do whatever you have to do get in the door and learn new skills on the job. He is missing out on some great opportunities (and most likely salary) by having this attitude.
There is an important caveat in the last paragraph of the article:
"Granted, all of this implies that companies have actually created an interview that actually tests the skills needed for the position they are hiring for."
Yes, and I am surprised that this wasn't at the start of the article instead. Very few companies have interview processes that test for the actual skills required on the job. Certainly not any of the big 4.
I agree, some years ago I prepared for a month for a Google SWE interview and still failed. I haven't prepared for interviews since, nor asked to write code. Last time I interviewed at Google for a SRE-TPM position I was asked Python trivia during the phone screen, which left quite a bad taste in my mouth.
[Shameless plug, feel free to skip] However, if you do want to prepare for a Google-style interview, I maintain a list of resources here: https://github.com/andreis/interview
I held a similar attitude through college. An exam exists to test my knowledge and abilities, give me a solid idea of what I learned and where my deficits lay. It is not a test of short-term memory. If I didn't learn the material good enough the first time, then it was a waste of my efforts to cram for today.
Likewise with the interview. Sure, I look into the company, the requirements. If they use libraries that I am unfamiliar with, I will review the documentation so I have a general idea of what it does and how I can map my existing skills against those libraries. But I can't become an expert in that short of a time, and I wouldn't purport to be one in the interview either.
I have yet to do an interview that asked me to white board. I've been asked to solve some fairly basic problems (of the fubar variety). But then again, I've never applied to a business that was large enough that my resume and interview wasn't handled by my future direct supervisor. I've no interest in jumping through the hoops of a large bureaucratic corporation.
Honestly, the best route IMO is to actually maintain an open-source portfolio of work. This obviously isn't feasible or possible for everybody, but if you can contribute to OSS, doing so is easily the best way continuously test your mettle and prove to your future employers, partners, and the general community that you're someone they want to (or don't want to) work with.
The true value of the face-to-face interview really should be getting a feel for the person - is this person someone I want to work with? Or will this person make me want to kill myself whenever I step into the office? - not to gauge technical prowess or whiteboard prove-you-are-smart-and-took-an-algo-class-in-college challenges
If you have to whiteboard code, I would strongly advise practicing. It's pretty loosely related to your day to day workflow, but some places are committed to it. You can get burned with a false negative just because you're not familiar with the paradigm.
It's like the SAT. You can't study but you can absolutely practice, and practice will improve your score.
But if you gotta spend time doing anything job hunting, spend time talking to people in your network.
82 comments
[ 77.1 ms ] story [ 1985 ms ] threadWhen I get a candidate who has no sense of the job they are applying for and is not able to ask meaningful questions, it tells me they don't care or don't understand.
If you are completely unqualified for the job, you will be found out, but if the difference in skill/experience is small enough, it's probably best to be honest about the gap. In that case, "studying up" may be a risky investment of your time, but at best it may show your commitment and at worst you will have picked up some new skills :)
They will even give you a study guide!
Being really good at programming on a whiteboard is the name of the game. And studying for this is absolutely useful, and not "cheating" because everyone does it and is expected to do it.
When I say "program on a whiteboard", I am mostly talking about the google style algorithms questions.
The way to practice for those is to just do a whole bunch of them, and talk to yourself, like you are in an interview.
It is just CS 201 material. All the material is out there for anybody to study.
The best materials are Cracking the Code interview, as well as the Google University github page.
There are also free resources out there for doing real life practice interviews, and pairing you up with people who do that.
Preparing for the Google Style interview is a whole entire industry.
They've got the most common algorithm questions asked at the various Big Tech companies.
Go through them, and learn to solve/implemented at least 250 of their problems, and you'll be able to able to breeze through most algo interviews.
I don't see how this process is useful to the candidate. I mean it is useful if he is actually hired but is there any other usefulness beyond this? Does it improve your skill? Makes you a better person? Is it fun? I don't think so.
Also refer to my other comment.
I sharpend my skills and learned new stuff.
The other day, I read a rant about an algorithms interview question at some big company (it might have been Google, but I'm not sure and it doesn't matter). Essentially the rant was that the candidate had been asked to implement an obscure version of some widely known and well described function that has O(n) time where all the standard and widely studied and likely to be crammed versions have O(n log n) time -- more or less the question was based on an algorithm of the sort that probably appears in a research journal or conference proceedings and no where else. Essentially, the question was uncrammable.
That's what makes it a great interview question. It identifies true genius when the candidate can figure it out on the fly. It identifies ordinary engineering talent when the candidate starts with what they know [an O(n log n) solution] and reasons from there (and perhaps asks for help!] and it identifies people candidates who are applying at Google because it is Google and not because they enjoy challenging problems.
Except they filter those who "doesn't do algorithms" for free (the prep/cramming takes about 6 months I believe)...
And finally, it would be fascinating to plot career performance at Google vs time spent interviewing. Intuitively I would expect those who got an offer without studying to do better (higher latent intelligence), but I could also see it going the other way (lots of studying correlates with willingness to work hard on boring problems, which is what most Google engineers actually have to do day-to-day).
Other people do though.
Perhaps you are one of those people who could just walk in and Ace the final exam for an intermediate data structures and algorithms class taught at colleges.
Why does this matter?
I do have to note that I mostly do the last interview rounds, after initial screenings and assignment (from home, no whiteboard coding), so I talk to candidates who have had plenty of exposure to things to ask follow-up questions about. Why should it not matter?
When interviewers ask you all sorts of minutiae that are outside of your experience and also not at all required for your job, and when those companies have extremely lucrative compensation and benefits package with "dream" work cultures (for most), not preparing for that interview puts you at a disadvantage for someone who has.
If you're trying for stretch roles that your experience doesn't cover for whatever reason, not preparing for those interviews will put you at a significant disadvantage.
Most interviews are set up to be an unnatural setting that is, unfortunately, often set to work against you. This is changing slowly, but it is what it is. Not having the skills to navigate that environment isn't bad per se but does worsen your position against someone who has.
An example: if I'm a Rails developer that wants to become a SRE at Google, and my current workplace is too small to give me the experience I need to coast through their notoriously tricky interview, what do I do? Do I take this author's advice and go in blind and wait for the beating that is about to come? Or do I learn what I need to learn to get through it, fail once or twice and iterate?
I would not be where I am today without having prepped for my interviews. I also won't ever ding someone for prepping for an interview. Quite the contrary, prepping shows that they care at least somewhat.
There's a difference between trying to _learn_ to get through and cramming as much "knowledge" as possible just to spit it out in the interview, and what usually happens is the second case, specially regarding algorithms.
Of course, you're probably not qualified for the position. Thus it's normal to have troubles in the interview.
This sort of transition used to be done by joining a "junior" position and getting trained on the job, without having to pretend to be a wizard.
Unfortunately it's hard to accept for one's ego that he has to continue as a not senior when changing fields, and it probably makes no sense on a financial perspective since an experienced ruby dev might earn more in his niche.
>But preparing for an interview by cramming/studying material that is supposedly needed for the job makes no sense. A candidate should have the experience to do the job well.
I think it is a good ideological stance. However, what about the scenario when you are applying for a junior position and don't have that much experience?
Moreover, as it has been demonstrated time and again, technical hiring is broken. Some folks like to talk about high-level concepts; some folks like to ask trivia and some others like to ask you to whiteboard the algorithms. If a company expects you to use a whiteboard and you are not used to it, you are not going to do well even if it is a topic you are familiar with (We don't realize how much we rely on editor/autocomplete).
I am happy that he was able to find another job without preparing, but this advice will not work for the majority of people.
>this advice will not work for the majority of people
That sums it up, the advice is good but since technical hiring is broken it doesn't work. This is why having a good interviewer is pivotal for a company. Someone who knows the company well and is good at reading people quickly and accurately
This was my first thought also. There are two issues here: One is: do you need to cram to prepare for the job? But the other is: does the interview measure your job preparation?
Most technical interviews don't. Even good ones that discern strong candidates often depend on knowledge and memorization way outside the actual job scope. (Often, way below the job scope. O(N) palindrome search is not a professional skill.)
So it's great to say that you should know what you need for the job, but conflating that with what you need for the interview is an unproven leap.
Interviewers have so many biases and pet interests. If you happen start talking about something technical(Some side project using x technology) you both enjoy, you instantly get on, and its great.
If start talking about a side project the interviewer has no interest or knowledge in, not so great. It becomes hard work.
There is an element of luck about who is interviewing you.
Sure, if we live in this fantasy world, where the person who passes the interview is by definition going to be good at the job, then his advice makes sense.
Unfortunately, the world we live in is one where you have to program algorithms on a whiteboard to get a job in web dev.
And for THAT world, it absolutely makes sense to study this material that you don't use in your job, but are being judged on.
Interviews happen in every industry. An interviewer asks about your interest in the company, your background, your leadership skills. Your technical skills may be investigated here, but in a discussion format. You may be asked questions about your knowledge of a database or perhaps a programming language, but you won't be tested specifically on that language.
Then there's the technical "interview" that is really an exam. Google's interview is a good example of this. You go up to a whiteboard, and the interviewer says "write a method to convert an integer to binary. Now add and subtract in binary. How would you square a binary number". You should be writing code on the white board, in either a real language or very tight pseudocode, to do this. Alternatively, the interviewer might ask you to find your way out of a maze, probably through some kind of graph traversal algorithm. Again, you really do need to write code that solves the problem.
This style of interview is indistinguishable from an exam. I think it exists because programmers don't have an actual exam in their field. It might be similar to asking a senior actuary to find the linear span of a vector space. There was almost certainly a time when the actuary could do this, since the actuary took an entrance exam on vector calc and linear algebra, but it isn't something a senior actuary most likely walks around ready to do. It would require re-studying.
As a few others have pointed out on this thread, there's a difference between studying for an exam and prepping for an interview. I've resolved not to do the latter anymore, but I really may simply not have that choice. The practice is deeply entrenched. But the former, of course I'd prep for an interview.
And also, you know, I actually think it's a good thing that lawyers take the bar, that actuaries take math exams. I don't think it's outrageous that people who hire programmers would want to know that these programmers have, at one time, passed an entrance exam on data structures and algorithms, binary operations, and so forth. The problem is that because we don't have such an exam in our field, we have to take a random and often unexpected version of it, under conditions of secrecy, with no feed back, evaluated by people who may not be qualified and who can be captious and arbitrary in their assessments.
I actually kind of enjoyed studying for and even taking my google exams. My day job often involves a lot of very intense and intricate work, but not necessarily fun concepts. I actually enjoy trying to figure out how to find all matching subtrees in a general tree, or all the permutations of a subset and whether they can be reassembled to enclose a different set, and how to do this efficiently. It actually is sorta fun.
Unfortunately, getting sharp enough at this where I can handle new questions like this in 45 minutes at a whiteboard was a bit much for me. I might be able to do it with several months of intense study. I was surprised with the amount of process they really do expect you to make at the whiteboard in 45 minute (the reason given for the no hire was that I analyzed problems well but just didn't make enough coding progress. who knows what that really means, they may have just been being nice).
Honestly, it may be a good filter. It shows that I either 1) am not quite sharp enough to get to this level within a couple of weeks, or 2) am unable or unwilling to invest the amount of time necessary to get myself to this level over a greater period of time (i.e., I have other life demands that prevent me from doing so, or am otherwise disinclined to do so).
That may give a tech employer some key information about my ability to devote myself to the job to the extent they would like.
(They did offer the job, but for not enough money after I naively answered the salary history question. Oops.)
imagine you have low savings and you support your wife and small child at home, can you afford to sit at home for months until you find good match without pretending and cramming when it obviously work for some companies?
If you can learn over the weekend just enough about some technology to pass the interview , then, after you get accepted you'll have another month before you actually join (standard notice period)
After that month of learning and another month of "onboarding" in the new workplace no one would be able to tell the difference between you and someone that has 1 year of actual experience in the given technology.
"Fake it untill you make it" - that's how I got my first 3 or 4 jobs :)
I feel like this is the least true statement in the article. A candidate should have the willingness and ability to learn the skills required to perform the job duties, and improve those skills over time. They should have some basic building block skills required in advance, like understanding how code languages work, and how to learn them, or how to communicate with teammates and get difficult questions answered. But experience is probably not what they need, unless only experience can build a specific skill (i.e. product/market vision based on intimate domain knowledge.)
> Taking one of them would have set me back in my career since I would not have the skills I would have needed to do the job well.
There's a massive disparity in most jobs between experience demanded for, and (potential) experience on offer to be gained from, the particular role.
When I've sat on the recruiter side of the desk I've always been a bit wary about people who have a superset of the skills required for a job -- they're going to be very bored, very quickly. When I've sat on the other side of the desk I've had trouble verbalising, to the panel, the benefits of considering a candidate who has 70-90% of the skills or experience they're looking for.
Nothing any of us can do about it. It would mean avoiding all mid size/larger tech companies. I am looking for a change, and I am preparing heavily. Algos, data structures, design stuff.
>Granted, all of this implies that companies have actually created an interview that actually tests the skills needed for the position they are hiring for.
I think he meant "assumes" not implies, but this is the crux. They test what they test, and if it possible to game it, people will do so.
The only other resource is questions from actual interviews that people put up. To be honest, I find it hard to prepare for this part too. Algos are easy, once you do crack the coding interview and a few online questions.
Usually people prepare for job interviews by cramming sorting algorithms, balanced trees, answers to questions like "why are manhole covers round?", and similar things unrelated to job.
This is a fallacy, you'll encounter things that you are not "qualified" to do on the job all the time, not to mention that if you are applying for an engineering job, or any other job that effectively requires you to solve problems; then learning new things, performing studies and research and finding a solution to the problem is your job description.
If the role is such that a candidate can have 100% of the experience and knowledge needed to perform that role during it's entire lifetime than that role is effectively the burger flipping of the tech world. This role is also the easiest to automate since apparently all the answers and knowledge needed to fulfil are known.
If the job doesn't require any reach, it's "burger flipping". If the job requires more reach than you can get, even from the top of your experience-pile, and building the pile up to extend your reach enough to achieve the goal will take more time than you have, then you're unqualified for the job. So, you want something in the happy middle: not trivial for you, but not out of your grasp.
Your reach should be small, compared to your experience, unless you're just starting out.
"Granted, all of this implies that companies have actually created an interview that actually tests the skills needed for the position they are hiring for."
It's an advantage is you want to self-select out of code-monkey work. Like if you want to be an "architect" or "strategist"
[Shameless plug, feel free to skip] However, if you do want to prepare for a Google-style interview, I maintain a list of resources here: https://github.com/andreis/interview
Likewise with the interview. Sure, I look into the company, the requirements. If they use libraries that I am unfamiliar with, I will review the documentation so I have a general idea of what it does and how I can map my existing skills against those libraries. But I can't become an expert in that short of a time, and I wouldn't purport to be one in the interview either.
I have yet to do an interview that asked me to white board. I've been asked to solve some fairly basic problems (of the fubar variety). But then again, I've never applied to a business that was large enough that my resume and interview wasn't handled by my future direct supervisor. I've no interest in jumping through the hoops of a large bureaucratic corporation.
The true value of the face-to-face interview really should be getting a feel for the person - is this person someone I want to work with? Or will this person make me want to kill myself whenever I step into the office? - not to gauge technical prowess or whiteboard prove-you-are-smart-and-took-an-algo-class-in-college challenges
It's like the SAT. You can't study but you can absolutely practice, and practice will improve your score.
But if you gotta spend time doing anything job hunting, spend time talking to people in your network.
I did make it to an in-person at Google. I failed the interview. The recruiter did encourage me to prepare, though.