this post was submitted on 25 Dec 2025
244 points (97.3% liked)
Programmer Humor
39640 readers
566 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't have experience with interacting with these questions in an interview, but I think these questions are supposed to be a test of problem solving ability, which could be relevant in some jobs like programming, I suppose. I still think it's stupid though.
This question in particular I'm pretty sure has a BS "outside the box" answer, where "outside the box" really means "the question is very misleading and to solve it you have to realize that when we explained this scenario, we heavily implied a set of abstracted rules you could try to solve, but we actually want you to "think outside the box" and come up with a different set of rules that, if you thought we were asking this question in good faith, you would have assumed is obviously cheating", which isn't relevant to programming skills and is also just ridiculous.
(I think the answer is :
Tap for spoiler
Turn one switch "A" on, and keep it on for some time. Turn it off, and turn another one "B" on. Go into the room. If the bulb is on, B controls it. If it's off but warm, A controls it. If it's off and cold, C controls it.Your answer assumes it is known wether it was off or on in the beginning. I did not see that from the question tbh.
I think they're stupid too. Going into an interview is already stressful enough and these types of questions don't put me into "problem solving" mode. They put me into "brain teaser" mode which is a different type of thinking for me. You know how we nailed these questions when I was in uni? We traded them after our interviews between each other and you just had to pretend you've never heard it before. So the main thing people were testing was whether or not the question had made it to them.
For programming, there are so many better ways to test out of the box thinking to me ... I think the "what happens when you press a letter into a web browser address bar" or something is better and at least relevant. One that I like is, "there's an outage in production, how would you go about diagnosing it?" Then as an interviewer I'd reshape the scenario and see where they put their focus and where they give up.