Live data from Hacker News

Fixing impostor syndrome in coding interviews

interviewcake.com

51–60 of 84 posts

Re: Fixing impostor syndrome in coding interviews

#51
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…

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.

Re: Fixing impostor syndrome in coding interviews

#52
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…

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.

Re: Fixing impostor syndrome in coding interviews

#53
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!

Re: Fixing impostor syndrome in coding interviews

#54

Earlier quoted context omitted.

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.

Re: Fixing impostor syndrome in coding interviews

#55

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

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.

Re: Fixing impostor syndrome in coding interviews

#56
post #52

Earlier quoted context omitted.

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.

Re: Fixing impostor syndrome in coding interviews

#57

Earlier quoted context omitted.

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.

Re: Fixing impostor syndrome in coding interviews

#58

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

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

Re: Fixing impostor syndrome in coding interviews

#59
post #46

Earlier quoted context omitted.

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.

Re: Fixing impostor syndrome in coding interviews

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

https://en.wikipedia.org/wiki/B-tree
Post reply on HN