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

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

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

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

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

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.

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.

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.

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.

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

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

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

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.

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

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.

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

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.

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.

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.

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.

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.