[HN Gopher] Why coding interviews aren't all that bad
___________________________________________________________________
Why coding interviews aren't all that bad
Author : picture
Score : 18 points
Date : 2022-03-19 14:13 UTC (8 hours ago)
(HTM) web link (eli.thegreenplace.net)
(TXT) w3m dump (eli.thegreenplace.net)
| TrackerFF wrote:
| My only real problem with coding interviews is that you never
| know whether or not people lack knowledge, or if they're just
| folding under pressure. I've seen very competent people start to
| fumble, when they're being put on the spot - which in turn makes
| a bad first impression, for the people that have just met them.
|
| Some people are very good at whiteboard interviews, others at
| take-home exams.
| sokoloff wrote:
| If the folding under pressure is episodic/random, then those
| very competent people will likely make a correctly good
| impression in the next 1 or 2 interviews they attend and end up
| landing a job soon. From their perspective, it's still fine.
|
| From a company perspective, if you really can't tell whether
| they lack competence or just folded under pressure, you pretty
| much have to pass on them and try again with the next
| candidate.
| throwmeawaycs wrote:
| I personally implemented major APIs and libraries that are
| currently being used in deployment by over 25m+ systems with
| 99.999% uptime. When I get called into interviews and some
| guy starts trying to get me to implement or work on some
| random crap in some random IDE and doesn't want me to use a
| search engine to do so?
|
| Guess what, I just turn off the laptop and go hiking.
|
| For a year. And then after that year I'll try again. You're
| not playing the game you think you are.
| keskival wrote:
| Why would it be random? I have seen people describe this as
| related to performance anxiety, and maybe some part of it is
| that.
|
| I have myself come to conclusion that this is largely due to
| brain architecture. Notably the same part of the brain is
| responsible for coding as for speaking. Asking people to
| explain their thinking to an unknown person with unknown
| criteria takes a huge amount of brain capacity exactly from
| the parts of the brain one needs to program.
|
| Additionally, the normal way experienced programmers approach
| these types of problems is to utilize background processing
| in the brain. They first encounter the problem, then they aim
| to understand it well. Then they go take a coffee, or even
| sleep on it, while the brain is working in the background
| unconsciously, and then at some point an innovation comes
| almost unbidden. The coding interview set up doesn't measure
| this real problem solving capability in any way. This is why
| experienced people become stumped, because it is not the way
| they actually solve the problems in the real life, and they
| might not even be aware of why their brain seems to not work
| suddenly.
|
| This might even flare up their impostor syndrome which is a
| common professional hazard if they think they have failed in
| something they should have succeeded in. It is not only a bad
| way to interview and screen people, it is discriminatory and
| materially abusive.
| sokoloff wrote:
| I used "if" in the sense of "if (i < 95)..." It's not
| arguing that i _is always_ less than 95, just saying what
| the consequent is in the event that it is.
|
| For many people, it is episodic/random; performance is
| variable by day, hour, and situation.
| keskival wrote:
| The author exhibits huge confirmation bias in their example of an
| otherwise good applicant stumbling on a technical test. They
| assume without any doubt that this means they narrowly avoided a
| mishire.
|
| Testing for simple algorithms knowledge biases for recently
| graduated people who have these in their active memory.
| Experienced people rarely encounter these details in practice and
| are more likely to have their heads full of deep knowledge no one
| in your organization knows about. If you screen these people out,
| it will be quite literally your loss.
|
| Technological fields are blue oceans where only junior people
| spend significant time near the safe harbors. Experienced people
| have sailed far away and seen lands you don't know about yet.
|
| People also have this inherent bias of treating everything they
| know well as some common knowledge everyone else knows as well,
| or at least should know. This bias of underestimating the
| vastness of the field is largely because of inexperience. People
| who haven't seen how deep it goes are liable to think that the
| basic university exercises are the important things.
| marssaxman wrote:
| > Testing for simple algorithms knowledge biases for recently
| graduated people who have these in their active memory.
|
| I have never understood this argument. With 29 years of
| experience, I am about as far from being a "recently graduated
| person" as anyone could be - in fact, I never graduated at all!
| Not only did I drop out after three semesters, I never took so
| much as one computer science class.
|
| I have, according to your assumptions, _never had_ algorithms
| knowledge in my active memory - and yet, these sorts of
| questions have _never been an obstacle_ for me. How can this
| be?
|
| I think many people must mistakenly believe that interview
| questions are the same sort of questions one might find on a
| university test. They appear to believe that the interviewer
| expects them to regurgitate a correct answer, on the spot, from
| memory, and that their suitability for the job is rated based
| on the speed of recall.
|
| That would be absurd, of course. If anyone is actually
| interviewing people that way, they're doing a terrible job.
|
| I have never answered these questions that way - and, when I
| ask such questions in an interview, I never expect them to be
| answered that way.
|
| Rather, the point of an algorithms problem is that you have to
| think your way through it. I solve them in the same way I would
| solve any problem I encountered in my day-to-day programming
| work: by thinking about it, poking around at different
| approaches, roughing out a simplest-possible approach, then
| refining toward a more efficient process.
|
| If I am interviewing you, and I pose you an algorithms problem,
| I'm _hoping_ you will not have memorized an answer. If you
| already know the answer, your skill at writing it out on the
| whiteboard tells me nothing. The whole point of asking you to
| think your way through an algorithms problem is that _I want to
| see how you think_. I don 't even care whether you find your
| way through to a correct answer in the time allotted, so long
| as I can see that you know how to think about a problem, work
| your way toward a solution, and communicate about your process
| as you go.
|
| The common idea that experienced devs ought to struggle with
| algorithms questions dismays me. What are people _doing_ that
| does not require them to maintain basic problem-solving skills?
| Or... perhaps... is this all a big misunderstanding...
| bcbrown wrote:
| > That, of course, would be absurd. If anyone is actually
| interviewing people that way, they're doing a terrible job.
|
| Perhaps you have never experienced that sort of interview,
| but it doesn't mean it doesn't exist.
|
| I was once asked a question where the solution involved
| implementing a trie. The naive design involves a 26-element
| array to hold all the possible next-letter entries, which
| obviously takes a huge amount of memory. The interviewer
| expected me to know the trivia answer on how to avoid
| allocating all that memory, and was clearly disappointed that
| I didn't know (using a linked list instead of a fixed-size
| array: https://en.wikipedia.org/wiki/Trie#Implementation_stra
| tegies). This was a principal engineer interviewing another
| principal engineer, FWIW. The company was Qualtrics, a
| survey/customer satisfaction company, not a bare-metal
| algorithms-heavy company.
|
| Obviously you've managed to have a successful career without
| encountering interview questions that hinge on algorithmic
| trivia, and I'm not doubting your experience. But saying
| "it's never happened to me so therefore it can't exist" isn't
| an especially strong argument.
| bcbrown wrote:
| > Technological fields are blue oceans where only junior people
| spend significant time near the safe harbors. Experienced
| people have sailed far away and seen lands you don't know about
| yet.
|
| I really like this analogy.
| jrjarrett wrote:
| Yes, exactly-this is what I wanted to get across in my comment
| down post.
| jokethrowaway wrote:
| What the article says makes sense but he's not disproving doing a
| coding test similar to what you may encounter on the job vs
| algorithms you'll implement once in a lifetime.
|
| When I'm interviewing, I ask about their projects to see if
| they're passionate about something and then I test them on
| something I need to implement for work (or similar enough). It's
| often something like, implement an API endpoint that does X with
| Y database, implement this UI component. I'm happy to be flexible
| on language and technologies the candidate is familiar with.
|
| If you think the job will be much more than that, you're simply
| wrong.
|
| The closest I got to implement a leetcode exercise at work was
| when I had to implement pathfinding for a 3d game in a language
| that is not commonly used for games. Turns out my naive solution
| was poor, I duckduckgoed 5 minutes and implemented a way better
| algorithm from Wikipedia.
|
| Besides: If I need to prepare for two months for your interview,
| I won't apply for your company. Even doing a take home exercise
| takes way less time than that, I can crank most of those in a
| couple of hours. Still, I'd prefer a real world exercise at the
| interview, so I don't need to prepare anything in advance.
| martinbooth wrote:
| The questions are designed to allow an interviewer to get as
| much signal in the 45 minutes spent in the interview.. that's
| why they're contrived rather than your typical piece of work.
| They're not designed to test you on something you would never
| encounter though. If a company is asking these kinds of
| questions and the job only ever requires dealing with npm
| packages that shields the engineer from this complexity then
| they shouldn't be doing that in my opinion. But most of the
| companies asking these questions are in the business of
| building software that requires this lower-level knowledge
| ovao wrote:
| I can appreciate the author's reservations around take-home
| assignments given how easy it is to cheat, but why not as an
| interviewer simply protect against that by asking the interviewee
| to detail certain aspects of their implementation on a follow-up
| call?
|
| Whenever I submit a project for review, I'm prepared to answer
| questions about why I did X, why I used this
| tool/library/approach versus some other tool/library/approach,
| and what I could do to improve the implementation further. On the
| latter subject, I'll raise that discussion even before being
| asked. If your applicant panics on questions like this -- or is
| obviously clearly making shit up on the spot -- there's your
| indicator to reject.
|
| If you ask me to implement a B-tree, I'll describe what a B-tree
| is and tell you I don't off-hand remember how to do it or what an
| ideal approach would be in a given language. I'd tell you that
| I'd research it a bit before diving face-first into it. Which is
| what almost everyone _would_ do in real-world contexts anyway.
| throwmeawaycs wrote:
| Ah, to me that sounds like you are a good engineer and what
| they actually are seeking is a good "follower/code-servant".
|
| You see it's good to filter applicants like you out because you
| may do nasty things like "question management decisions" and
| "think creatively".
|
| We want obedient slaves with social media accounts, Damn it!
| BoiledCabbage wrote:
| Honestly, they are really great points he makes.
|
| There absolutely are flaws with interviews. But if you stick with
| coding questions using simple datastructures non-esoteric data
| structures, they are the most objective, scalable and accurate
| method of evaluating a candidate.
| jrjarrett wrote:
| Except that skews the candidates that pass younger. If you're
| fresh out of school, you remember binary trees or sorting
| algorithms.
|
| After doing software development for 20+ years, you've been
| using those structures as a small part of the larger problems
| you now solve. If you go looking for a new job, you don't
| necessarily remember all these tricks to invert a binary tree,
| and you fail. Even though you have all that experience in what
| you actually will be asked to do on the job.
| ratorx wrote:
| I'm a fairly new interviewer at FAANG. I wouldn't consider
| "invert a binary tree" to be a good question.
|
| If a question did require "invert a binary tree" to be part
| of the optimal answer, then identifying this would be the
| most important thing. If the candidate then coded an
| suboptimal version, whilst mentioning that a more optimal one
| could exist, that's almost max points.
|
| I think there is a slight focus on "tricks" for coding
| interviews, but from the questions I've done and seen, these
| are more general problem solving strategies, rather than the
| slightly esoteric algorithmic tricks that get brought up on
| HN.
|
| I haven't seen a current question where a very specific
| algorithmic trick is required to get a good rating (but that
| could very well be my lack of experience). I guess dynamic
| programming may be the closest thing. But I would say that's
| a more general strategy and the questions I've seen that use
| it are fairly rare. I've never seen a question require it for
| a good rating, the ones I've seen have it as extension type
| stuff.
| throwmeawaycs wrote:
| Your mentality is "throw them at a hacker rank problem and
| rate who had the best American Idol performance."
|
| Which is braindead. You can claim that's not your process
| but ultimately you're trying to get someone to present an
| output based on your input while also not accepting that
| the process _is not always the same_.
|
| Let's explain by analogy here: I'm hiring a great /Painter/
| for a portrait of my family. Would it be reasonable to call
| in 10 painters and show them a photo of my family and say
| "show me what you can paint in 10 minutes!"?
|
| Do you think that's a good metric to hire creative talent?
| Or, perhaps you don't think they're creative, and you make
| your portrait a paint by numbers, and then say "quick, take
| this color and mix it, then paint in the numbers, let's see
| who can mix the color really fast!"
|
| Or maybe you call the 10 painters in and say "show me your
| personal gallery, that will be all!" So you dismiss 7/10
| painters because they sold their work and it doesn't ride
| around with them.
|
| Do you feel that you're hiring a good painter?
| BoiledCabbage wrote:
| Agreed that it's not perfect.
|
| But asking to talk about technical topics is what is
| essentially trivia - is an absolutely worse approach.
| kag0 wrote:
| The author asserts that simple coding interviews
|
| > involving nothing more than simple and fundamental data
| structures
|
| is the objective way to evaluate a candidate. Because those
|
| > do require a good understanding of programming fundamentals
|
| But in my experience, someone who can memorize those basics can
| also memorize their implementations. So it is quite possible to
| have someone code a perfect BFS, but have no grasp of programming
| fundamentals.
| Apocryphon wrote:
| The discourse around algorithms/data structures coding interviews
| (as opposed to domain-relevant pair programming coding
| challenges) does seem to be universally either about abolishing
| them or keeping the status quo.
|
| Then what about keeping those topics but improving the process?
| How about reducing other pain points? Such as:
|
| * Transparent rubrics about how an applicant is to be judged
|
| * Disclosure of what specific topics are to be tested or not,
| e.g. avoiding candidates stressing over dynamic programming
| problems only to be stumped by simple string manipulation
|
| * Actual training of interviewers so that they can be more
| collaborative and helpful during the interview
|
| * Disclosing to candidates just how many questions they are
| expected to answer during a round
|
| Companies want to keep their Leetcode question banks, fine. But
| the coding interview process are painful and scary to candidates
| not only because of any difficulty in problem content, but
| because of the apparent subjectivity and opaqueness of everything
| involved. Maybe the current process can be reformed and
| systemized a bit so neither party wastes their time.
|
| And another subject worth considering: how could current
| algorithmic pedagogy be improved? How do you take the teaching of
| runtime costs and complexity, specific data structures, and
| general principles like dynamic programming, and be able to solve
| specific problems like, say, merge intervals, without having seen
| such problems previously? Maybe there's a layer of "now that you
| have a toolset, this is a good set of heuristics for matching
| your methods to actual problems."
___________________________________________________________________
(page generated 2022-03-19 23:02 UTC)