Why do people study for interviews? I feel like if I have to study for an interview, then I’m clearly not good enough for the position. Is this common in other fields of study?
If you do something, whatever it is, you might as well put an effort to do it well.
In this case it means studying. If you don’t want to, state it upfront.
And the comments:
It is highly unlikely that you already know, or god forbid, remember, everything you need to know in order to be a productive contributor to the task at hand.
It is also highly unlikely that the technical interview is correlated, even remotely, with the task at hand.
You study and perform given the above.
If the employer likes your effort, attitude and skill, they’ll hire you.
If they don’t, the problem solved itself. You did your best and they are not a good match for you.
I study because of the "have to know everything" aspect of tech interviews. I rather be prepared and review/practice something I never use just in case it comes up. Might find myself reviewing JSTL because I used JSPs in 2008 for instance. Problem is the more senior I get and the more languages/frameworks I add to my toolbox the larger the scope becomes.
I wouldn't study, at least not in the way that a student would cram for a test. However, I think it is helpful to focus on potential interview questions (especially having anecdotes for non-technical "tell me a time when..." sorts of questions), mentally rehearsing how the interview might play out, deciding what to focus on...
IMHO, the biggest challenge is to decide what aspects of oneself to focus on. Depending on the context, I could present myself as a technical know-it-all, a process-oriented team-builder, a collaborative problem-solver, an engineer focused on delivering business value, or something else. All of these (I hope) would be accurate representations of myself, albeit incomplete by themselves. Since I don't have the time to showcase all of these facets of myself, I pick and choose based on what I think the organization's interview process is selecting for.
Though I was recently rejected after an all-day onsite interview, so maybe I'm taking the wrong approach; or perhaps I misread the company's hiring objectives; or maybe it wasn't the right fit.
BTW, I hate trivia-style tech interviews, and would be hesitant to work for any company that utilizes them—not because I wouldn't want to go through the process personally (I actually kind-of enjoy them), but because they're optimizing for a set of skills that is very much out of line with the requirements of 99% of software development teams. Our industry needs more wholistic thinkers; most of us face many more people challenges than technical ones.
In software, it's full of the bullshit "Cracking the Coding Interview" types of questions that have very little to do with the actual job. You must study for these because you won't really learn about them in your job as they don't really have anything to do with the actual job, and still have a very high impact on wether you'll get hired at top places or not
> I have to study for an interview, then I’m clearly not good enough for the position.
that is true only to the extent that the interview is related to the position... Whereis most interviews in our industry are akin to a hazing ritual, and it stands for a reason that "Google interview" got it name from that and is also religiously practiced in the other frat-companies like for example FB or stereotypical startups with young founders.
Wrt. the ritual aspect it is thus natural that at Google/FB you first have to pass the interview and only after that you are getting to the project assignment stage ( not sure about specific details at FB as i failed there, while at Google the offered projects were pretty crappy (as well as the offer itself))
The way Google does project assignment after a lengthy interview process strikes me as a bait-and-switch. Feels like they're hoping you've invested so much time in the process that you won't turn down a role you would have never applied to in the first place.
You interview to get into Google at a specific level (new grad, SWE III, etc). They don't reveal which project you will be working on until the offer stage though. So it's possible that you can be in the interview process for months only to find out you'll be working on some kind of old legacy maintenance role.
Interviewing is a different skillset than most development positions ever use; you can be a good developer but a terrible interviewer. You'd be great at the job, but you get rejected in favor of someone else that put some more practice into skills that are applicable to interviewing (i.e. whiteboard programming, working without reference material, etc).
You go into the interview, having not studied. Your twin studied and ended up being more impressive during the interview. Out of the two of you, who will get the job?
And it's ridiculous IMO. Any interview question that can be answered completely with 20 seconds of googling is useless. I've encountered a couple of these "obscure programming trivia" type questions before and each time I wanted to quiz the interviewer back with random shit I happen to know pretty well that I'm 100% certain he or she couldn't answer either.
A good developer doesn't optimise for a specific problem or even group of problems, they optimise for the meta-problem, which is how to quickly find the solution they need no matter what the problem happens to be. No-one can possibly know everything, and these gotcha-type questions say more about the interviewer than the interviewee.
It wasn't really 'trivia'. It was several hours of difficult problem solving without reference material, given access only to a whiteboard and a judge.
The studying that would have led to a success:
* Memorizing a significant amount of the interview's programming language. Since there is no reference material, you really need to know it. No standard library reference to help you out.
* Solving enough algorithms and data structures problems to be able to minimize the time needed to identify and implement them. There is a time constraint, so blanking out or slowly deriving them is a recipe for rejection.
I'm doing both of the above, and I know I'll have success this time around, but it was jarring the first time.
Honestly, I'm OK with this now, because I am good at studying and learning. I just wasn't expecting it initially, because I wasn't going in for a position at Google or something. The company advertised the position as needing much less experience than that. So I was really surprised (and under-prepared) when I was given the whole day coding interview process.
> It wasn't really 'trivia'. It was several hours of difficult problem solving without reference material, given access only to a whiteboard and a judge
Even more irrelevant with today's access to Google, StackOverflow and alike. I've done my share of learning by heart pages of demonstration for some obscure quantum physic model, puking it the day of the test, and then forgetting about it. It the company is looking for an obedient monkey, well, I'll pass.
> Honestly, I'm OK with this now, because I am good at studying and learning.
But are you any good at analyzing a combination of problems never encountered before ?
> But are you any good at analyzing a combination of problems never encountered before ?
Haven't won a Nobel Prize yet, otherwise most work is done by first examining what I know vs. what I don't, and then using the appropriate tools (search, reference -> think -> implement/test -> discuss, as necessary) to accomplish the next steps.
Regardless of what I think and what I know, or even of my abilities to solve novel problems, the industry has decided upon its entrance exams.
Many times the problems vary on the surface, but the core concepts do not, and so the iterations and combinations thereof are solvable by polling previously encountered experience (study & practice).
The way to solve a problem you've not encountered is usually to break it up into smaller problems you do know how to solve, and it's easy to see how some rote learning could help here.
OK, agreed that's not the trivia I was talking about. Although honestly it sounds like you dodged a bullet, if anything your experience is even more ridiculous. Does this company make a habit of writing programs on whiteboards without any references?
It, uh, probably does help to know the language you're being interviewed for, although a good programmer in any language can almost certainly start being productive in another one within a month. A good hiring process knows this, too.
There's knowing a programming language and where to look when you're unsure of the details, and there's knowing a programming language.
I could write programs in the target language on a computer, easily, but on a whiteboard I encountered a few halts where I would have used the reference docs. When I asked a doc reference question, I immediately could tell from facial expression alone that my interviewer was docking me points.
Was that experience ridiculous? I know it changed my willingness to interview more until I've mastered more material. I'm not going to burn time and money to be grilled for several hours and not be able to nail it.
I'm employed full time but it's time for advancement, so I've been studying a lot.
> For instance, there is a domain of cognitive science
called “expert-novice studies.” Two of its leading figures
are Herbert A. Simon, the Nobel Prize winner, and Jill
Larkin, who has co-authored articles on this subject with
Simon. Their studies provide an insight into the paradox
that you can successfully look something up only if you already know quite a lot about the subject. In these studies, an expert is characteristically a specialist who knows a lot about a field—say a chess master or a physicist, whereas a novice knows very little. Because the expert already knows a great deal, you might suppose that she would
learn very little when she looked something up. By contrast,
you might think that the novice, who has so much to
learn, ought to gain a still greater quantity of new information from consulting a dictionary or encyclopedia or the Internet. But, on the contrary, it’s the expert who learns more that is new, and learns it much faster than the
novice. It’s extremely hard for a novice to learn very much
in a reasonable time by looking things up.
The linked paper is interesting and elaborates this phenomenon a lot more than the one quote.
Sometimes its necessary to learn more of a board sense of something. Even if you've used it before.
For instance, we use Mongo DB at my place of work but, we do not take advantage of ALL the features Mongo has to offer at one time. If I were to interview at another company that also uses Mongo it might be to my benefit to dive a little deeper and look for features I may be unfamiliar with on a day to day basis.
If you do something, whatever it is, you might as well put an effort to do it well.
In this case it means studying. If you don’t want to, state it upfront.
And the comments:
It is highly unlikely that you already know, or god forbid, remember, everything you need to know in order to be a productive contributor to the task at hand.
It is also highly unlikely that the technical interview is correlated, even remotely, with the task at hand.
You study and perform given the above.
If the employer likes your effort, attitude and skill, they’ll hire you.
If they don’t, the problem solved itself. You did your best and they are not a good match for you.
Onwards.