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?
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.
Deleted Comment
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.
Deleted Comment
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:
https://news.ycombinator.com/item?id=31983353
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.