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?
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.
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.
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.
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.
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.
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.")
So far, all of my hypotheses have been confirmed.
The devil is in the details. Once they will start probing, the candidates who had made up stories would start floundering.
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:
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?
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.
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).
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.
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 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?
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).
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.
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.
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.)
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
Sounds pretty reasonable to me. I ask people about relevant experience they've listed on their resumes all the time.
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.
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.
> 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.
I think I would laugh and probably do it if it was a fun problem. I’d likely end up giving up on it.
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.
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.)
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.
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 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.
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 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.
Or I redirect from stupid trivia to what the interview is supposed to be about :)
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.
I don't think that's fair mind you, but I probably wouldn't die on this hill.
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.
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
