Maybe the coding interviews which have nothing to do with the job are the problem. I'd say if you're going to be tested on something you don't actually do, for a job you are qualified for, it is rational to have imposter syndrome.

Also just to add - many REALLY good engineers have some form of anxiety disorder, and the standard practice for an interview is to put them in a pressure cooker situation.

I sometimes have a similar experience reading HN, where seemingly every question receives an expertly detailed answer, regardless of topic. I have to remind myself that it's a bunch of people, each with their own (probably small) set of areas of expertise.

It's often fun to read these "oh, I can say a lot about this" posts, though.

Regardless of whether you consider yourself an imposter, do ask clarifying questions! They are generally expected from candidates. If you're not asking them, you're probably hurting your chances.

Source: I interview lots of candidates for SWE positions.

Thanks for the post! Original author here. Happy to answer questions here. I love talking about coding interviews!

Sometimes impostor syndrome doesn't need to be fixed. I am beginning to think there's one UC system school which is afflicted by Teaching assistants who shouldn't themselves be able to pass a programming job interview.

I've pointed out to interviewees that user input in one problem can result in circular references. I point out, as a hint, that thing A can refer to thing B, then thing B can refer to thing A, and you'd wind up with an infinite looping execution in one part of the code. How can we detect this? So then these 3.8+ GPA Comp Sci grads tell me to write a conditional that detects a 2-element loop. Not an algorithm that can detect the cycle, but just a conditional that only detects the 2-element cycle. Then I have to ask, well what about a 3-element cycle? To the credit of most of the applicants, they then try to incoherently describe an algorithm involving some kind of hash table, but then never give anything which is implementable. Once, the applicant didn't yet realize there can be n-element cycles, then proceeded to literally handwave away all graph algorithms.

These same applicants usually have a hard time writing their own recursive algorithm. Would you want to trust your startup coding to people who don't habitually think at least one step ahead? Come on! These things used to be covered in the first algorithms class! This should be Freshman Year stuff!

I always find impostor syndrome interesting. When I was in grad school I was ignorant of a lot of things and didn't try to fool anyone. Same thing with job interviews. I figured that the profs and potential employers were the ones that knew things and there was no way I could fool them because I didn't even know what I didn't know.

I did an interview a while ago. I first had a 30 to 45 minute chat with the business owner. After that he called his tech-lead into the meeting who was going to ask me technical questions. He was going to do a white board thing, something with a linked list or something. I refused and asked him what the value on the whiteboard interview was. "To see me think". Why wasn't he present during the first 30 to 45 minutes when I talked about all my experience, he could have seen me think then.

I have interviewed quite a bit because I work as a contractor. Most companies I have interviewed with have no idea what to actually do during an interview. They just copy stuff that they have read about on the Internet. Oh, Google does puzzles, well...

Interviewing is broken.

"For me, it was seeing the back end code wizard on my team—the one that always made me feel like an impostor—spend an hour trying to center an image on a webpage." To be fair, before flexbox this was also true of front-end wizards...

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?

Depends what it is? Detecting a cycle is something I learned about a long time ago in a Lisp context, but haven't used. It's simple enough once you know it, but I doubt I could have come up with it on my own without thinking about it for a few days; certainly not on the fly.

For many front-end developers, I don't think graph algorithms matter. I suspect they don't matter for machine learning (though I know little about that field). Would you pass up knowledgeable people in these fields?

This is why you need multiple people to ask a lot of different questions and judge people by what they can do, not what they can't do. And try not to entirely forget about hindsight bias.

The answer:

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.

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 my own resume before an interview and be prepared to describe my past accomplishments in a distinct non rambling way.

There are some things I do in programming that are such habits that I have hard time explaining it.

If someone gave you an English test (assuming you are a native English speaker), and gave you a sentence to correct:

I love that antique green big wonderful car that is always parked at the end of the street.

It probably would sound wrong to you but could you explain why? (http://www.gingersoftware.com/content/grammar-rules/adjectiv...)

> 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))

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?

Initially I didn't study, then I failed to land a great job that I easily would have acquired with some dedicated studying.

For the same reason they dress nicely.

Software engineering isn't a profession, there's no standardised way of demonstrating to an employer that you have the requisite skills they want.

A CompSci degree/MSc/PhD is just a piece of paper that a lot of other people have.

Employment history is just a paragraph on your resume, that you could have embellished to make yourself look better.

This is why companies do these "Dr. House" style 4-6 hour, multi stage interviews, because they can't evaluate people in any other way.

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.

This can be applied to all tools and languages.