[HN Gopher] Whiteboard interviews are a test of obedience, not i...
___________________________________________________________________
Whiteboard interviews are a test of obedience, not intelligence
Author : vitaminCPP
Score : 62 points
Date : 2024-06-03 21:34 UTC (1 hours ago)
(HTM) web link (ashgw.me)
(TXT) w3m dump (ashgw.me)
| optimalsolver wrote:
| Can't it be both?
|
| In the same way a college degree tests your willingness to jump
| through hoops authority figures set for you, but it also
| demonstrates a basic level of mental competence.
| j7ake wrote:
| Yeah clearly. Most companies only want engineers to implement the
| companies ideas, but don't actually care about high level ideas
| from those engineers.
|
| Imagine you are interviewing senior levels of engineer, like
| Guido van Rossum: in an ideal interview, you don't want to hear
| him regurgitate textbook problems taken from an exam book.
|
| You want to hear about his vision of where he sees the field in
| 15 years.
|
| But this is not what companies want.
| brandall10 wrote:
| A real life example of this is Kyle Simpson, the You Don't Know
| JS author. He's recently been public with his issues finding
| employment.
| tomrod wrote:
| Do you have any sources you recommend?
| Aurornis wrote:
| I've hired a book author, worked side by side with internet-
| famous lead devs of two different popular open source
| projects, and followed the lead dev of another semi-popular
| open source project that shows up on the HN front page
| frequently.
|
| The key thing I learned is that they were all very talented
| at what brought them success in their endeavors, but none of
| them actually made great developers within a company. In two
| cases, it became immediately obvious that they wanted to
| treat their job as a side project (that pays the bills) while
| they further expanded their book/course/open-source empire.
|
| Being the author of popular educational material doesn't
| necessarily make someone a great employee. It can actually
| present a significant distraction, which unfortunately can
| make it difficult for them to get jobs.
| Aurornis wrote:
| This is exactly what Staff Engineer roles are supposed to be,
| and they exist all over the place.
|
| > Imagine you are interviewing senior levels of engineer, like
| Guido van Rossum:
|
| The average engineer applicant is not Guido van Rossum. The
| 99.8% percentile engineer is not Guido van Rossum. Using such a
| publicly accomplished and prolific person as your example isn't
| doing the conversation any justice because it's not relevant in
| any way to how actually hiring works.
| jasonpeacock wrote:
| The author falls into the trap of every "technical interviews
| such, just talk to them about their experience!" argument - it's
| easy to sound like you know what you're talking about but not be
| able to actually write code.
|
| I've had so many interviews that started strong, great
| conversation, amazing resume, and then they couldn't write a
| basic function to implement a straightforward algorithm.
|
| Like, they literally could not write a nested for-loop that
| worked (in a language of their choice!).
|
| IMO, the solution is apprenticeships/probationary offers. "Try
| before you buy" goes both ways - it gives the candidate and
| opportunity to try out the company (how many companies like about
| their culture, tools, quality, and work/life balance?!).
|
| Alas, it requires the industry to shift to support that model,
| it's very difficult for companies and candidates to support that
| model on their own without most other companies doing the same.
| robertjpayne wrote:
| I absolutely _love_ the idea of both sides being able to "try
| before you buy". Some jobs just suck for the employee and they
| wont know until they're a month or so in and it's a waste of
| effort for both parties to continue cordially expecting it to
| magically get better.
| JohnFen wrote:
| I think about half of the dev jobs I've had started with a 3
| month probationary period, during which either myself or the
| employer can decide "never mind" without serious
| consequences.
|
| As the new hire, I strongly prefer it for the exact reason
| you state: it's pretty hard to know if I'm a good fit in a
| company prior to actually working there. I've used the
| probationary period twice to get out of such mistakes.
|
| As the hiring company, it's also a great thing for exactly
| the same reason but from the other side of the equation.
|
| Lots of companies do this. I think more companies should join
| the bandwagon.
| parpfish wrote:
| What kind of consequences would a dev have for quitting
| early? I think you can do that at any job.
|
| The consequences are always about your _next_ job and
| whether you can explain leaving a position quickly
| asdasdsddd wrote:
| Or just fire fast in general.
| sokoloff wrote:
| How does "try before you buy" really help the candidate
| though? Many (most?) things that suck about a company can be
| (or are naturally) hidden in a two-week trial period.
| stouset wrote:
| I obviously can't speak toward your experiences, but on the
| flip side I've _never_ been surprised to find out someone can
| 't code their way out of a paper bag after having a technical
| conversation with them.
|
| I have of course met candidates who don't know even the most
| basic constructs in a language they're supposedly expert in.
| But none of them were able to "talk the talk", especially when
| probed directly about problems they've run into and how they've
| solved them.
|
| I want to be clear I'm not discounting your experiences and I'm
| also not trying to say you suck at interviewing or anything
| like that. What I _am_ trying to say is that my own experience
| tells me there must exist questions that reliably expose this
| kind of candidate.
| neilv wrote:
| Do you happen to score as "intuitive" on Myers-Briggs?
|
| I'm idly wondering whether that's why I believe I'm pretty
| good at interviewing people just by talking with them.
|
| Maybe, many of the people who are capable programmers or
| software engineers, but who insist that they can't tell
| anything about a person's ability to code without, say, a
| Leetcode hazing, are just wired a little differently, and not
| picking up on all the signals the same way?
| rcxdude wrote:
| The problem is supporting the 'try before you buy' model would
| basically require most companies to be happy with someone
| taking a month off to go try working somewhere else for a bit
| and then come back if nothing happens. I don't see any
| particular motivation for them to encourage that at all.
| Otherwise, the probationary period is basically just a quicker
| escape from a match that's bad enough that you're rather be
| unemployed (or at least take the risk of such). Either way it's
| enough of an investment that both sides are gonna want to spend
| a least a little effort on figuring out if it will work
| beforehand, like with interviews.
| pessimizer wrote:
| > The problem is supporting the 'try before you buy' model
| would basically require most companies to be happy with
| someone taking a month off to go try working somewhere else
| for a bit and then come back if nothing happens.
|
| I wouldn't think that this is how you would hire a known
| performer. I can still see the problem, but I can also see
| how it wouldn't be a problem if it were a more common and
| more standardized process. And if the applicant were being
| paid contractor's wages (higher) during the tryout period,
| not salary-level wages.
| makeitdouble wrote:
| The whole issue is to identify a "known performer" in the
| first place.
|
| Otherwise, that practice being more common means people can
| leave their job for weeks here and there no questions asked
| ("I'm going to work for our main competitor for 3 weeks"
| won't fly if it needs approval), and come back without
| impact or penalties on their performance.
|
| That would be ideal, but we're so so far from that. Even
| getting people to properly take their parental leave is
| still a fight.
| pessimizer wrote:
| > IMO, the solution is apprenticeships/probationary offers.
| "Try before you buy" goes both ways - it gives the candidate
| and opportunity to try out the company (how many companies like
| about their culture, tools, quality, and work/life balance?!).
|
| I had an ideal experience with the job that did this with me.
| It wasn't a probationary offer, they just offered me a seat as
| a contractor for a month as a tryout. At the end of the first
| week I found a buggy, unoptimized query that was slowing down a
| critical part of their site and frustrating them for a while,
| fixed it, and they made me an offer at the end of the day.
| Everybody was happy.
|
| I don't know why this isn't done more often.
| chadcmulligan wrote:
| There's a risk with that in more sensitive areas, sometimes
| its months before you're allowed to see something serious
| because they don't want their secrets exposed.
| danielrhodes wrote:
| > IMO, the solution is apprenticeships/probationary offers
|
| Most companies would love this, especially startups. The
| problem is that desirable candidates do not love this
| arrangement - there's an opportunity cost and risk for the
| candidate here and if you're in demand you can get a solid
| offer from a company who isn't trying to hedge.
| ilc wrote:
| Here's the thing:
|
| There is a massive asymmetry between what a company that can
| afford to do 1000's of trials at a time to get what they want,
| and an individual who really can't afford to be culled and lose
| 2-4 months looking for another position.
|
| Also if you've ever dealt with temp->perm situations, people
| can change when they go perm. It is a real issue.
|
| ---
|
| As an employee: I usually can tell if a company is bad, I don't
| need to work there 2-3 months to learn that.
|
| So for me there's little to no benefit, and massive downsides
| in that I don't have ANY real safety net to jump to the next
| "internship".
|
| Maybe in Europe where they have stronger employee protection,
| and also better healthcare I'd consider it. But in the US, I'll
| take every protection you give me.
| henrikschroder wrote:
| The norm in Sweden is that every position is "probationary"
| for the first six months, which then automatically converts
| to a permanent position. What it means is that the employer
| can terminate the employment without cause during the
| probationary period.
|
| It's kind of a necessity in places with strong employee
| protection, otherwise companies would have an even harder
| time hiring. Now, companies can take a chance on someone
| without risking very much, so I think it's a good thing.
| Obviously, the companies have to pay new employees the same
| as the permanent ones and give them the same benefits, sick
| pay, PTO, etc.
|
| The flipside is that some unscrupulous companies churn
| employees every six months to avoid having too many permanent
| full-time employees. Not common in the IT industry though.
| jlarocco wrote:
| "Contract to hire" is a popular way of doing that.
| tedunangst wrote:
| This will be shocking, but honestly, the point of asking someone
| to code up fizzbuzz on the whiteboard is not sifting for obedient
| slaves. Hand to god, chop down the cherry tree, no lie.
| eindiran wrote:
| At some point the test stopped being fizz buzz and started
| being "reproduce Brent's cycle detection algorithm from memory
| or from first principles if you have forgotten what it is",
| which isn't testing your ability to program in any meaningful
| way.
| convolvatron wrote:
| i used to ask cycles in a graph. we were building a database,
| used graphs alot.
|
| if we cant talk about the problem together from first
| principles and make some progress, and you cant demonstrate
| that you're tracking the discussion at all then we cant work
| together on that database.
|
| sure, for devops, who cares.
| zaptheimpaler wrote:
| It isn't if the problem is FizzBuzz or a slightly more
| challenging and realistic problem. When its 1-2 leetcode hards
| in 45 minutes that can only be solved by having done hundreds
| of those problems, it does seem the purpose is more to just
| gauge how many such problems you've spent time grinding on
| before even though they have very little relevance to
| programming.
| titanomachy wrote:
| I've interviewed at various "prestigious" companies widely
| considered to be rigorous in their interviewing, and no one
| has ever asked me to solve 2 leetcode hards in 45 minutes. I
| think I might have gotten _one_ leetcode hard question ever.
| Most companies seem to ask relatively straightforward
| questions, although they do sometimes expect you to solve
| them quite quickly.
|
| Doing a bunch of leetcode problems (something like 20-30
| hours over a few weeks) certainly made it easier to answer
| questions quickly, largely by becoming more fluent in the
| language and libraries.
| crooked-v wrote:
| Leetcode questions are definitely step 1 in Meta
| interviews, at least as of the round I went through earlier
| this year.
| robertlagrant wrote:
| I did Meta in about 2020 and they did not ask anything
| like that in step 1. They asked a single question that I
| had about 20 minutes to figure out. Nothing particularly
| leet codey about it; just a question that was basically
| asking for a dictionary implementation that also had a
| list for most recent access. The point wasn't the
| advanced algorithm; it was comprehension and a bit of
| code.
| titanomachy wrote:
| I do get lots of leetcode-style questions, just not
| leetcode _hard_ questions.
| whimsicalism wrote:
| Whenever someone tells me they've been asked a leetcode
| hard in an interview, I always ask them "which one". I
| don't think I've ever gotten a response that was an actual
| LC hard.
|
| This is the only LC hard I've ever been asked in an actual
| interview https://leetcode.com/problems/shortest-path-in-a-
| grid-with-o...
| tikhonj wrote:
| I haven't done any Leetcode so I have no idea of what
| "medium"/"hard"/etc are, but the last time I interviewed,
| the two problems I failed were very fiddly dynamic
| programming problems--the hard part was not even the
| dynamic programming, but rather the problem-specific setup
| (based on chess rules and geometry, respectively).
|
| I am sure I would have done better at those with practice,
| entirely because I would have seen lots more fiddly dynamic
| programming problems and not because I would have picked up
| any general-purpose skills or knowledge I don't have as-is.
| whimsicalism wrote:
| 2 leetcode hards is just absolutely an exaggeration, i've
| done tons of these interviews and i've only been asked a
| formal "LC hard" once and that one I believe was a
| misclassification and was probably more of a medium
| kristjansson wrote:
| Whiteboard questions are great, if the question is like two
| orders of magnitude simpler than the day to day. At that point
| you're answering "has this person seen a computer before, and
| are they able to do the simplest possible task?". Which I think
| your experience has also shown, can be a live question for far
| more candidates than one would expect.
|
| The problems come when a company overestimates that threshold,
| either by selecting too hard a task, or believing their work
| requires more than it does. Then the question selects for (a)
| savants and (b) people who study for interviews. Unsurprisingly
| (b)s outnumber (a)s, and then get pissed when they realize how
| disconnected the material they studied is from the job, and
| write things like TFA.
| tikhonj wrote:
| The purpose of a system is what it does. And what Leetcode-
| style whiteboarding tests substantially do--very much _not_
| fizzbuzz!--is select for people who have specifically prepared
| for Leetcode-style problems.
|
| Describing that as selecting for "obedience" is rather dramatic
| and provocative, but it's directionally right.
|
| That's what the article is about, it isn't about the sort of
| basic programming test that anybody should be able to pass
| without explicit preparation.
| micromacrofoot wrote:
| > We don't need free thinkers or leaders, we need obedient
| slaves, individuals who'll unquestioningly follow orders and work
| overtime. Their expertise? Irrelevant. We'll train them, we can
| afford it, our customers will pay for that.
|
| I mean, yes that's actually what most large companies want. "Free
| thinkers" can often be outright terrible employees because
| they're just not interested in building whatever boring thing a
| company needs. They put a small number of these people in a box
| and make the majority of the company build what seem like the
| most profitable ideas to come out of the box.
| the_real_cher wrote:
| Actual coding has always been like 20% of my job.
|
| The rest is spent co-ordinating, planning, troubleshooting, etc.
|
| If youre going to test me on coding then actually let me code.
| lol
| schneems wrote:
| A whiteboard test asks the question: do I have anxiety about
| whiteboard tests.
|
| The answer is "yes".
| tennisflyi wrote:
| Yes and interviews are about who interviews the best. Not the
| best fit or smartest
| zerr wrote:
| Same goes for [unpaid] take-homes and leetcode grind.
| jahewson wrote:
| I don't get the hate for unpaid take-homes. It's not like you
| are getting paid for multiple hours of interviews.
| TN1ck wrote:
| While (live) code challenges have a lot of problems, I don't see
| it as a possibility to get entirely rid of them. As someone who
| hires engineers, I do want to verify that people can actually
| code. While most people who are "merely talk" can be already
| filtered without a code challenge, there are plenty who make a
| good impression, but lack fundamentals in coding or do not have
| the skill level I'm hiring for.
|
| Live codings especially are a very good insight in how someone
| thinks and approaches a problem, never thought about obedience in
| any aspect.
|
| If someone has contributed to an open source project or has some
| themselves, talking about those instead is enough for me as well,
| but that's even more to ask for imo, as not everyone has the time
| to create a project that is worth talking about and demonstrates
| their skill.
| rkagerer wrote:
| When I went to my first job interview after years building my
| own software product, I brought all kinds of examples of code I
| wrote which I felt showcased my talent (including an effective
| API I created for one of their services that lacked one, and
| code examples of mine that had been published in a textbook).
| The interviewers had zero interest, and just wanted to discuss
| superficial / artificial whiteboard-type problems and (in
| retrospect) how to hose more ad revenue out of users by
| upending expected browser behavior.
|
| I can appreciate how some of it offered a glimpse into how I
| approach problem solving, but the process (not just that
| aspect) left a sour taste, and over a decade later I'm so glad
| I didn't wind up in a career position there.
|
| If you want to attract top tier talent, as an employer you
| should also work to make your interview process fun and
| challenging, and showcase what sets you apart from you
| competitors. Too often firms loose sight of the fact that in
| the interview, they are being evaluated too.
| theogravity wrote:
| I'm absolutely terrible at interviews, especially
| whiteboarding, and the best ones either involve taking a tour
| of my own code, or them showing parts of their codebase and
| me asking questions around it; or, take homes and I have a
| chance to explain what I built.
|
| I don't have the memory capacity that others do to just stuff
| leetcode challenge algorithms that I'll never use in my head.
| parpfish wrote:
| I see two problems with bringing in your code for an
| interview:
|
| - I don't know how long it took you to do it, and being able
| to do things in a reasonable amount of time is part of all
| jobs. Also, I don't even know if you're the one who wrote it
| or if you are passing off somebody else's work
|
| - it's unstandardized across interviewees, so how do you
| compare? Person A wrote a more elegant solution, Person B
| solved a more challenging problem, and Person C did all their
| best work on propriety stuff they couldn't share so they had
| to share show you a throwaway side project they did in one
| weekend
| nomel wrote:
| I once gave an interview to a PhD with 15 years of experience.
| He couldn't write a for loop at the end of the interview, but
| had great knowledge otherwise. We needed someone who could
| actually code. I had my boss join late, because it was so
| unbelievable. I was the only "no" for him. I was the only
| person that tried to make him type something.
|
| I keep my question _very_ light and completely work related.
| They 're allowed to ask as many questions as they want. They
| don't even have to remember any algorithms (I have a review
| slide for the relevant ones they might pick). They just have to
| be able to think and be "seeking" in their mindset, asking
| questions to fully understand the context, then convert that to
| code. That's it.
| lapcat wrote:
| What's more likely?
|
| 1) The candidate was a criminal mastermind who somehow
| managed to fool everyone for 15 years.
|
| 2) The candidate was just super nervous during the interview
| and experienced a kind of test anxiety.
| fivereason wrote:
| one advantage to the whiteboard interview is that it allows a
| person to get the job regardless of their past experience, which
| can be determined by what they were "allowed" to do at previous
| companies. in some cases, people are pigeonholed into various
| genre of engineering based on assumptions about them (e.g.,
| assign african americans or women certain types of work even
| though that isn't what they prefer). if you can only speak to
| what you've been allowed to do compared with what you can prove
| you've learned to do (via the interview), you could be at a
| disadvantage.
|
| what if we could pick the type of interview we wanted? whiteboard
| coding challenge or work experience based?
| throwawa14223 wrote:
| I've worked at companies that required very heavy whiteboard
| interviews and companies that banned them. The caliber of
| engineers at the whiteboard heavy companies was higher at each.
| At this point I see them as a needed filter.
| DFHippie wrote:
| One thing a whiteboard interview does is confirm that you
| resemble the person described in your application. This is ever
| more important as many people have an LLM write their application
| for them.
|
| Here's a prediction: as it becomes ever easier to fake details
| remotely, there will be an ever greater emphasis placed on in-
| person interviews in the hiring process, with the result being
| that even remote work is less remote: you have to being the
| physical presence of an interviewer at some point. If the job is
| in Kalamazoo, most of the people making the final cut will be
| near Kalamazoo.
| thedynamicduo wrote:
| It's hard to read this as anything other than a bitter candidate
| who got rejected after a series of FAANG interviews. There are
| some legitimate criticisms sprinkled in, but to characterize
| everyone who made it through as slaves who are more obedient than
| you seems like a coping mechanism.
| devit wrote:
| They are a test for people who are very strongly identified with
| being highly intelligent/skilled where the definition of
| "intelligence/skill" includes solving programming and computer
| science problems (and have the capability to achieve a good
| level).
|
| If that's your identity, then not being able to solve hard
| Leetcode problems (which, to my knowledge, are not even actually
| hard, since they seem to be easier than the problems in actual
| top competitions like the IOI, ICPC, etc.) is completely
| unacceptable and thus you will study and practice relentlessly
| until you manage (if you can); conversely, if that's not your
| identity, it's probably going to be hard to find the motivation
| to do so.
| janalsncm wrote:
| A while ago I interviewed at Scale AI. After reading about them
| online I was fairly certain I didn't want to work there, but I
| decided to do the interview as practice anyways.
|
| The interview had nothing to do with the role I would be doing,
| and worse yet, the interviewer seemed pretty tired and
| uninterested. So when I was rejected I wasn't too upset.
___________________________________________________________________
(page generated 2024-06-03 23:01 UTC)