This reminds me of how one time in an interview, I realized I had an off-by-one error. Instead of actually trying to understand the source of the error, I just sped-run tweaking different values +/- 1 until I got the expected result.
In the moment I felt quite clever, but the interviewer apparently did not appreciate that technique.
Love to hear it. Interviewing sucks from all perspectives, so as an interviewer I try to give leeway for the stress and time pressure the interviewee is under. But the key thing is they must express their reasoning for their approach, and "I don't have time to dig into this" will get you a long way, at least under me.
(Obviously there are nuances, but there is not enough space in this comment to elaborate)
If you fail an interview because the interviewer was unreasonable, sometimes you should be thankful and think of it as a bullet dodged.
Yes, an otherwise good company might have a bad interviewer, but if they don't have some feedback loop to catch it, chances are there are other things they also don't catch.
Had an interview once over Zoom. Dude has me do a coding test: normal String manipulation algorithmic problem solving stuff. So I’m screen sharing and try to google something and he’s like “STOP! What are you doing?” I’m like “well I don’t remember the exact name of the function” and he’s like “You can’t do that, this is a Test!!”
So I flunked his “test” and then immediately contacted the recruiter and said “no thanks” before he could muahahaha
I mean, in this case… it is nice to get an interviewer that lets stuff slip, but brute-forcing bugs in an interview problem doesn’t seem very good, right?
Many years ago before a demo we discovered that a program failed to run properly but it did run successfully the next time. We couldn't figure why and the clock was ticking. We made a script to run it twice, fail then success, and the demo was good. Then we debugged the issue, which was something trivial (I can't remember the details) but proper debugging and fixing under time pressure is never trivial.
So, an interviewer might appreciate that balancing of signs if told that it is the fastest way make it work (and pass your demo,) only to fix it later. Once proven that the hacked code gives the right solution maybe you could have offered to send them the correct code on the next day or keep working on it if they wished so.
Long ago in high school, I entered a LEGO robot competition with some friends. Tests were line following, collision detection, etc. One of the tests involved the bot being sent on a collision course with a wall. It had to detect running into it and turn around. This was one of the easiest ones to complete, but shortly before the test started we realized that our pressure sensor was malfunctioning and didn't send any more signals. There was no more time to swap it out, I don't even think we had a spare to be honest.
Not wanting to give up points on an easy test, we gauged the distance the bot had to cover in the test, and quickly uploaded some new software. At the start of the test, our bot moved forward for 4 seconds, stopped, then turned around. Full points on that one!
Some times things just need to work and we can worry about them working _correctly_ later...
Damn you beat me to it, I knew this felt like a Monty Python skit...
>“Nobody expects the Spanish Inquisition! Our chief weapon is surprise... surprise and fear... fear and surprise... Our two weapons are fear and surprise... and ruthless efficiency.... Our three weapons are fear, and surprise, and ruthless efficiency... and an almost fanatical devotion to the Pope... Our four... no... Amongst our weapons... Amongst our weaponry... are such elements as fear, surprise... I'll come in again.”
> Instead of actually trying to understand the source of the error, I just sped-run tweaking different values +/- 1 until I got the expected result.
That's perfectly valid, when one knows a specific step or result must be positive or negative.
Not that much different from dimensional analysis, which speedruns you to get/fix to proper formula (at the cost of skimming on dimensionless constants).
Similarly, interviewer was not impressed when they cut me short and started walking me through some step and I pointed to them that their result was obviously wrong as it was dimensionally inconsistent and if they didn't cut me out the formula must have been something like baz*foo/bar^2 or something and now we just have to figure out the constants.
Honestly it wouldn't surprise me if it had been invented multiple times independently, it's just too obvious to anyone that has had to deal with calculation.
(But thanks for sharing what us without a Twitter account cannot see otherwise anymore…)
It was common saying 30 years ago when we were preparing for IT Olympiads in Eastern Europe - if you do even number of errors chances are your program will work ok.
We would joke in physics class that you either need to memorize the right-hand rule; or if you were right handed while doing the test, the negative left-hand rule.
(because students would often make the mistake while holding their pencil during the exam of how to calculate the curl)
The tricky bit is when you have multiple interacting systems which see different combinations of those sign errors: it makes it a lot more important to know where all the sign flips should actually be. For example, it's quite easy to make a PID controller where the D term is actually the opposite sign to the others.
