Hacker News Reader

Comment by mircerlancerous | Hacker News Reader

Sadly I've seen this kind of interviewing from lots of places; maybe it's a technique they teach in college or something.

Interview questions like this are useless as they are not an accurate approximation of a real work scenario. I've frozen up at a whiteboard in an interview before, and then figured it out on the drive home.

The best approach I've found is to do a send home quiz, and then ask them questions about the quiz to test understanding. The test also shows coding habits, which tells you a lot right there.

Bonus: put some typos in the quiz that don't matter. Red flag for the people that get hung up on that.

View on HN

An accurate approximation of a real work scenario would be sitting in a conference room for two hours while trying not to fidget or visibly look bored as co-workers make a mountain out of a molehill.

And then after being 90% complete with the project having your manager or business liaison change the fundamental requirements at the last second and be mystified as to how that could possibly affect any sort of estimates or deadlines.

Once I've been to an interview where first they made us solve a problem in a group and then we had 1-1 interviews. After the group task the guy immediately asked me "Don't you have a feeling that you might've been forcing your opinions onto others?" to which I replied "Yes, I have.". Absolute fucking Chad I was.

Interviewer's notes: anal_reactor is stubborn, difficult to work with, has little regard for others' opinions, not a team player. Do not recommend hiring.

Not wrong, especially at the time. I excel when I'm given my own chunk of job to work on with certain degree of freedom. I don't butt uninvited into other people's decisions, I expect others to do the same with me. I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard.

IMO diving people into small groups, sometimes groups of one, with API between them, is the correct way of managing employees. I really dislike the "everyone does everything" paradigm that my current workplace applies because the end result is that there is no design, we just keep stacking features until something gives, and then we have a project "someone please unfuck the application".

> I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard.

Those are the worst. No, I don’t feel like I need to let Bob feel heard. Bob wants to create a nightmarish stack involving ElasticSearch and Kafka for a problem that grep and a flat text file could realistically handle. I have already explained to Bob that his solution is unnecessarily complex.

But is your solution scalable? Resilient against injection attacks? What about o11y? Is literally anyone besides you going to be running these searches? If so, you're going to want to put a UI around it and that means thinking about scalability, data sanitization, and o11y. Maybe Bob knows something about the scope of the problem that you don't?

Look mate, software is business and business is marketing. If your solution really is better, you need to market it as such, even to the Bobs of the world. Especially to the Bobs of the world. If you couldn't present it in a way such that it's obvious to Bob and everybody else that your solution is better, that's a failure on your part, not Bob's, the other participants', or the meeting organizers.

It is not my responsibility to teach critical thinking and a CS degree to Bob, nor is that in my job description. If Bob can successfully convince our boss and finance team that his solution is necessary, then so be it; I will continue banging my head into the wall.

A real anecdote: I once had to explain to other software engineers, during a retro, that the aggregate bandwidth their queries demanded for the result set was far in excess than that of the DB’s capabilities.

“This would’ve required 230 Gbps, assuming the DB could’ve fulfilled it.”

…

“That’s more than a typical top-of-rack switch.”

…

“It’d be like filling 69 Blu-Ray discs every minute.”

“Ohhhhh.”

The switch analogy may have gone over their heads, admittedly, but the fact that 230 Gbps on its face didn’t sink in is distressing. Entirely too many devs don’t understand any fundamentals, and as such they can’t do basic back-of-the-envelope calculations, and we wind up with Bobs.

> If you couldn't present it in a way such that it's obvious to Bob and everybody else that your solution is better, that's a failure on your part, not Bob's, the other participants', or the meeting organizers.

I invite you to go to any Arab country and tell them to legalize gay marriage.

> Bonus: put some typos in the quiz that don't matter. Red flag for the people that get hung up on that.

I feel like after presenting a great solution to the stupid, cryptic, arbitrary interviewer games where you have to guess the rules on your only attempt at playing the game, you've added one at the last minute. What if one of the values is attention to detail?

Attention to details that matter and knowing what to pass on, is what's important. If they did poorly on the important stuff but then point out the typo, clearly they were putting their efforts in the wrong places

I always give people a ton of leeway in an interview because nobody is at their best in that situation. I once got asked how to use window functions in SQL, with like 10 years of SQL experience using window functions and froze.

I much prefer a pair programming interview or something where you can really see how they work through a problem they don’t necessarily have to finish or do perfectly.

Please no. No and home quizzes

Reply on news.ycombinator.com