Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing impostor syndrome in coding interviews

interviewcake.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Fixing impostor syndrome in coding interviews

#61

Post by khedoros1 »

alacombe wrote: post #33
amarkov wrote: post #26

Earlier quoted context omitted.

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.

Re: Fixing impostor syndrome in coding interviews

#62

Post by skybrian »

stcredzero wrote: post #58
skybrian wrote: post #55

Earlier quoted context omitted.

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

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…

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.

Re: Fixing impostor syndrome in coding interviews

#63

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

Re: Fixing impostor syndrome in coding interviews

#64

Post by khedoros1 »

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

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?

Re: Fixing impostor syndrome in coding interviews

#65

Post by taurath »

emodendroket wrote: post #56
taurath wrote: post #52

Earlier quoted context omitted.

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

That is really quite interesting! Thanks for sharing.

Re: Fixing impostor syndrome in coding interviews

#66

Post by emodendroket »

pan69 wrote: post #63

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

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.

Re: Fixing impostor syndrome in coding interviews

#67

Post by stcredzero »

skybrian wrote: post #62
stcredzero wrote: post #58

Earlier quoted context omitted.

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…

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?

Re: Fixing impostor syndrome in coding interviews

#68

Post by alacombe »

emodendroket wrote: post #47
taurath wrote: 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.

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.

Re: Fixing impostor syndrome in coding interviews

#69

Post by taurath »

tytytytytytytyt wrote: post #59
taurath wrote: post #46

Earlier quoted context omitted.

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.

Re: Fixing impostor syndrome in coding interviews

#70

Post by alacombe »

khedoros1 wrote: post #61
alacombe wrote: post #33

Earlier quoted context omitted.

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