[Liquix]

leetcode seems to agree with your definition [0]. the meme isn't to say that inverting a binary tree is particularly difficult - anyone familiar with coding challenges and trees could trivially produce a solution. the meme is more pointing out how ludicrous it is that senior/staff/principal interviews can hinge on these types of problems, despite the engineer proving their proficiency by doing something like running DOOM in typescript types or writing homebrew [1].

[0] https://leetcode.com/problems/invert-binary-tree/description...

[1] https://x.com/mxcl/status/608682016205344768

[devmor]

I think those challenges (especially leetcode) are heavily misused.

When my team conducts technical interviews, we are asking for a couple simple programming solutions - but we're asking because we want to hear the candidate talk through it and see what their problem solving process is like.

If you aren't evaluating based on conditions like those, I don't really see the value of coding questions.

[xenadu02]

I agree with this. I got to experience both sides when I interviewed at FB/Meta. I practiced the leetcode and Cracking the Code Interview stuff of course and one of my interviewers asked something like that. I guess it was insulting and pointless but whatever - I just did it.

Another interviewer asked a much more interesting question: you are writing an IM client. How do you build the client-server communication?

That was a great conversation I enjoyed on its own without regard for the interview. Asking questions: do we have online/offline status? (yes) What are the target devices? (mobile).

IIRC I said I'd want to optimize for bandwidth and latency. Cellular networks can be spotty at times and stall out in really annoying ways. I'd design the protocol to use an efficient encoding with a pre-shared dictionary (the list of friends doesn't change that much after all and lots of the same words/emoji are used frequently). I also said I'd make a flexible format that would let things like online/offline status or you have a new message from X ride along with an actual message in the current conversation and explore options like QUIC or other UDP-based eventually-consistent options given how a cellular dead band can put you in TCP retransmit jail for minutes at times.

For closure I was offered a position but went to a different company.

[josephg]

> If you aren't evaluating based on conditions like those, I don't really see the value of coding questions.

The way I think about it, you're really trying to evaluate a candidate on about 10 different metrics all at once. Metrics like programming skill (writing & debugging), communication skills (listening and explaining), capacity to learn, domain knowledge (eg if you're hiring a react dev, do they know HTML & react?), likeability, and so on.

A good interview gives the candidate the chance to show their worth in all of those different areas. But time is limited - so you want some different challenges which will show many capabilities at once.

Asking a candidate to talk through how they'd solve a "leetcode problem" sort of does that - you can see their CS knowledge and their communication skills. But if thats all you ask, you end up overemphasising the candidate's CS knowledge. Most people aren't very good at thinking and talking at the same time. And you don't learn about other stuff. How good are they at debugging? At reading code? Do they have domain knowledge? Can they talk to clients? Are they good at design? Its also quite easy for the interviewer to be distracted by the question of whether or not the candidate solved the problem you gave them. - Which isn't really what anyone is there for.

As part of a larger interview, and especially for systems engineering roles, I think they're still fine questions to ask. But if thats the entire job interview, its a bad interview - because it won't let you evaluate a candidate properly. Especially in product roles where CS knowledge isn't very relevant anyway.

[phatskat]

Our technical questions typically stay within the realm of the position we are hiring for, so technical usually revolves around “would you use X or Y in this scenario? Why?”

Understanding how someone thinks is more core to evaluating candidates, so questions like “let’s say you own a window washing company and you’ve been hired to wash every window on every skyscraper in New York City - how do you do it?” provide a much better insight into how someone goes about approaching a challenge.

A coworker has a simple diagram they use outlining a tech stack: backend, cache, frontend, and they give a brief overview of the “application.” Then they explain that there’s a big report that “customer says X isn’t working - how would approach fixing this?” It’s less technical on details and more about again how they would approach finding the issue.

[cancerhacker]

This is absolutely the way. My interviews are conversations with someone that I want to work closely with, and while leet code might be an interesting lunch conversation it’s not going to be part of any of our day to day work (c/c++/swift/obj-c)