Anyone ever consider bringing a coding exercise for the interviewers

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

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

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?

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

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

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.

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.

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.