
Fixing impostor syndrome in coding interviews - cmuir
https://www.interviewcake.com/impostor-syndrome-in-programming-interviews
======
taurath
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.

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

~~~
sho
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!!"

~~~
Humdeee
"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

~~~
alacombe
> (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".

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

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

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

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

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

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

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

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

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

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

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

------
stcredzero
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!

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

~~~
stcredzero
_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?

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

~~~
stcredzero
_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?

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

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

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

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

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

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

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

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

------
afpx
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?

~~~
make3
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

