[HN Gopher] Becoming a dungeon master for an interview
___________________________________________________________________
Becoming a dungeon master for an interview
Author : mooreds
Score : 106 points
Date : 2024-02-10 17:13 UTC (5 hours ago)
(HTM) web link (www.propelauth.com)
(TXT) w3m dump (www.propelauth.com)
| navane wrote:
| > it feels like a very, very light version of the prep you do
| when designing a campaign as a DM
|
| With todays chatgpts, that reads like a pretty decent prep for a
| campaign as a DM.
| neilv wrote:
| > _Interviews should be as close as possible to the work that the
| candidate would do if they join._
|
| Interviews should give information to both parties about what it
| would be like if the person joined.
|
| Simulating a typical work task, as this article describes, might
| give you some of that. Though important to remember that's far
| from all that's relevant to either party.
|
| A recently fashionable Leetcode hazing, on the other hand, is
| mostly "anti-pattern". It tells the company whether or not the
| individual has studied for that ritual specifically, and was
| willing to submit to it for the approval of this company (or is
| using this company as practice for the gameable ritual). And it
| tells the individual nothing except that the company thinks this
| is a good way to do interviews.
| mooreds wrote:
| > Interviews should give information to both parties about what
| it would be like if the person joined.
|
| I have participated in interview processes where, at the last
| interview, the employer tries to talk the candidate out of
| taking the job. Discuss the problems, the warts, the
| intractable issues, and other things that are downsides of this
| job. Every organization has these.
|
| I love this, because the employee is going to find all of the
| issues out anyway, and it's better for both parties if they
| part before employment begins if the issues are too much.
| neilv wrote:
| Interesting, and I could see that working well for some
| places.
|
| I do something related to this in the interview. Part of the
| interview is more like things you'd tell a colleague who was
| considering that: pretty accurate characterization of what
| you know of the work, your idea of pros, things that might or
| might not be cons for the person, etc.
|
| Basically, they show up the first day, and their interactions
| with me are just the same (plus a little extra excitement on
| my part that they joined, and now able to share proprietary
| details but without unpleasant surprises). Six months later,
| and I'm still just the same (plus extra familiarity and
| increased mutual trust). And hopefully they also are what
| they seemed to be in the interview.
|
| Though you can't necessarily be 100% candid about everything
| in an interview, like if you were doing an internal
| assessment a technology, product, vendor, or competitor. For
| example, there are personnel issues, company image,
| proprietary tech, etc. Also, you don't want to say something
| that ends up misleadingly quoted out of context on a jobs
| forum or word-of-mouth by someone with a different sense of
| professionalism or confidentiality, and you don't want to
| give ammo to a spy from a competitor.
|
| In practice, the line of what to say seems pretty intuitive
| to hit, and I haven't knowingly had a problem with it.
| Though, when working at one company doing exotic-sounding,
| high-value-sounding stuff, I did have a couple candidates
| grill me on the tech and/or on resources. On those I try to
| respond something like, "Some of that is very proprietary,
| and unfortunately can't be talked about much right now until
| someone joins the team. But I can tell you some of the public
| information from news articles and such is _A, B, and C_.
| There 's a few marketecture diagrams on our Web site, and
| links to some published research papers that detail those
| aspects better than I could."
| abathur wrote:
| > was willing to submit to it for the approval of this company
|
| I abstain, myself. I have too much real work that I'd like to
| push forward to be able justify spending weeks of free time on
| fake work.
| paulcole wrote:
| Great! Isn't that the point? That some people who really
| don't want the job won't invest a bit of their time and
| people who do really want the job will?
| majormajor wrote:
| Don't forget about the people who don't have to spend weeks
| or months focused just on interview prep to do well on the
| average leetcode question...
|
| That's who interviewers are looking for. Now, a case can be
| made that there aren't that many of those people and you
| might not need them anyway, but... if you can spend a few
| weeks to catch up that's not all bad compared to what high-
| end job offers in other professions demand of your resume.
|
| The more we keep the interview process something
| demonstrable vs status/prestige/name-check/references, the
| better.
| dinobones wrote:
| If you want to receive top compensation, and work at the
| Meta/Roblox/AirBnBs etc, you will need to be able to
| solve 2 Leetcode medium questions in 45 minutes,
| correctly and optimally.
|
| I work for a big tech company where people smell their
| own farts and think they are geniuses even though they
| work on CRUD interfaces for admin portals for Cloud. The
| interview process is well known.
|
| I have seen _wrong_ solutions made by these genius
| question writers in their own doc, or where they find out
| 4 weeks later that the time complexity of their own
| solution is not really what they thhink it is. Do you
| really think in a company with 50k+ software engineers,
| where many studied English (but like to conduct CS
| interviews like they're CS researchers), that everyone
| will know and understand details like; how the expected
| linear time complexity of quickselect works?
|
| It's a nightmare; it's blind leading the blind. It's been
| completely gamified at this point and the only way to win
| is to play the game, maybe 10 years ago you could've
| passed on your own merit of having a CS degree and
| knowing basic DS&A, but I promise you that is almost the
| case nowhere anymore.
| pavlov wrote:
| That selects for people who aren't holding productive jobs
| currently.
|
| It's a reasonable filter for junior positions, but seems
| counterproductive if you're looking to fill a position
| where experience would be valuable.
| abathur wrote:
| I doubt it?
|
| My willingness to practice leetcode isn't correlated with
| my interest in new work or the work any given job post
| describes. It's also not correlated with my willingness to
| invest time in exploring the position.
|
| 6 hours of leetcode practice teach me nothing about a
| position, the work it entails, the problems the company is
| grappling with, and the people I'd be in the trenches with.
| 6 hours in conversation or working close to real problems
| are higher leverage.
|
| I have meaningful open source work with real users in the
| queue, and blog posts that won't write themselves. I feel
| like it's pretty reasonable to sort positions that don't
| compel low-leverage busywork that doesn't help me assess
| the position above those that do.
|
| Sure, they _might_ mean to exclude me, but I 'm skeptical.
| jstarfish wrote:
| That, and age discrimination.
|
| Someone who took CS in the last 4 years will presumably do
| better on trivia than someone whose degree is nearing 40.
|
| It's the older crowd that have less time to prepare for
| circus acts.
|
| The daycare center aesthetic and all this weird pronoun
| crap achieves the same ends. If everyone around you is an
| androgynous alien speaking a novel language and
| communications mishaps will get you fired, you won't feel
| comfortable working there.
| pavel_lishin wrote:
| > _The daycare center aesthetic and all this weird
| pronoun crap achieves the same ends. If everyone around
| you is an androgynous alien speaking a novel language and
| communications mishaps will get you fired, you won 't
| feel comfortable working there._
|
| I'd argue that if you can remember people's names, you
| can remember their preferred pronouns - and that if you
| can't, or refuse to because you think it's "weird crap",
| they won't feel comfortable with you working there
| either.
| jstarfish wrote:
| I'm terrible with names, but that's my own problem. I
| don't do voicemail or pronouns either.
|
| The rest of it is being ostracized for refusing to
| acknowledge the black floor tiles are lava. Redefining
| the reality of others is literal brainwashing. In
| fostering this sort of environment you're running a cult,
| not a company.
| lostlogin wrote:
| > I don't do voicemail or pronouns either.
|
| You don't use any pronouns?
| mewpmewp2 wrote:
| To be fair, even remembering the names is really
| difficult, especially working in a large org, many people
| I see only once or twice or have just heard about. With
| pronouns most of the time I can luckily just resort to
| "them" if I am unsure.
|
| I frequently in a meeting am unsure if I have or when I
| have met the person before, although I do find their face
| familiar. That is the first level of awkwardness to solve
| for me. Should I tell them "nice to meet you!" or "great
| to see you again after such a long time!".
| kanbara wrote:
| leetcode interviews and intense algorithmic problems for
| roles which don't require such acumen can definitely be
| ageist
|
| the pronoun issue is your own, however, and speaks
| nothing to the character of colleagues who may be
| genderqueer. they aren't aliens, they're human beings.
| zilti wrote:
| They are humans indeed, and as the phrase goes, "your
| mental health is not your fault, but your responsibility"
| ProjectArcturis wrote:
| Not gonna lie, you had me in the first half.
| neilv wrote:
| There's a lot of age discrimination in tech industry.
| But, for the record, progressive efforts in companies
| aren't about age discrimination (though I guess they
| might be abused for that at some places).
|
| I'm over 40, have been working since I was a teen, and I
| have understanding and empathy for things like preferred
| pronouns. Genuine appreciation for this can come from
| seeing how things were for people before we improved
| awareness and sensitivity. In practice, our improvements
| aren't always perfect, and they sometimes get misapplied
| or abused, but overall, people are trying, and some
| social/societal things are improving. Try to see past the
| rough spots and growing pains.
|
| Even Leetcode interviews (which I think are very bad for
| software engineering), you can see why that gets cargo-
| culted. Especially if someone has never had a pre-
| puzzles/Leetcode interview, and doesn't know it can be
| better.
| TheCleric wrote:
| Sure. If what the company doing the hiring is explicitly
| trying to get employees who are willing to do that.
|
| However if they just want knowledgeable, quality employees,
| some will self select out of that process.
| karmajunkie wrote:
| if that's the only way you're able to discern a good
| candidate from a bad one, that speaks far more loudly about
| you than any candidate.
| adamgordonbell wrote:
| I feel like leetcode is a Goodhart's Law thing. When nobody was
| cramming for it, then at some places it was a good measure.
|
| Coding is more like weight lifting sometimes then running.
| There are some weights that some people just can't pick up. And
| so if the job involves lifting things that are usually light
| but occasionally heavy, then a squat becomes a good measure for
| candidate.
|
| But once everyone knows a big squat is the way in, they train
| squats, they show up in lift suits, they use amyl nitrates and
| the whole thing stops being a good measure.
|
| Because on the job you don't squat in a squat rack, but pick
| things up where they are found, in the conditions on the
| ground.
|
| Goodheart's law breaks things, because now you have a bunch of
| people optimized for a task that isn't exactly the job.
| mooreds wrote:
| > Goodheart's law breaks things, because now you have a bunch
| of people optimized for a task that isn't exactly the job.
|
| Companies lose another way too.
|
| Folks who might be darn good at picking things up decide it
| isn't worth the focused training to get into companies that
| only seem to care about squatting, so they don't apply.
| adamgordonbell wrote:
| Yeah, I feel like any measure like this starts as a way to
| measure a proxy for IQ. But as it becomes a known thing,
| people train for it and it becomes a measure of
| conscientiousness (In the big five sense, aka diligent
| trainers rise to the top).
| yieldcrv wrote:
| making a react component in a 45 minute interview (something I
| recently did) is _better_ than leetcode, but still a poor
| signal. on the job I 'll never do a time trial where I'm being
| watched and gaslit about "just wanting to see how I think" as
| opposed to "do it perfectly from memory in this collaborative
| coding session faster than this guy escaping a dystopia in
| Asia, and trying not to be deported back"
|
| find a way to simulate that I will do it some time over the
| next two weeks because the product manager reduced everyone's
| story points in half for this sprint in the grooming session,
| and the fact that I even did that gets me praised because
| nobody else on the team finished their tasks
| azangru wrote:
| > faster than this guy escaping a dystopia in Asia, and
| trying not to be deported back
|
| While that guy may have an advantage over you in motivation,
| you might have an advantage over him in communication.
| gdsimoes wrote:
| Also known as accent.
| AlotOfReading wrote:
| On average, I enjoy these kinds of interviews much more than
| leetcode. The quality of the prep work and the ad libbing makes a
| huge difference to the quality of the interview though. One
| particularly memorable interview involved verbally debugging
| intermittent crashes the interviewer had recently seen.
| Unfortunately, they had no information about the software stack,
| unique symptoms, or access to status registers so it ended up
| like:
|
| "Is this bit of information available?"
|
| "No"
|
| Repeated for 30 minutes.
| bee_rider wrote:
| That seems like an interview that you passed (the company
| learned that you know a lot more than them about the resources
| available for debugging).
| pavel_lishin wrote:
| It also sounds like an interview that the company failed.
| rzzzt wrote:
| Also a high level of frustration tolerance.
| X9 wrote:
| Love this approach! We used this method for awhile when
| conducting interviews, usually with a couple problems escalating
| in difficulty. Found it to be way more helpful to watch how
| someone troubleshoots than to test their aptitude with specific
| skills
| golol wrote:
| I think one issue with this is that some candidates who might be
| great at the actual job could, for whatever reason, be bad at
| this verbal type of simulation. Perhaps they work by staring at
| the problem on their screen a lot, perhaps they struggle to think
| at the same time as roleplaying. Just saying that this
| roleplaying aspect is somewhat tested for and doesnt align with
| the job exactly.
| mock-possum wrote:
| Yes precisely. Make sure that you're actually selecting for
| what you mean to be selecting for.
| paulcole wrote:
| A lot of companies would much rather pass over a great fit than
| hire a bad fit. Not hiring great people isn't that bad of a
| thing in most cases.
| abathur wrote:
| The interview the post describes actually sounds like a good
| format for me, but I do have some problems adjacent to the ones
| you mention.
|
| As someone who struggles with ~parallelizing some tasks
| (especially when anxious), it would be great to have an up-
| front check in about how comfortable I am with the format of
| any technical ~challenge. (And even better to discover there's
| some wiggle room to accommodate.)
|
| For example, I find it very difficult to code my way through a
| problem _and_ narrate what I 'm doing _and_ take feedback while
| I know I 'm being evaluated and the clock's ticking. If the
| interviewer says something important in the middle of this, I
| often have to put down any plates I've managed to get spinning
| (and maybe go offload some adrenaline) and then ask them to
| repeat before I can even parse the words they said, let alone
| figure out how they apply to the problem.
| Animats wrote:
| That's called an in-basket test.[1]
|
| For a really unusual interview process, see how Jane Street, the
| trading firm, does it. They expect people to do well at this.[2]
|
| Their actual interview process starts each candidate with a stack
| of poker chips. In each interview, candidates get to make bets on
| various things that look like financial trades. If they run out
| of chips, they're out.
|
| [1] https://en.wikipedia.org/wiki/In-basket_test
|
| [2] https://figgie.com/how-to-play
| a_wild_dandan wrote:
| They should live stream interviewing the stock trading fish. Go
| pro, little dude!
| andrewstuart wrote:
| Here's how to recruit software developers.
|
| 1: define the requirements for the job
|
| 2: devise questions that attempt to give insight into how well
| the candidate might meet that requirement
|
| 3: note down the candidates suitability out of ten for each
| question
|
| 4: TALK to the candidate in a free flowing and open discussion
| about their work, what they have done, how they built it, why
| they built it that way, their role in the project, what went
| right, what went wrong, what they would do differently.
|
| 5: Whether or not the candidate asks questions is a meaningless
| measure. What is meaningful is to sense their level of curiosity
| - about this job that you are offering, about computing and
| technology in general. Software development is hard and being
| good at it requires a level of curiosity. It's probably a concern
| if someone shows no curiosity in this job or software, though you
| need to be cautious about how you measure this - did you do a
| good enough job to explore their level of curiosity? Curiosity
| does not necessarily reveal itself without careful probing.
|
| 6: Discuss the actual work of this job with the candidate.
| Quickly run through the actual todo list of things that need to
| be done right now - talk through the hardest of those tasks - how
| would they approach it?
|
| 7: take a leap and employ the person you feel is right - do NOT
| go into ever deeper analysis, ever more interviews, ever more
| tests and checks and hoops. No matter how much interviewing you
| do, you probably won't really know how someone goes in this job
| until they've been in it 3 or more months.
|
| 8: Don't be so risk averse that you don't hire anyone. Do it
| based on your best guess. it might sound harsh, but do your best
| and be willing to fire them before their 3 month trial is up if
| they are not the right person.
|
| 9: Take into account enthusiasm - how much does this person want
| this job? And no, do NOT measure this until the end of the
| interview process - looking for enthusiasm in a cover letter is
| like wanting a girlfriend/boyfriend commitment before first date.
|
| 10: Pay more than people expect, if you can. $1K less than
| someone says they want/need reduces first day enthusiasm for the
| job, $1K more increases first day enthusiasm. Wind the numbers up
| and down for greater impact.
|
| 11: After the interview process is done, talk to referees,
| analyses interview results apples versus apples.
|
| 12: Interview gimmicks, leetcode, abstract questions should be
| red flags for interviewees. If you're looking for a job and find
| yourself in a silly interview, be willing to politely call it off
| and save yourself the time and hassle of dealing with a company
| that does not know how to recruit software developers.
| wiseowise wrote:
| I was expecting different dungeon master:
| https://thefinalrumble.miraheze.org/wiki/Van_Darkholme
| neonsunset wrote:
| Took me a moment or two to realize this is about DnD.
|
| After all, interviews tend to be a stressful and intense
| process...
| Tade0 wrote:
| In interviewing I try to avoid approaches that in any form or
| shape resemble riddles, so ostensibly open problems but with
| predetermined acceptable answers.
|
| I've found that it's both frustrating for the candidate and
| doesn't give me much insight.
|
| Such a back and forth to me is too close for comfort, even though
| I used to be into role-playing games back in the day.
|
| Currently I try to use the little time I have to determine
| whether the person in front of me is a charlatan, so only
| questions that are easy to answer for someone actually having the
| skills advertised in their CV.
| im_down_w_otp wrote:
| Could you just have them sign an NDA and pair with people on
| some non-trade-secret real issue that needs addressing?
|
| If you start by giving a little bit of context and then jump
| into some reasonable end of the backlog, then you get to see
| how they think of priorities, they get to ask you lots of
| contextual questions, you get negotiate with each other a thing
| to do, you get to investigate and/or develop a solution, and at
| the end of it all parties involved got lots of signal about
| what it's like and what's required to do the job. Not to
| mention you stand the chance of some normally useful thing
| getting further along too. Work with the person like they're
| "consultant for a day" and see where you get to.
|
| Why is our industry so resolute to come up with a bunch of
| bespoke, oblique representations of a job when the actual job
| is right there available to be used for assessment?
| pavel_lishin wrote:
| My favorite interview experience was a short take-home that
| required me to write a toy version of something the company
| actually did on a day-to-day basis, followed by an in-person
| pairing session to extend that toy to handle more
| functionality and cover certain edge cases.
|
| Of course, the downside is that it required me to spend four
| hours working on this at home, and then another several hours
| at the interview - but having to spend time interviewing is
| something that _cannot_ be avoided, so I 'd much rather the
| time be spent on something relevant that actually shows off
| my abilities, rather than playing Advent of Code with money
| at stake, or filling out astrological profiles.
| one_buggy_boi wrote:
| > _When interviewing as a software engineer, for example, you'll
| run into places that lean heavily on algorithms interviews. And
| don't get me wrong, those interviews can be fun (in the same way
| that Project Euler can be fun), but it's not very relevant for
| most jobs_
|
| I'm curious what changed around 2015-2016 that led to the current
| interview process. In the before times the interview was more of
| a technical conversation, sure they had some gotcha questions,
| but nothing too brutal. If you had real experience that you could
| talk about, maybe it was validated against references or a
| background check. People usually looked for a CS or adjacent
| degree, and that was enough. The quality of folks wasn't too
| different in my experience.
|
| I really feel for those with a lot of experience that are being
| dropped into the fire, especially those with families who may not
| have the time to memorize patterns for 3 months, but are still
| very capable. Non-tech, low paying jobs now ask you to create a
| soduko solver or trap rain water within 45 minutes. There's not
| many places to go for those that don't 'adapt'.
| dmoy wrote:
| > I'm curious what changed around 2015-2016 that led to the
| current interview process. In the before times the interview
| was more of a technical conversation, sure they had some gotcha
| questions, but nothing too brutal. If you had real experience
| that you co...
|
| Places just copied big tech companies that were already doing
| that for many years prior to 2015. I had leetcode style
| interviews well before 2010 even.
| sailorganymede wrote:
| Pretty much this. Companies needed software engineers, looked
| at what Google was doing, and copied. And they call
| themselves innovative for doing it.
| a_wild_dandan wrote:
| Ah, so to reach their hiring destination, their preferred
| mode of transportation is the bandwagon.
| bluedino wrote:
| Part of the problem is people just memorize things for
| interviews. We interviewed three candidates that were almost
| exact copies of each other in their responses. Maybe they all
| read the same interview book?
|
| I also witnessed someone give a completely wrong (algorithm)
| whiteboard answer to a problem. Obviously they weren't
| thinking about the problem as they did it.
| DoctorDabadedoo wrote:
| Big Tech could afford to do that due to their aura of
| mysticism and greatness, but if you're a mom and pop shop
| with Google-esque aspirations but none of the compensation
| and status, I wonder how many candidates have the patience
| and interest to go through the hoops.
| monlockandkey wrote:
| Leetcode started around 2015
| xw30992 wrote:
| Personally I love leetcode. I do it on Sundays like others do
| crossword puzzles.
|
| But once upon a time these leetcode interviews made a ton of
| sense. Just getting your program to run at all was basically
| a leetcode exercise.
|
| see for example: https://arstechnica.com/gaming/2020/03/war-
| stories-how-princ...
|
| I have my war stories too. It was fun but frustrating.
| Definitely not as productive as today.
|
| Early 2000s internet was kind of like that too. The web was
| huge relative to what we had to work with and there wasn't
| the kind of products/services available then so asking
| leetcode stuff had a logic to it.
|
| Admittedly, that's not where we are now for most programmers
| so it makes sense that the interview process should adapt.
| herval wrote:
| The kind of people who do best at FAANG interviews are the
| ones who enjoy leetcoding. We're all selecting for the
| wrong skills.
| mewpmewp2 wrote:
| Even if I enjoy leetcoding and I do, there are tons of
| things I would rather do before that, and that are far
| more useful, such as building and working on side
| projects.
|
| So to me leetcoding is a waste of time and less fun than
| actually building something, having other people use what
| you have built. And there is infinite things to build
| there and learn.
| meowtimemania wrote:
| I recently started interviewing again and haven't encountered
| many leetcode style questions this time around. I'm noticing
| lots of contrived questions that relate to some feature the
| company had to build.
| marcellus23 wrote:
| What does it mean for an interview question to be contrived?
| a_wild_dandan wrote:
| So overly specific that it feels inappropriately artificial
| within the context of testing a stranger.
| lovegrenoble wrote:
| And this Dungeon Master tool can add some ambience to your
| adventure)) https://tabletopy.com
| thdc wrote:
| I like to think it went like this
|
| 1. Interviewer: If you're a good software engineer, you can
| answer basic algorithmic questions.
|
| 2. Interviewees: Practice algorithmic questions so you appear
| to be a good software engineer.
|
| 3. Interviewer: People are just studying leetcode to get jobs,
| what can we do? Ask harder leetcode questions.
|
| 4. Other companies: Let's copy them since they're successful.
|
| In short, the questions used to be reasonable until people
| specifically prepared for them. No one knew what to do about it
| so they just raised the difficulty, which made it even more
| unfair for people who don't specifically prep.
| Spivak wrote:
| It's actually great on the hiring side -- you can skip all
| that bullshit and because tryhards are all prepping obscure
| CS questions just having a conversation about technical
| topics has become signal again. Measure something people
| aren't trying to game and you get a better assessment, go
| figure.
| mewpmewp2 wrote:
| Yes, I explicitly do the opposite and have the most
| pragmatic exercises, questions.
|
| Another thing is an exercise for system design where
| hyperscaling is not required and the thing is actually
| quite simple. Many who have specifically prepared by
| leetcoding and reading "cracking the coding interview" 10
| times over will naturally overengineer everything trying to
| fit this exercise to those book patterns dropping all
| common sense, all the while not having actually built
| anything meaningful.
|
| I think these people will mostly try to rest and vest
| anyway. Truly passionate people will pass since they have
| actually built something and will understand the exercise.
| liquidpele wrote:
| What changed? Well it was about 2010, The industry became a
| target for very low quality people to do whatever they could to
| land the job by faking and lying. All of these annoying
| interview tricks are just a way to try to filter out all the
| people (90% of them now) who taught themselves how to talk the
| talk but couldn't program themselves out of a wet paper bag.
| And yes, there are ways to figure it out but it's really hard
| given the current volume, and having your engineers stop and
| interview constantly kills productivity when you have to
| interview 20 people and only one can even count words in a
| file.
| doctorpangloss wrote:
| The people who are fooled by fast talkers don't care about
| the results of leetcode questions either.
| liquidpele wrote:
| Even just giving Leetcode questions isn't enough anymore...
| I've had plenty of people just memorize the top 50 used
| questions and be able to answer them, but then not be able
| to explain anything about their answer. It's exhausting.
| prox wrote:
| Function wetpaperbag() { Quit() }
|
| How did I do?
| hx8 wrote:
| It all started in a few years earlier. Google had determined
| that there was a strong correlation between understanding
| fundamental computer science and being a strong software
| engineer, so they began testing for computer science
| fundamentals. At the time lots of companies were trying to
| mimic Google's success and it quickly became an industry
| standard. People began just studying how to answer these
| questions. The population of people that are good at these
| types of interviews shifted from hardcore detail oriented
| programmers with academic backgrounds to mostly people that
| spend time practicing leetcode style questions.
| dr_kiszonka wrote:
| One of their hiring criteria is cognitive ability. If it
| correlates with strong proficiency in CS algorithms, then
| this might have been why they focus on it when hiring
| engineers.
|
| (I am not saying that this strong correlation exists.)
| rhymer wrote:
| I'm grateful for leetcode. Despite my background in electrical
| engineering, where I specialize in statistical signal
| processing, I never had the opportunity to delve into algorithm
| or data structure courses during my college years.
|
| In my field, understanding signals and systems, probability,
| optimization, and numerical computing is very important.
|
| Leetcode, in comparison, offers a more confined scope, making
| preparation more manageable and systematic, ultimately helping
| me break into software engineering.
| tptacek wrote:
| It is possible to structure interviews so that:
|
| * Every candidate get an almost-identical interview
|
| * The interview is not heavily dependent on the investment or
| natural aptitude of the interviewer
|
| * Interviews generate _data_ that can be scored by a rubric
|
| * Interviews aren't scored by the interviewer, thus eliminating
| the intrinsic bias of being in the hot seat with the candidate
|
| It looks different for every role. For instance, for a
| penetration testing role, I've run standardized interviews that
| involve generating and prioritizing attack surface lists and
| hypothetical bug lists. The output isn't "pass/fail", it's the
| list of places to test, the list of bugs expected,
| scheduling/testing budgets, and things like that. If I'm
| delivering the interview to the candidate, I'm presenting the
| panel of reviewers not my opinions on the candidate, but what
| they came up with.
|
| The same approach works for general software development (we
| don't use it here, we have an even fussier process). You can do
| design exercises, you can work out the dependencies that are
| going to be needed for a particular complicated project, you can
| do estimation exercises, you can catalog likely bugs. Review some
| PRs together. Look at the day-to-day work your team does, and
| then make the exercise a model of that work.
|
| It's not especially easy to do compared to just sitting down and
| asking a bunch of questions. Moreover, it's _very hard_ to adopt
| it as a practice, because you have to trust the rubric (iterating
| on it over time, but using it enough for it to be meaningful) and
| not override it based on extrinsic considerations (referrals,
| misgivings about candidate background, &c).
|
| But the upside is pretty obvious? Once you have it worked out,
| you get a repeatable process, something that is naturally geared
| towards iteration and improvement.
|
| Standardize your interviews, generate data, have a panel make the
| decisions and not the interviewer.
|
| You can still play the interview like D&D if you want!
| dangus wrote:
| This sounds like a regular situational interview?
| breadchris wrote:
| wow awesome analogy. I got rejected because my leet code solution
| wasn't fast enough for a security engineer position. The person
| who referred me was furious. Meanwhile, another interviewer did
| just this to me and it let me flex my knowledge.
|
| Would love to see this more. There is also the inevitable future
| where someone publishes a book on it and it gets cargo-culted.
| C'est la vie.
| kqr wrote:
| This is called _simulation_ and it is a useful tool both when
| selecting for and training for cognitive skills.
|
| Importantly and usefully, simulations for cognitive work do not
| require any sort of physical fidelity, so it's really easy to set
| up basic scenarios like for hiring.
|
| (The main cost in using simulation for training lies in designing
| scenarios that train for expertise. That takes slightly more
| advanced elicitation methods which fall under the umbrella of
| cognitive task analysis.)
| randomgiy3142 wrote:
| A good interview should be a good fit for both parties. Just have
| a casual lunch with them. You should be able to tease out if they
| are a good fit. These "hacks" are so ridiculous. Way to overthink
| something.
| neuralzen wrote:
| I went through something similar once when I was interviewing for
| an IT position in the Antarctic (I'd applied for positions at
| both McMurdo and Amundsen-Scott), and I was supposed to connect
| to their network simulator to troubleshoot and solve some network
| issue, but it wasn't working on their end so the interviewer
| walked me through the scenario, and responded as a DM would. -
| Quite frustratingly this was my 3rd interview for the position,
| and although I diagnosed and solved the DM'd scenario of a downed
| vlan issue in a Cisco environment in ~5 minutes of this off-the-
| cuff "simulation" using DM provided prompts, help menus, and
| outputs, I did not get the job. I think he penalized me for
| relying on the DM provided help menus and auto suggest
| tabbing...which is something anyone on a working simulator would
| have done. Which was a bummer because even though I was
| overqualified for the positions and would take a pay cut, I
| really wanted the experience of living for months in the
| Antarctic. So while I see the usefulness of this kind of
| interview, there are noteworthy issues of bias which a real
| simulator wouldn't begrudge you.
___________________________________________________________________
(page generated 2024-02-10 23:00 UTC)