It seems that “able to code a simple problem well” is a far less ridiculous proxy for good software engineer than “able to code a hard problem at all”. Much to my surprise.
The software industry is notorious for underestimating overall complexity factors, understanding uncertainty, and time to manage them and interviews seem to be no different. So “simple” problems are often good (I agree with you) because they’re actually not so simple for most people when you factor everything in, they’re often reasonably challenging under the set of circumstances.
Meanwhile genuinely difficult problems (in any arbitrary setting and longer timelines) require a whole lot of rote training and reusing little clever idiosyncratic techniques that may or may not be generally useful, so you very often end up with a question lottery on whether you already know how to address the problem in question or not correctly vs having some problem where a reasonable solution and expectations around that can be derived in the time (and environment) it’s taking place. Lots of nonsense.
Truth is, I'm never looking for "the best", I'm looking for "good enough to do the job competently". Because we can hem and haw over what is best for hours. And we could disagree with what qualities in what proportion make someone "the best". But we can all generally agree with "could do the job". As I've mentioned elsewhere, we're hiring right now and we have the duality of candidates in our pool.
There's one guy who is just a hard no from at least two people in the group. And that translates into a no from the third member simply because we're so adamant that he's not the guy. And there's another who we're all feeling really solid on. Not "the best", but solid floor and we feel they'll be able to learn.
But being able to weed out people who can't even perform the basics despite having a decent resume is invaluable.
When I worked for more medium sized companies, I'd get software engineering candidates who obviously did not even remotely know how to code. Imagine the worst possible software candidate, and then lower your expectation even further. One couldn't even tell me what an "int" was. I think a single "for loop on a whiteboard" question would filter out at least 50% of candidates.
"You can lead a horse to water but you can't make it drink."
It says barely anything about the universities and everything about the student. If a student just wants to just have a perfunctory gargle at the fountain of knowledge instead of drinking as deeply as they can, that's on them.
Almost everyone embellishes their resume. Some do it to an extreme. The first stage should be weeding these people out, and any hiring manager learns this lesson very quickly.
Story: I learned this as a hiring manager early on. I was the resume screener, first contact and then last contact. Everyone in between was my team and other adjacent teams. I failed to ask the right questions in a phone screen and when we brought this guy on-site he failed very bad. Even worse, he broke down begging for for another problem he could solve.
It was bad for everyone and we were a very accommodating group that gives many tries. We weren't looking for perfect answers to one question.
Though I still do start with a short fizzbuzz-level question because you would be surprised how many people fail that and it makes it way less awkward if you start with atoi and they can't write a loop.
If they fail fizzbuzz I generally just turn the interview into a chat or give them easy questions to practice, rather than say "yeah no thanks", because I feel like the latter is a bit mean, and everyone can benefit from interview practice.
It’s kind to politely ramp the interview down in that case but I’ve learned to then cut off any later interviews. It’s a waste of the company’s time and the candidate’s too.
If we were going to have lunch the recruiter takes them to lunch anyway, unless the (now former) candidate doesn’t want to.
> We also used atoi/itoa
Trying to debate the interview format or reject interview questions is one of my hard-stop rejection triggers in interviews now.
The couple times I’ve been part of hiring pipelines where candidates argued about the interview itself and then got hired anyway, they became extremely difficult employees within the company. Arguing about interview questions turned into arguing about every other ticket, code reviews, and every architecture choice.
I’ve had the same experience where we take an actual problem we solved in our codebase and turned it into a small interview problem. Same thing: Some candidates will try to debate the relevance or try to wriggle out of it.
if the interviewee pushes back and find they don't like the answer, then it's a good signal to both parties.
Sometimes you just have to "document your objection, but do it anyway."
Sometimes we want harmony and not drama.
Knowing how to push forward without being abrasive is a more valuable trait.
Fwiw this is surprisingly subtle and non-trivial to get right. A naive "random swap" approach does not produce uniform permutations. Sorting based on a random comparison function can likewise produce biased results depending on the implementation of the sort. Tagging each element with a random number and then sorting based on the tag works (or so I think?) but you need to deal with the case where tags collide. Fisher-yates shuffle is bulletproof but I would not trust myself to write it from memory lest you end up writing Sattolo's algorithm instead.
At the end of the day the question is: “could this person do the job and could they work with others in the process?”
“Trick” questions are dumb, but you want to get an idea of if the candidate knows their stuff (and let the candidate know what we’re like — interviewing is a sales process in both directions). If someone asks a question like “is it ok to modify the argument” (or says “I’ll assume I can’t modify the argument”) that’s great (or says “I can’t remember if strlen includes the 0 byte so I’ll add 1 — normally I’d look it up”) - again, no trick questions.
When I say “simple” it’s something like atoi or “shuffle a deck of cards”: basic, but not 100% trivial like fizzbuzz.
On of our best hires was a guy who made a fundamental mistake — when we asked him if it world work as intended he said “I’m a fucking idiot” and fixed it. You’re not supposed to talk like that in an interview I supposed but we read it as a strong positive signal.
We had one candidate who insisted that parsing a string and returning an integer was an unreasonable question because there was already a library function for it. “But what if you have an embedded system and no library?” (an actual situation for us, for part of our system). He was adamant — honestly that was a failure of the phone screen: had it been caught it would have saved us, and him, from wasting time.