Live data from Hacker News

Becoming a dungeon master for an interview

propelauth.com

31–40 of 181 posts

Re: Becoming a dungeon master for an interview

#31
post #26

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

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?

Re: Becoming a dungeon master for an interview

#32

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

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).

It also sounds like an interview that the company failed.

Re: Becoming a dungeon master for an interview

#33
> 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'.

Re: Becoming a dungeon master for an interview

#34

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

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).

Also a high level of frustration tolerance.

Re: Becoming a dungeon master for an interview

#35

Earlier quoted context omitted.

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?

[flagged]

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

Re: Becoming a dungeon master for an interview

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

Re: Becoming a dungeon master for an interview

#37

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

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

Re: Becoming a dungeon master for an interview

#39
post #26

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

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, an…

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.

Re: Becoming a dungeon master for an interview

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

Post reply on HN