Ask HN: Anyone ever consider bringing a coding exercise for the interviewers | Hacker News Reader

Ask HN: Anyone ever consider bringing a coding exercise for the interviewers

68 pointsciwchris88 comments

Someone was asking how to determine the quality of coding practices at places they are interviewing. My mind went on a tangent wondering if it is fair for interviewees to bring a coding exercise for the interviewers to complete. I've heard that interviews are an opportunity for both sides to interview each other? So does the interviewee have an equal opportunity to determine how the interviewers work through problems by presenting their own exercise for the interviewers to complete, and therefore gain insight on the company's practices?

I've never heard of anyone doing this before and I don't think it would be well received. Has anyone done this? For anyone who conducts interviews what would you think if someone did this?

View on HN

I did something like this on the interview for my current role! It's not exactly what you asked about, but I'll describe it in case you find it helpful.

The technical interviewer gave me an algorithm question that I fielded for an interview for another company. I said I've heard it before, and asked if there was a backup question we should switch to. The interviewer said we should go ahead and I basically just dropped the optimum answer and live coded it. I mentioned I would be rustier on the "harder version" of it that comes next, and found out he wasn't familiar with that particular twist. I asked if I could give it to him and we could work it out together, and he said yes. So we spent the rest of the half hour laughing with me sort of leading him through a more challenging form of the question and working it out together.

I don't think this would have been successful if I went into the interview with a random Leetcode question in my back pocket and awkwardly asked for someone to work through it for me. However, if it comes up naturally for you like it did for me, it can be a very fun and rewarding experience.

This sounds pretty much ideal. Two people [vaguely] familiar with a problem working through it together. Both have the opportunity to evaluate each other. This is exceedingly rare in practice. Obviously you got (and accepted) an offer.

Some of the best interviews I've given and taken have gone roughly this way. It's nearly impossible to set this up intentionally, though.

do pair programming on any coding problem. could be a live one from your actual work, or some FOSS project using a similar tech stack

you should have asked him to build something you built in the past, which you needed several hours for, and ask him to do it in one minute. only then would you solve his question.

that is hilarious and awesome. Did you enjoy working with them, and did you think tackling a newer unseen problem with the interviewer as a peer showcased your skills well? I wondered if that would be a better experience (having the interviewer unfamiliar with the question as well, or something like that).

Power move

This would be a waste of your time.

You have limited, precious time in the interview to learn about the company, their management practices, how they operate as a company, their growth history and plans, the composition of the company beyond the people you're interviewing with, and so on. Giving a single interviewer you're interfacing with a coding exercise would waste all of that valuable time.

A coding exercise would also be testing the wrong things. Often, the person running point on your interviews isn't a programmer in their day-to-day activities. At a tech company they likely have some technical background, but if someone has been a manager for 5 years and isn't coding day-to-day then what do you actually expect to get out of giving them a coding exercise?

As a hiring manager, if someone tried to give me a coding exercise I'd probably try to be a good sport and see if we could work it in 10-15 minutes, but I'd also be questioning the person's level of experience and maturity in the workplace. Hiring manager and IC developer are very different roles, and trying to give your hiring manager questions that don't explore their management style or how the company operates suggests that they don't really understand how the relationship is supposed to work.

They may be very different roles in practice, however IME the better managers (of coders) are also coders. You probably don’t want someone being your boss who can’t do your job if need be. It’s a skill necessary but not sufficient, as they might say in academia.

> Often, the person running point on your interviews isn't a programmer in their day-to-day activities. At a tech company they likely have some technical background, but if someone has been a manager for 5 years and isn't coding day-to-day then what do you actually expect to get out of giving them a coding exercise?

We always let a manager and a developer do the interview, and for good reasons because they both have a unique perspective on whether someone fits in the team.

I’ve been this developer in a lot of interviews. We don’t typically do in-interview coding questions so it would be a little weird if someone just threw one at me — although I guess it would depend on the context of the question.

My style of interviewing is to have a as casual a conversation as possible with someone about their experience, ask them to do a deep dive into a solution they’ve delivered, what they could have optimised better, what they learned in the process (technical or otherwise), what were the pain points, etc etc.

I find the best applicants get me talking quite a bit about related projects we’ve worked on. It fits the flow of the interview, which is important. Asking me to whiteboard a random algorithm would be bizarrely out of place, but i’ve 100% whiteboarded hypothetical architectures while responding to questions from applicants. If we’re to that step then it’s usually a pretty good sign.

It is not a waste of time if you are also doing a code exercise, they can be doing one at the same time.

Instead of coding interviews, I suggest asking behavioral questions. Why? Because you can easily ask them when they say "Do you have any questions for us?" No one will think it out of place.

The reason I ask them? To expose the fact that behavioral questions are being gamed by candidates. Not once has an interviewer given me a good response. If they expect candidates to have good responses, they'll get a lot of candidates who memorized scenarios that may never have occurred - and they cannot distinguish between the sincere and those gaming it.

To give you an idea: A former Amazon employee was coaching me for their behavioral interview. For those unfamiliar: You look up Amazon's 14 leadership principles, take each clause in their descriptions, and come up with scenarios demonstrating each clause. His advice on how to prepare for it? If nothing obvious in your work history demonstrates the behavior, make something impressive up and memorize it.

Of course, Amazon's behavioral interview is probably the easiest to game, as you essentially know most of the questions in advance. Probably over half of the ones I was asked were straight from their descriptions (e.g. "Give me an example of a time you disconfirmed a hypothesis.")

> Of course, Amazon's behavioral interview is probably the easiest to game, as you essentially know most of the questions in advance

The devil is in the details. Once they will start probing, the candidates who had made up stories would start floundering.

There's a magical escape hatch for this known as "I can't quite recall". The truth is most interviewers don't know how to properly evaluate the authenticity of a story and won't accord it much weight relative to the coding challenges anyway. You'll probably get through if you can pass the Leetcode portion and just bullshit well enough on the behavioral.

All the police procedural propaganda makes people over estimate how well they'd discern fact from fiction.

> There's a magical escape hatch for this known as "I can't quite recall".

Indeed. I don't know how Amazon would evaluate that, but one probably should be wary if the candidate knew much of the details.

Except they shouldn't, because Amazon forces you to come prepared with these stories, and penalize you if you don't come prepared with these stories.

You know you're in a hacker forum, where people "make up" solutions to imaginary scenarios all the time.

Easy to handle this:

1. Pick an example from work where a coworker exhibited the behavior and you're intimately aware of the details

2. Pick an example from work that didn't go the way Amazon would have wanted it, but fantasize about how it could have. I think those who've worked long enough have plenty of tales to tell that didn't quite happen that way in reality, but make for a better narrative. Just adopt one of those. Do you think most of the comments people post on HN with experiences from their workplace are 100% accurate? Do you think they needed to spend a lot of time crafting that narrative? No.[1]

Both of these don't even require much prep.

[1] Edit: Heh - see sibling comment - written while I was writing mine:

https://news.ycombinator.com/item?id=31983353

Amazon's hiring practices are the biggest tell of a sociopathic organization that you should only work for if you have to.

If you are good enough to "raise the bar" at Amazon, then you should be good enough to get a better job somewhere else.

What Amazon hires for is insecure people desperate for the Amazon stamp of approval and willing to be exploited for insane work hours and discarded before their compensation vests. That's what their hiring process selects for, not actual talent.

Then the abuse REALLY starts when you get there.

> What Amazon hires for is insecure people desperate...

They prey on that subset, but they hire for disposable warm bodies in general.

I worked for them for not quite a year, and quit, because it was so absurd how incompetent the many layers of management above were, who took home massive pay for emailing and deriding talented engineers they knew little about.

Disclaimer : I'd already saved more than enough to retire young, so didn't need to work there, just thought it interesting, am pretty sure was assigned to backfill a hire-to-fire departed warm body, and was quickly keenly aware of the scam almost ponzi scheme they run, having spent several years at Apple which was run excellently (where I was).

Did you do their hiring gauntlet just for practice?

no, trusted the jobs to which i could be assigned would be interesting development, but was wrong

> Give me an example of a time you disconfirmed a hypothesis.

So far, all of my hypotheses have been confirmed.

If this is genuine, it's a good indicator that more information can be obtained by making more risky hypotheses. If a joke then woosh on me. :)

Yes, behavioral questions aren't perfect, but I do believe they still serve a purpose. Sure, candidates will embellish and make up stories. Still you are able to weed out candidates who are an obvious bad match, or identify potential gaps that might need to be addressed after a hire.

My point isn't that behavior isn't an important factor - I think it's more important in predicting success than technical skills. The problem is this:

How many of your existing employees don't have these behavioral deficiencies that you're trying to root out? If you suddenly gave existing employees a behavioral interview, how will they fare?

Conventional job interviews are bad from the viewpoint of the interviewees is that even though the function is to hire somebody, the process is fundamentally a rejection process. It is in everybody's interest to disrupt this process.

One of the greatest job interview hacks is this:

Imagine yourself as a consultant who is there to solve a problem for the business right there in the job interview and you can tell them that is your goal. Take advantage of "do you have any questions for us?" to probe deeply on a problem they have: sometimes you can get people talking for hours and get a lot of information.

This works best at small firms, say 20 employees, where you can talk to the principals. Big companies like Google have a structured hiring process precisely to defeat this and other interview hacks.

I have.

A couple years ago, I had a phone interview with one of the big tech companies. The interviewer almost immediately started asking a series of pretty basic questions - something a new grad should be able to answer, where if you can answer one, you can answer them all. I don't have an issue with couple of questions like that to verify the info on my resume is accurate, but he was going on and on with them.

I told him I had a question for him and gave him the question. He giggled and said, "That's an interesting question", then started to ask me another question. I stopped him and asked him to answer my question. He said something along the lines of "this isn't for me to answer your questions".

I ended the interview. I don't think I would have liked working there.

I haven’t done this but I had a fun experience grilling my interviewer on the relevance of the technical interview. My interviewer worked at a company specializing in virtualization technology. The interview was done remote, and this technical interview was the first step.

I was asked to program a mildly challenging problem, the very type of problem you’d see in cracking the coding interview.. mind you I hadn’t done any prep before because my personal stance was that a true technical interview will gauge what I know on the spot, and not what I’ve crammed or pretend to know.

Sooo, it went as you would imagine. I very slowly talked through the solution with my interviewer and while I was able to solve the problem, it took me all of about 30 minutes at which point the interviewer politely told me it wasn’t going to workout and was happy to give me constructive criticism.

His first feedback: Your problem solving is sound and you’re on the right track, you’re just way too slow. A good candidate solves this first problem in less than 10 minutes and also solves our second problem. You didn’t even get to the second one.

It was at this point I thought, “screw it, nothing else to lose so why not go for the brutal honesty approach.”

Me: how often do you solve a problem like this in your day-to-day?

Him: Oh never, this has nothing to do with the position we’re hiring for.

Me: So why is this part of the interview process?

Him: For the time being, there’s no other way to gauge programming talent in a short period of time.

It was at this point I was happy the interview went the way it did. This company would rather hire worker bees who cram technical challenges as opposed to someone who took the time to slowly think through a problem they hadn’t practiced.

Since then, I built a platform to hire junior and senior talent at my company which emulates a task a junior or senior developer may be given within their first few weeks. The challenge is simple although a bit time consuming. What’s amazing is that although we tailored the challenge for what we thought a good junior developer could handle, it actually has done an excellent job at weeding out senior developers who certainly were not senior by our standards and for the type of work we would expect a junior to be capable of.

Our challenge was to retrieve data on a regular interval from an intentionally buggy API, and visualize the data. Any language or tool was fair game.

Can you believe it? A challenge that actually asks people to do a task similar to what they’ll do on the job?

> The challenge is simple although a bit time consuming.

This is really the problem though. You can't ask an interviewee to do anything too time consuming if you want senior people, who often have kids or are otherwise busy.

We ended up explaining the challenge and giving them access, plus up to two weeks to submit. (We’d always give more time if they asked).

They could do it whenever on their own time, and then we scheduled a 1 hour time block to review their code. Some people took an entire weekend, some people took an hour. Sure people are busy but at least this method also gives them the opportunity to see if they’d like to do the type of work we do, as well.

Overall ended up with really great hires who seemed to enjoy the challenge.

An interview process is successful if you hire candidates which turn out to be a good fit both ways.

An interview process is fair if you don't exclude any candidates that would have met the criteria if not for the lousy interview process.

While you seem to be enjoying the former (for now), you are intentionally or accidentally narrowing the pool, and mistreating a number of your candidates.

If intentional, the word will get out, even if it takes a while. If accidental, I hope you work to improve the process.

>We ended up explaining the challenge and giving them access, plus up to two weeks to submit. (We’d always give more time if they asked).

Sorry, but I'm not spending "up to two weeks" to answer some made-up problem you have for me

I have better things to do in life (like kids, current job, hobbies, etc)

I like your platform. I was making a special service for recruitment at intel. Your task was to talk to its api, but this api would return inconsistent results, sometimes fail etc.

Now this was for me a typical day, dealing with some intranet service/app. Generally your job is to retry, figure out which endpoints offer more valid/up-to-data data etc. A lot senior engineers would either be lost or would halt and respond that the service needs fixing before any work can happen (they were aware that this service is buggy and its your task to deliver best effort results).

I interview a dozen people every month.

If a good candidate brought me a coding exercise, I would schedule a time to do it.

Why? Because I want them to know the quality of the people they're working with. I want to sell my company.

(I would not do this for a bad candidate.)

two real stories -- one is a successful but small company whose products I admired; I brought a demo that I wrote and showed it in the interview (yes this did actually happen long ago), I then asked the interviewer directly "how did I do this?" .. he was the engineering manager for all the coders, founder level and had an actual PhD in physics.. ten years older than me perhaps.. and, of course he did not know! he was a good sport about it. He was impressed! tricky graphics.. honestly I did get further but I wanted more money than they wanted to spend so it didnt happen. Second story is that I interviewed at Giant Company with a technical manager, who asked me a coding question about operating system code.. I had actually studied the OS source code for that particular part in the week before the interview. I then recited a lengthy and detailed description of the OS mechanism and afterwards, knowing I had hit the right points, I asked him -- how is it that you know about that, it is pretty obscure. He confidently leaned back, no drama, and replied "you mention that in your resume so I asked about it. I thought it would be a good question" .. he had no previous exposure to that topic and basically admitted it. (all before this hazing style become "standard").

ps- the first time I saw the hazing style interview was a group of technical project managers from Microsoft, on the campus of Apple, interviewing for a certain project. I suspect Google picked it up partly from Microsoft, who designed the method to control the interview and watch the response from the candidates. I asked "dont you want to see examples of my actual work?" and the frat-guy type said "no" flatly. also long ago...

I enjoyed reading the recent post here about interviews at Google where a introverted hardware guy was literally pursued by Google, and when he went for the interview, they started doing this "grad school algorithms" routine on him. Who here knows hardware? its not the same subject .. anyway, best to all

I'm not sure I understand the point you're making with your story - the technical manager wasn't 'hazing' you, they were simply trying to validate your cv against reality by making to talk to what's on there in detail. Are you suggesting what he did was a bad interview practice?

Would you prefer to be asked questions unrelated to your CV?

> "you mention that in your resume so I asked about it. I thought it would be a good question"

Sounds pretty reasonable to me. I ask people about relevant experience they've listed on their resumes all the time.

I do the coding screening interview for my company, a semi-large-ish private Bay Area company. If you tried to pull this, it would just result in either you failing the screen due to not completing enough of the problem (or any, depending on if you were willing to do the screen question we asked you), or you'd waste the 10 mins we reserve at the end for you to ask any questions you have when you could be asking a fellow engineer questions about what the work is like etc

You wouldn't fail due to my discretion by the way, I don't have a lot of leeway - to reduce bias, I can only pick one of a few questions to give, and I have to grade you against a rubric. So to pass you'd literally need to get xyz things on the rubric, and if you spent much of the time trying to screen me, I wouldn't be able to check them off for you.

The rigid format is not how I'd do interviews personally? And if it were more free-form id probably be at least intrigued by what question you posed me. But interviewing isn't very well-rewarded work at my company so the dominating strategy as an IC is to do anything you can to minimize the time footprint that interviewing inflicts upon you. Alas.

Anyway, my point is, it's an intriguing move but you're gambling on what kind of interview process you're in.

Your place sounds hellish to interview with, to be perfectly honest. Rubrics?

Yes, Rubrics. You want standardized non biased interviews, right? "Standardized non biased" often translates into bureaucratic.

Same reason they're used in grading. How else do you ensure that "partially correct" is consistently weighted?

Certainly, in college, I recall one calculus problem, we had to find the local maxima or minima of a function, something along those lines. Long and short, I differentiated, plugged in for zero, and made an algebra mistake, got one right, one wrong. Something like that. 5/10. Someone else...differentiated, and ended with the differentiated function set equal to zero, but didn't solve for it. 8/10.

No idea if that was a lack of rubric, or a badly worded rubric ("got one of the maxima/minima wrong = -5 points", "Well, he didn't get either one wrong, so..."), but yeah, a good rubric would have prevented that inconsistency in grading that I still carry with me to this day because it was so unfair.

No, I don't. Because engineering mindset isn't something you can quantify, and I don't care if a senior position isn't able to rattle off all of the 2xx HTTP status codes from memory. Having a conversation with candidates instead of ticking off boxes gives me the absolute strongest signal every time.

This is somewhat of the norm at large places isn't it? I've done interview rounds and was given example questions and more or less told to stick to it otherwise "liability" and "personal bias"

Not everywhere, no.

> If you tried to pull this

> the 10 mins we reserve at the end for you to ask any questions you have

What's that company so I can avoid it?

Every company bigger than 500 people I expect.

I’ve thought about this. It’s at best passive aggressive. Definitely don’t do it. Among the innovative interview techniques I have yet to see is one where the interviewee is allowed to customize the process. If you have projects you can showcase let’s see them, if not take this test. Seems simple but alien to anyone I’ve mentioned this too.

I thought about this. I think it would be incredibly difficult to pull of.

Doing that means that effectively you have +2 different ways to interview candidates. Ensuring consistency, fairness and a good candidate experience with one standard process is already hard enough. I suspect you'd have a really difficult time running this process successfully. Also, inevitably some candidates would find it unfair, and complain about the option the didn't choose.

> Someone was asking how to determine the quality of coding practices at places they are interviewing. My mind went on a tangent wondering if it is fair for interviewees to bring a coding exercise for the interviewers to complete.

> I've never heard of anyone doing this before and I don't think it would be well received. Has anyone done this?

Yes, I have done something similar to this and I believe it is important for an interviewee to ask. The way I phrase it usually is along the lines of, "what is a representative problem this organization currently has?" Then use that as an exemplar for a problem solving exercise.

It helps make the exercise "real" for the interviewers and allows the interviewee a glimpse into what problem(s) exist as well as how the panel feels about them.

While not strictly "a coding exercise for the interviewers to complete", it often leads to interesting discussions during the interview process.

Depends on how it’s done. You’d have to be quite the likeable guy to pull that off.

I think I would laugh and probably do it if it was a fun problem. I’d likely end up giving up on it.

Yeah I can imagine a candidate where I laugh and agree to do it, but I'd have to be in a good mood, like the candidate already, and not be super busy that week.

You can ask question of the interviewer but don't come across as a douche if your intent is to get hired. If I was interviewing you and it felt like you were about to try something like this then I'd terminate the interview and show you the exit.

Power move

In my last interview, the questions I was asked made me seriously question the technical chops of the hiring manager. It's cathartic to think about turning the tables like that, but no, that isn't a good use of anybody's time.

Here is my recent hack. I recently done it. It was a take away task and it was rated as excellent, they asked some questions etc. I have asked them to try and suggest what can be done better (I had a couple of ideas, I intentionally left to spot if they will pick up on them).

I think this strategy can be applied to live coding. Just ask them at the end what would they suggest to do better or if they see any other solution to this problem. They should now the tasks in and out if they use them, if they don't I would be highly suspicious.

Why do you think an interview has to be "fair"? These companies do not even pretend to abide by laws and norms around hiring and firing. They are going to try to see if you are useful, and how willing you are to be abused. If you try to abuse them, it will end poorly.

Let me tell you a story:

I've had a Google interviewer sit inches from my face and scream at me during what I later figured out was supposed to be a courtesy interview.

Was it "fair" that someone raised their voice when I asked to pause and think about their question, and then I flubbed every other interview that day?

Hint: No. I went to Tide House afterwards and joked with a friend I was happy to have made it out of the infamous "Google Gangbang", as folks used to term the multi interviewer sessions scheduled with folks who'd published at the conference I was at, with all my holes intact, since they were so notorious for having at least one interviewer behave in a manner that would get you maced, tazed, or shot if you interacted that way back home in Appalachia.

So let me be clear: You will never get a job if instead of trying to plan for antisocial behavior in the interview, you yourself engage in it.

Research the company, not the interviewer, and don't get cute...

(Unless you want to make a show of calling them out as a spy and you're interviewing with the feds. Apparently having someone straight up tell your staff "I'll fill out an SF-86, I just wanna make sure that information only goes to the US government" can trigger an investigation that gets several people fired, but somehow damage your career despite being an incredible patriotic, though admittedly asshole-ish move.)

I’m a technical EM, hopefully a good one, and I think having the skills and experience helps me a lot. That said, I’ve never tried to actually code something that went into production. That feels like a line I should only cross if it’s something arbitrary and random.

This felt uncomfortable at first, but having a strong dependency on the engineers (by not having a working development environment, really digging into the coding-specific things, or giving actual PR reviews, etc.) has actually really helped me not venture too close to what the engineers are doing. So even as a technical manager, I stay the fuck away. I get signal through other engineers. Most engineers won’t tolerate shitty code, so this works fine.

It forces me to rely and trust them for all of those things, which I think creates the symbiotic relationship between EM and IC. Any EM who does not embrace the idea of their engineers being better than them and does not think their success is directly tied to their engineers’ success is a shit EM. I read so many stories about shitty EMs on this site and it makes me sad for my craft.

I think a handful of technical "phone screen" style questions would be more reasonable, especially if you tie it into their code base/organization.

1. What are your thoughts on "functional programming"? 2. Define "functional programming". 3. Do you use a distributed database? 4. Define "eventually consistent"?

That kind of thing.

I tried that one time. I didn't get the job. Or rather... I got a job at the same company with a different group. The group I thought I wanted to work for turns out was pretty rigid and I probably would not have worked out there, so it turns out it was a decent thing to do.

I've performed hundreds of interviews and this never came up. If it happened, I would chuckle and say we don't have enough time. However I would offer the candidate to meet privately at some time after work and go through a coding exercise together, off the record.

If you want to signal poor social skills, by all means.

Everyone in the industry knows you need to prepare and study for these coding interviews. The interviewer already did that when applying for the company. Of course, they will be rusty if they try to solve one right there unless they are also actively interviewing somewhere else. Also, what kind of interesting signal is that going to give you? It's much better to ask questions about their feedback processes, how they ship software, team structure, exciting projects, etc. Besides money, those things make people leave or stay at companies. Not if your colleague can solve LC questions at any point in time.

I usually look to see if a company has public github repos for insight into their code base.

The thought of doing this has occurred to me before, but if someone actually did this in an interview, I would genuinely laugh, find it quite endearing, and I would 100% do my best to solve the problem in the remaining time.

I think there is a stroke of brilliance in this.

I don’t know about asking a coding question in-person, but I think it would work well for “take home” interview questions.

If you’re really interested in a company, but they insist you do a take-home problem, perhaps you could insist that they do a take-home of your design, as a fair trade. This would actually be a great way to see what the coding practices are like at the company, assuming they don’t take the request as an insult.

It would get a laugh; unless you absolutely smashed the rest of the loop, it wouldn’t result in an offer. IOW, it would be a huge negative EV move for most candidates.

Have three or four thoughtful questions (not necessarily technical) that you would like to ask the interviewer(s) at the end of your interview. In most interviews they would give the candidate an opportunity to ask questions or clarifications about the job. When they open it up, you can ask your questions.

If they don't, you can still ask, "I have a few questions and clarifications about the job. Would you be okay to answer them?"

I'm seriously tempted to try this just on a throwaway just to give it a shot. Sounds like it could be hilarious.

This is why I do all of mine in Haskell.

This is absolutely hilarious to me. I hope someone actually does this. I may do this.

I honestly don't really mind coding interviews but telling a company you'll solve their puzzle if they solve yours first actually seems like a completely fair deal to me.

No but it has occurred to me to ask the interviewer some of my favorite math puzzles. Or at least casually mention one in passing and talk about my innovative solution…. especially as a counter to their puzzle-type questions ;)

I don't bring "a coding exercise" for interviewers, but I do respond to pointless trivia questions with similar ones in return

Or I redirect from stupid trivia to what the interview is supposed to be about :)

> I've heard that interviews are an opportunity for both sides to interview each other?

This is true to the extent that you want but don’t need the job. If you’re desperate for the job, only ask what will help you get the job.

You could evaluate the interviewer that way, but IMO it's more valuable to evaluate the interview process since that will apply to everyone you would work with. If the interview is easy, expect to work with warm bodies.

Sadly I think most employers would take that poorly unless you had a strong justification.

I don't think that's fair mind you, but I probably wouldn't die on this hill.

I have turned the tables quickly when being interviewed by juniors, especially if I'm not sure of the quality of their programming.

As an interviewer if it took more than 5 minutes I wouldn't be doing it for you.

I used to bring this question with me to interviews in my back pocket, so to speak:

Two people, Alice and Bob, are each flipping a coin repeatedly. Alice will stop when she flips two heads in a row (HH). Bob will stop when he flips a head followed immediately by a tail (HT).

Who will flip the coin more times on average: Alice, Bob, or is there no difference?

I had come across it on Metafilter a few years ago:

https://www.metafilter.com/147228/You-blew-it-and-you-blew-i...

I figured if I ever got a whiteboard or coding problem where I was completely lost, I might try saying something like, "I have no idea how to solve this. But here's a fun problem I came across recently that we could work on together."

There were a couple times where I got a question I couldn't solve. But I never had the courage to pull out my backup problem.

I admire your preparation of a fallback brainteaser to throw back at the interviewers in case you ever get flummoxed, but I feel it would take some real storytelling skills or charm to "sell" this as anything but a desperate attempt at a switcheroo. (Maybe the fact that I'm so pessimistic about this tactic means I'm the kind of person who would definitely fail miserably if I ever tried it.)

Discussed here: https://news.ycombinator.com/item?id=11282480 And https://www.quantamagazine.org/mathematicians-discover-prime...

If the interviewee gets stuck just have them write a program and spit out the values averaged over many runs. This is what convinces a lot of people about the Monty Hall problem too

No, but if I really want a no hire I’ll give it a shot.

fucking legend. would love to hear what went down from anyone trying this.

I think it's fair to expect interviewee to solve 2 LC mediums in 45 mins given by the candidate. That's the current FAANG expectation. If a bad candidate is too costly for a company, so are a bad company too costly for a candidate.

So glad I've decided not to bother with FAANGs. I can spend two months in my "free time" re-learning algorithms I haven't touched in years (which have no practical bearing on my skills or experience), or I can spend time with my family.

yes, or you can spend it starting a new business.

the current FAANG expectation is solve a 2 hour problem in 2 minutes.

Reply on news.ycombinator.com