Live data from Hacker News

Fixing impostor syndrome in coding interviews

interviewcake.com

21–30 of 84 posts

Re: Fixing impostor syndrome in coding interviews

#21
post #17

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.

Re: Fixing impostor syndrome in coding interviews

#22
post #18

Earlier quoted context omitted.

^ 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…

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.

Re: Fixing impostor syndrome in coding interviews

#23
post #4

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?

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.

Re: Fixing impostor syndrome in coding interviews

#24
post #3

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.

Re: Fixing impostor syndrome in coding interviews

#25
post #11

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

Re: Fixing impostor syndrome in coding interviews

#26
post #17

Earlier quoted context omitted.

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.

Re: Fixing impostor syndrome in coding interviews

#27
post #11

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.

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

Re: Fixing impostor syndrome in coding interviews

#28
post #11

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.

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.

Re: Fixing impostor syndrome in coding interviews

#29
post #18

Earlier quoted context omitted.

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…

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 d…

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

Re: Fixing impostor syndrome in coding interviews

#30
post #15
post #4

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?

> 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 wi…

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.
Post reply on HN