Hacker News new | comments | show | ask | jobs | submit login
Fixing impostor syndrome in coding interviews (interviewcake.com)
47 points by cmuir 7 months ago | hide | past | web | favorite | 82 comments



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 agree that many coding interviews don't test on-the-job skills. But pressure-cooker situations do happen on the job, e.g. production outages, major customers being affected by bugs and threatening to cancel, etc. It's not unrealistic to say that people who can't deal with that are unsuitable for many engineering positions.


Well fair enough but I don't see the two qualities as being all that related.

"Oh my god, production is down! Quick, someone tell me, from memory, the solution to the N Queens problem!!"


"Production is down. Let's put our heads together to fix the problem!"

vs

(raspy voice) "Wanna play a game? You have 45 minutes to parse this html in assembly using only half a keyboard. Otherwise... you will not be able to feed your family. From us, at least."

I would absolutely watch SAW: The Software Interview


> (raspy voice) "Wanna play a game? You have 45 minutes to parse this html in assembly using only half a keyboard. Otherwise... you will not be able to feed your family. From us, at least."

Don't forget about interrupting the candidate every 5 minutes to ask about the color of a blue moon, effectively preventing him to "get in the zone".


And if production is down, and you're the one under the most pressure, it's probably because you're the one who knows "production" the best.


What tech company do I sign up for to get an interview like the one in Swordfish?


That kind of pressure isn't the same as interview pressure.

I've been in whiteboard coding interviews and in situations where "production is down" and they are very different kinds of pressure and expectations.


I agree. I handle work pressure well enough, but social anxiety is a completely different animal.


I'd call it performance anxiety / pressure vs work pressure.


"Pressure cooker situations" are different than being asked to be an expert in IGBT transformer, have state of the art metallurgy knowledges, and have the flexibility of an olympic gymnast... for a welder position.


What questions are asked that are as divorced from being a software dev as olympic level flexibility is from being a welder? Or is this just a straw man argument?


Having a front end web developer/designer implement a b-tree from memory for example.


A b-tree or a binary tree? A b-tree doesn't even sound believable, unless there's other info you're not telling us.


I have been asked to write a matrix search robot (Ideal solution using A* algorithm) for a company that was doing CRUD education software apps, in which I was applying for a full stack position with plenty of experience building prod apps in their stack. I just looked them up and they shuttered about 12 months after the interview.


So what happened with the b-tree??



Pressure cooker situations absolutely happen on the job, when you are on the same team and the goals are the same - completely different situation than sitting in a room, alone, across from a panel of people evaluating you personally and professionally. I thrive in the former as anyone I've ever worked with can tell you, and break down in the latter.


This is why I tend to interview the candidate in things related to their past jobs. Sometimes they come from an different industry than what our company was involved in.


What would you do instead? Everybody knows interviews don't work that well but nobody has any better ideas.


1) give a 3 day coding challenge to gauge the candidate real potential, and 2) hire fast, fire fast.


I’m barely willing to take an online coding test for one job when I know historically for me, if I get submitted for 10 jobs by a recruiter, I’m likely to get three offers, take myself out of the running for 6, and only have one company that’s not interested. Why would I ever spend three days on a coding challenge.

And I’m a good test taker and interviewer.


Yeah, hour-long coding challenges and taking a day or two off of work are bad enough.


we're probably not at the same pay-grade / level of specialization.


Who's going to consent to doing three _days_ of work?


Most of the candidate of my past job who passed the initial non-technical interview with my former manager, over 2 years, that was probably a dozen people, leading to 3 hires.


Personally I think being willing to do such a thing is a sign of desperation.


On the other side, it saved us from bad hires that would have been difficult to fire otherwise.


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.


It's the reason I like HN so much. There is without fail someone who's been in that industry for a while. On reddit comments like those are rare and often gilded, then make their way over to r/DepthHub, but here I can almost expect them. It's great.


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.


Questions are often under specified for exactly this reason: to test ability to ask questions when necessary.

Even if the problem is fully specified, asking clarifying questions is considered a good signal in any interview I've ever conducted.


> Questions are often under specified for exactly this reason: to test ability to ask questions when necessary.

Unless you deviate from the script the [incompetent] interviewer expect, in which case, you are toasted.


If you can't make yourself understood to the average engineer at a company, I think it's fair to say there's not a good fit between you and the company.


s/engineers/managers/... Who probably ended up there to limit their collateral damage to the company, ie. followed the Peter principle.


I'd say that if you're in a technical interview with a non-technical manager, you may've chosen the wrong company to interview with. And if it's a non-technical portion of the interview and you have trouble making yourself understood (to a manager), you're back to the "it's not a good fit" conclusion.


It was definitively the "technical interview with a non-technical manager", and yes, I do agree with you, but it's difficult to judge companies beforehand.


Fair enough; unfortunate that they put you in that situation.


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!


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.


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.

When I took Comp Sci, you received some very general, broadly applicable tools. What I'd expect from my Comp Sci classmates, would be looking at such a problem for a couple of seconds, then they'd say, ok, you can do [X]. We were educated with a toolset that allowed us to do that. If you are thinking of it in terms of cycle detection being a particular specific obscure thing that you'd never have to do, let me say this. 1) If you think of it like that, and you further tell me that it would take you a couple of days, then that immediately tells me you don't have a particular, very broadly applicable toolset. 2) There are contexts where you have to do the kind of systemic thinking where cycles are something you have to account for.

There have been fields where knowledge has been lost. The British Navy figured out how to stop scurvy, then lost the ability to do so. The Japanese figured out how to stop the beri-beri deficiency disease, then failed to propagate the knowledge. I am starting to wonder if academia in the Bay Area and California can effectively compete with startups and big tech companies for Comp Sci expertise commensurate with teaching. Maybe only the very top institutions can do this?


I don't think graph theory is in any danger of being lost. That seems overly dramatic.

Since people can learn from each other, it's hard to say what people really need to know the day they join the team.


I don't think graph theory is in any danger of being lost. That seems overly dramatic.

The Brits and Japanese had no idea of the underlying mechanisms, and our society has the underlying comp sci knowledge in our case, archived in libraries. If an entire generation of computer science grads just fluffs graph theory, it's not like the knowledge will be lost, but it's definitely not a good thing. It's definitely a step in the wrong direction.

However, it was not graph theory which was lost. It's a body of engineering knowledge for how to do applied graph theory; how to recognize you have to deal with graph theory, then quickly clobber the problem with several broadly applicable tools. Why isn't this being passed down from one generation of profs and TAs to the next?

Since people can learn from each other, it's hard to say what people really need to know the day they join the team.

It's one thing to know a high level overview about something, then to be able to go and bone up on a specific area. It's another thing if someone doesn't know enough to recognize the thing without prompting and clearly has no practice solving problems of that general category, whatsoever.

EDIT: Isn't anyone curious about what these tools are?


> EDIT: Isn't anyone curious about what these tools are?

Um, Not when you are making readers feel incompetent for not having them.


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.


Just like becoming aware that my parents weren't little gods, I had the same type of enlightenment with professors and other professionals. I'd put them up on a pedestal for a long time without taking account of my own expertise. It took a good while of them asking me questions before I realized they weren't teasing me for my education but asking because they legitimately 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.


But the problem is lots of people can talk a great game but then turn out not to be able to do the code thing.


"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...


Came here to say the same. Centering an image is much harder than it should be, pre-flexbox.


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?


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


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.


Would you care to elaborate? I'm not familiar with the process.


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.


Yikes. That stinks.


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?


I never understood why people act like interviewing is an innate talent and not a learned skill like everything else.


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


^ This happens too too often :/


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.


On the other hand, someone with more knowledge accessible off the top of their head is more able to find and assimilate new information too.


Thats not the case. Being good at trivia doesn't mean you're able to concentrate enough to synthesize solutions using the knowledge you have.


That doesn't seem to be true. https://www.aft.org/sites/default/files/periodicals/LookItUp...

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


That is really quite interesting! Thanks for sharing.


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.


I don't think the question of whether it is a profession really ties that well into the rest of what you have said.


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.


Or even just you haven't touched it in a while.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: