When I was interviewing candidates at IBM, I came up with a process I was really happy with. It started with a coding challenge involving several public APIs, in fact the same coding challenge that was given to me when I interviewed there.
What I added:
1. Instead of asking "do you have any questions for me?" at the very end, we started with that general discussion.
2. A few days ahead, I emailed the candidate the problem and said they are welcome to do it as a take home problem or we could work on it together. I let them know that if they did it ahead of time, we would do a code review and I would ask them about their design and coding choices. Or if they wanted to work on it together, they should consider it a pair programming session where I would be their colleague and advisor. Not some adversarial thing!
3. This the innovation I am proud of: a segment at the beginning of the interview called "teach me something". In my email I asked the candidate to think of something they would like to teach me about. I encouraged them to pick a topic unrelated to our work, or it could be programming related if they preferred that. Candidates taught me things like:
• How to choose colors of paint to mix that will get the shade you want.
• How someone who is bilingual thinks about different topics in their different languages.
• How the paper bill handler in an ATM works.
• How to cook pork belly in an air fryer without the skin flying off (the trick is punching holes in the skin with toothpicks).
I listed these in more recent emails as examples of fun topics to teach me about. And I mentioned that if I were asked this question, I might talk about how to tune a harmonica, and why a harmonica player would want to do that
This was fun for me and the candidate. It helped put them at ease by letting them shine as the expert in some area they had a special interest in.
"Teach me something" is how the test prep companies would interview instructors. Same idea—have a candidate explain a topic they are totally comfortable with—but they were more focused how engaging the lesson was, how the candidate handled questions they didn't expect, etc. moreso than I expect you would if you use this in a IC coding interview. It's a neat idea though, I can imagine lots of different ways it would be handy.
Kudos to you - this sounds like a fantastic interview format.
I especially like that you're prepping them very clearly in advance, giving them every opportunity to succeed, and clearly setting a tone of collaboration.
In person design and coding challenges are a pressure cooker, and not real-world. However, giving people the choice, seems like a great way to achieve the balance.
Honestly, I'm really just commenting here so that this shows up in my history, so I can borrow heavily from this format next time I need to interview! :) Thanks again for sharing.
That sounds really cool. I wish I was running into more job interviews like the one you describe. The adversarial interviewing really hurts the entire feel of the process
I don't remember how I came up with the idea. Maybe I just like learning things.
One candidate even wrote after their interview, "that was fun!"
Have you ever had a candidate say that? This was the moment when I realized I might be on to something. :-)
Interviews are too often an adversarial thing: "Are you good enough for us?"
But the real question is would we enjoy working together and build great things!
People talk about "signal" in an interview. Someone who has an interest they are passionate and curious about and likes to share it with others? That's a pretty strong signal to me.
If this became popular, wouldn't people start rehearsing for it like they do Leetcode interviews, and it would be become another performance that people focus on and optimize for, rather than on the skills for the job?
Rehearsing how to teach something is not a bad thing.
And I'm sure you're going to get different questions about different aspects of the things you're trying to teach from different interviewers. The wonderful thing about this is that it models trying to teach a concept to a fellow coworker. How you handle the questions during the teaching time says a lot about the candidate.
Or would it train people to choose topics very carefully, such that a little teaching skill goes a long way?
It's not like the interviewer getting a lesson in tuning a harmonica is going to bust out a harmonica and start putting his newfound knowledge to work, or revisit the subject in 6 months to see if he's retained the knowledge, or bring in a panel of harmonica tuning experts to check there weren't any major gaps or mistakes in the lesson.
I think the lesson to be learned from the parent comment is to put candidates at ease and let them express their interests. I think it doesn't matter if you chose to use "teach me something" specifically. However, it does matter how to try to be accommodating towards the candidate either by asking about their hobbies, some recent news any fond memory/project etc.
I forgot to include something important in my initial comment. In my introductory email, I explained that the "teach me" segment is completely optional.
If someone didn't want to do it, that's fine and wouldn't be held against them. In practice, I think one person out of 20 chose not to do it.
And if they weren't a great teacher, that was fine too!
The purpose of the segment is to give the candidate a chance, if they want, to shine at something they are interested in, and help put them at ease by letting them start out being the expert.
I think the point is to remove the adversarial aspect and therefore see how they react when not under pressure. I wouldn't be surprised if OP does warn their candidates about it.
You have it exactly right. I always told the candidate in my introductory email that the segment is optional and I like to learn all varieties of new things and they should feel free to pick any topic they want.
And then when they were teaching me, I made sure to pay attention, ask questions about anything I didn't understand - not to judge their teaching skills but to show I was interested and listening.
I immediately want to learn about all these cool things you listed.
I work as a developer and as an interviewer (both freelance). Now I want to integrate your point 3. into my interviews, but not to choose better candidates, just to learn new stuff I never thought about before.
It is your fault that I see now this risk in my professional life, coming at me. I could get addicted to "teach me something".
'Hey candidate, we have 90 minutes. Just forget about that programming nonsense and teach me cool stuff'
You just need a small file, like a point file. Any gasheads remember those? And a single edge razor blade or the like to lift the reed.
To raise the pitch, you file the end of the reed, making it lighter so it vibrates faster.
To lower the pitch, you file near the attached end of the reed. I am not sure on the physics of this and would appreciate anyone's insight.
The specific tuning I've done many times is to convert a standard diatonic harp (the Richter tuning) to what is now called the Melody Maker tuning.
The Richter tuning was apparently designed for "campfire songs". You could just "blow, man, blow" and all the chords would sound OK.
Later, blues musicians discovered that you could emphasize the draw notes, the ones that are easy to bend to a flat note to get that bluesy sound. This is called "cross harp". For example, in a song in G you would use a C harp instead of one tuned in G.
The problem with cross harp is that the 7th is a minor 7th and you have no way to raise it up to a major 7th if that would fit your song. And the 2nd is completely missing! In fact you just have the tonic (G in this case) on both the draw and blow notes where you might hope to hit the 2nd (A). There is no A in this scale, only the G twice.
To imagine a song where this may be a problem, think of the first three notes of the Beatles song All My Loving. It starts with 3-2-1. Oops, I ain't got the 2. Just the 1 twice.
This is where the file comes in. You raise the blow 1st to a major 2nd. And you raise the minor 7th to a major 7th in both octaves.
Now you have a harp with that bluesy sound we all love, but in a major scale!
Re: lower pitch, I'd hazard a guess that you're basically reducing the restoring force, so the resonant frequency goes down. Think of the attachment point as a bunch of springs in parallel; you snip a few of them and the overall spring constant is reduced. Or another way to think of it: Imagine you had a reed of a given width and then added mass to the end by making it wider at the non-attached end. You'd expect the frequency to go down.
I'm sometimes tuning accordions, which is rather similar, but if you want to lower the tone by a lot, you can plop some solder close to the tip of the reed.
It's pretty clear why that's the opposite of filing off material close to the tip, so obviously the tone goes lower.
In my mental image, filing close to the base of the reed gives the reed a similar shape as putting extra material next to the tip (thinner at the base, thicker next to the tip), and that's why it behaves the same.
The solder on the tips reminds me of a doctor visit years ago. I thought I may have broken a finger, and when I got to the doctor's office I mentioned to the receptionist that I had a high-deductible (HSA-compatible) insurance plan.
The physician's assistant said, "We could send you over for an X-ray, but since you're paying out of pocket, we can start with a simple test." He pulled a contraption out of his desk drawer and asked, "Do you know what this is?"
I said, "Yeah, a tuning fork. And based on the size and those heavy weights on the tips, it must be tuned to a rather low frequency."
He said, "Yep. So we get it vibrating and then touch the base to your finger. If you have a fracture, it will hurt because of the broken bone ends jiggling against each other. Then we will go for the X-ray to get more details. If it doesn't hurt, you are good to go. Is that OK?"
"Sounds good to me!"
It didn't hurt at all, and I just had to pay for a simple office visit instead of an expensive X-ray.
Probably so. Or in some cases, multiple resonant frequencies all at once, like a bell. I asked my friend Miss Chatty (ChatGPT) about this and she had some interesting insights:
Once we are there, it then is all about techniques. Working from first principles is going to get us there, but there are likely pitfalls, traps, all manner of gotchas laying in wait...
And there we now have a basis for further discussion.
I spent a decade and change doing adult instruction in CAD. Early on, many were still transitioning off 2d hand drawings. Boy, was that an art! I got to do a few the very old school way and have serious respect for the people who can produce a complex assembly drawing that way. Same for many shapes that may feature compound curves, for example.
But I digress!
Asking them what they wanted or would teach me was very illuminating and frankly, fun all around! I was brought a variety of subjects and not a single one was dull!
Seems I had experiences similar to yours.
One of my questions was influenced by someone who I respected highly asking, "what books are on your shelf at home?"
This one almost always brought out something about the candidate I would have had no clue about otherwise. As time advanced, it became more about titles because fewer people maintain a physical book shelf!
I am! But I am now on the other side of the virtual table.
IBM conducted a mass layoff a few months ago, and as our little team lost our only customer at the time (this is public information), many of us were let go. Ah well.
One door closes, another opens.
If anyone out there is curious about "who is this guy with the strange and interesting ideas about interviewing", you can find my LinkedIn and other contact info in my HN profile.
I love this. I hope you don't mind, but I'm going to steal it for when I am back in the saddle interviewing folks. We need much more of this and a lot less of the adversarial BS.
(3) is biasing the process strongly in favour of people who spin a good story. If you're looking for a certain team culture then OK but this is going to neatly screen out anyone who just wants to do their job well and doesn't particularly know how to sell the extra-curriculars they have.
Sure, they can do that. Then the average interviewer is going to recommend hiring the person who was the best at spinning a good story rather than the person who has the clearest explanation (which might easily come across as boring or simplistic). The problem here isn't getting through the interview; it is what the interviewer does next in the hiring pipeline.
Somehow this reminds me of my old physics professor, who often had simplistic, almost boring explanations of things, like jiggling atoms making friends with each other, or how a train stays on the track.
... Classic interviewing techniques of "explain how X algo works" or "write code to solve Y" will unfairly bias against interviewees that don't test well under pressure, but would otherwise be a good coworker.
... "Teach me something interesting to you" or "tell me stories about past experiences" will unfairly bias against interviewees that are shy, soft spoken, or are mildly socially awkward, but would otherwise be a good coworker.
Given the above awareness of where bias can emerge, how should the interview be done in order to get a candidate that knows what they're doing, and works well with the rest of the team?
Other comments mention relying more on recruiters and referrals, but that isn't always an option.
I don't see what useful signals are supposed to come out of an interview. If referrals and recruiters aren't an option I'd probably try to skip the interview altogether and go with a long probation period (3-6 months). Or possibly have a short 20 minute free-form interview talking about their last day job and expectations of the new one with a very short list of major red flags ("doesn't want the job", "unable to form sentences") then block candidates who raise them.
- How do they take a business problem and model it into code
- How do they debug their own code
- Is their code easy to read
- Do they name their variables/fields/methods/classes in easy to understand and consistent ways or are the names confusing or inaccurate
- How do they take constructive criticism
- How collaborative are they
- Do they think about the problem first or do they just start hacking away
- When asked to add a feature to existing code, do they start hacking or do they write out a test describing the new functionality first
- When confronted with vague requirements, how well do they ask questions to get the information they need
- How much experience do they have with algorithms, database design, systems design, building things so they scale well
If it were possible to work all that out in the interview then there wouldn't be any bad hires.
As a wishlist I like it, I just don't see how you're going to assess all that in an interview. You'll notice that the technique of the day ("teach me something") doesn't address any of the dot points and that holds for ... pretty much any technique. Interviews are a weak process for assessing anything.
The long probation approach completely ignores the very real costs of onboarding someone new.
It takes time, money and people to bring someone in, and hiring is actually quite a risk for many companies (unless they're huge and/or in a hiring frenzy).
If a candidate doesn't work out, that's a lot of time and money down the drain, and potentially lost work, and disruption to teams and timelines, etc..
Most people don't get this part, and I think that's why they don't understand why interview processes are structured the way they are.
You really want to do the best possible evaluation, on all fronts, at the start. The longer a bad candidate stays in your pipeline or company, the more expensive and disruptive it gets.
Specifically for engineering I think it could work if you really press on that it's about teaching something. A core part in an engineering team is to walk eachother through concepts, so judging how you can explain concepts to someone is actually a good thing i believe?
A big part of any engineering job is casual technical communication. This seems like it's entirely fair line of questioning. And the candidate gets to pick their strongest topic. What more do you want?
I don't think this approach favors the talkers / story spinners too much. It is the other way around!
It is a nerd test. You can get every nerd talking if you ask them to tell you about a special skill or project they really care about.
I remember quite a lot of these lunch conversations:
Me: Hey, what's up? Do you like the salad?
Introvert Nerd: Mmmm-Hmmm.
Me: Great weather outside!
Introvert Nerd: Mmmm-Hmmm.
Me: I was hiking last weekend in the mountains and got caught in a storm.
Introvert Nerd: Mmmm-Hmmm.
Me: Does your work project proceed well?
Introvert Nerd: Mmmm-Hmmm.
Me: I've heard that you regularly cook medieval dishes and you created a food medievality detector using a Raspberry Pi and a horseshoe?
Introvert Nerd: Oh, yes! You know, measuring the medievality of a dish is not as simple as it sounds! Obviously, there are no American foods like tomatoes or potatoes allowed, but did you ever think which spices were common in Europe in the High Middle Ages and why that changed in the Late Middle Ages...
...
The problem is in leaving the topic of what to teach open. To some people, this may feel like freedom. To others, in the context of an interview where the purpose is to judge the candidate, it will just lead to a bunch of stress from trying to guess which types of things to teach are currently a la mode on the interview circuit.
For a fairly casual question I'd see it more like an ice breaker or a way to build some rapport, but it's down to how you ask the question as well. Letting people know in advance (as the parent suggested) rather than dropping it on the fly is a good enough accommodation for people who would be anxious about that.
I find interviews quite tense and I generally dislike having them (on both sides of the table), but throwing in a few disarming questions here and there throughout really takes the edge off. A conversational, or more cerebral, approach like that can suit some people far better than live code tests or quick-fire Q&A.
This post is some unintentional satire how IBM operates (nobody invents anything in IBM anymore).
The opening question is a copy of what was done before (probably by someone who doenst work at IBM anymore) and all the new stuff is stolen from outsiders.
I'm surprised at the negativity your approach seems to have sparked in a few, but I found it really great, probably very effective as well and will probably start to use it at some point.
Thank you! And please do feel free to use the idea, or change it and make it your own. The great thing is that it starts the interview with the candidate being the expert at something, and I am their student.
So was I! Frankly, having done similar things, I found their comment here lucid, well thought out and valuable enough to write some things in resonance.
My take is the negatives may just be people leaning hard on, "if it seems too good to be true...
> In my email I encouraged the candidate to teach me something unrelated to our work, or programming related if they preferred that.
What if I decide to teach you something about the Quran and you don't hire me?
Perhaps this is just urban legend but from the stories I've heard hiring for FAANG-type companies there are people out there interviewing with their only goal being baiting you into a topic they can sue you over.
Worst instance I have heard of is when an interviewer asked about the books the candidate liked to read (since the candidate said they're an avid reader in their resume) and he just said that he liked to read the Bible. After not getting hired for failing the interviews he accused the company of religious discrimination.
I'm by no means an expert in US law and don't know the people this happened to directly so maybe it's just one big fantasy story but it doesn't seem that far fetched that
- If you are a rich corporation then people will look to bait you into a lawsuit
- If you give software engineers (or any non-lawyers) free rein on how to conduct interviews then some of them can be baited into a situation that the company could be sued over way more easily than a rigid leetcode interview
I think nothing came of the fellow who liked reading the Bible but I would imagine the legal department has a say in what kind of interview process a rich company can and can not use.
I think you may have misunderstood the guidance from your legal team on this.
There is literally no way to prevent a candidate from disclosing a protected characteristic during an interview. Some obvious examples: they might show up to the interview in a wheelchair, they might be wearing a religious garment, they might be visibly pregnant, and so on...
What legal doesn't want, is you asking questions directly intended to elicit that kind information when the candidate didn't volunteer it. Asking the candidate a direct question like "are you planning to have kids?" makes it sound like that information will be used in the hiring decision.
Completely unrelated, but I find that other people will create problems by making an off-colour statement, something mildly offensive, or disrespectful and then when they get a reaction they say "why are you making a problem where none exists".
DARVO/gaslighting behaviour, and I wish it was rarer than it is.
I have found that if you tighten the parameters a bit, you can still get all the benefit of what this question is asking for. For example, teach me the rules of a sport, board game etc. You still get to see if they can present a coherent explanation of something relatively complex, but you can avoid these potentially dangerous topics.
People who are poor managers or in positions of power, but not emotionally regulated or unwilling to get therapy, find blaming others easier than self awareness and doing the work of bettering themselves. Couple that with financial success and why should they when all our society values is how big your bank account balance is.
and like you said it's not that deep. pick something light.
a candidate that pulls the religious thing now is one that's going to drag their crazy shit into the office later. or complete misread the room / culture now, and in the future.
like it's a technical job interview, talk about something vague technical, even if it's just how the convection settings work in your oven.
Companies with armies of attack lawyers riding helicopter gunships don't make great targets for this kind of thing, in general. I shudder to think about trying to take Apple or Disney to court.
It's somewhat overblown - obviously anyone can try to submit a demand letter about anything. My experience with legal in the hiring process is they want to avoid obvious own goals, and document the process so that clear reasoning can be expressed. Then, unless you really do something obviously discriminatory, you can tell people who claim they've been discriminated against to go pound sand.
There are lots of good tactical reasons to settle claims like that, so lawyers may advise you to settle, but if you're of the "we don't negotiate" mindset, in my experience most lawyers are quite happy to gear up for a fight with the right groundwork in place.
What I added:
1. Instead of asking "do you have any questions for me?" at the very end, we started with that general discussion.
2. A few days ahead, I emailed the candidate the problem and said they are welcome to do it as a take home problem or we could work on it together. I let them know that if they did it ahead of time, we would do a code review and I would ask them about their design and coding choices. Or if they wanted to work on it together, they should consider it a pair programming session where I would be their colleague and advisor. Not some adversarial thing!
3. This the innovation I am proud of: a segment at the beginning of the interview called "teach me something". In my email I asked the candidate to think of something they would like to teach me about. I encouraged them to pick a topic unrelated to our work, or it could be programming related if they preferred that. Candidates taught me things like:
• How to choose colors of paint to mix that will get the shade you want.
• How someone who is bilingual thinks about different topics in their different languages.
• How the paper bill handler in an ATM works.
• How to cook pork belly in an air fryer without the skin flying off (the trick is punching holes in the skin with toothpicks).
I listed these in more recent emails as examples of fun topics to teach me about. And I mentioned that if I were asked this question, I might talk about how to tune a harmonica, and why a harmonica player would want to do that
This was fun for me and the candidate. It helped put them at ease by letting them shine as the expert in some area they had a special interest in.