I actively try to avoid discussing status. The 1:1 is primarily a meeting for them, whether or not they realize it. The goal in a 1:1 is primarily to get them talking about whatever it is that they want to talk about. Sometimes this just turns into chatting about non-work stuff. Sometimes we'll discuss problems they're having on the team. Sometimes they'll talk about work they want to do but haven't been given. Sometimes they'll have questions about "how the system works" (these are usually pretty interesting conversations). I try to tell stories from my own work history (frequently embarrassing ones) both because they're funny, and because it makes it easier for them to talk about their own potentially embarrassing problems. Sometimes I try to lead the conversation toward something that I want to talk about - like if I need to give them some feedback, or if I want to discuss their career development, or a new opportunity. Sometimes you can tell that they're circling around something they don't know how to bring up, and you can gently nudge them in the right direction.
Sometimes it's useful, and sometimes it isn't. Ultimately, if it helps to deepen trust and understanding, then that's a good result.
It's funny because when I read the sentence "the 1:1 is primarily for them" i didn't realize you were a manager. To the me the 1:1 is primarily for the manager. I need my manager to talk about their perception of how the work, more specifically my work, is going.
I'm an engineer, and my 1x1 meetings all feel useless to me. It is 100% a meeting for managers and I'd skip every single one if I could.
I would vastly prefer an ad hoc meeting when I actually have something to talk about instead of 30 minutes every week where I'm constantly struggling to find material for this useless meeting.
The implication is that humans have been trapped in a local maxima in terms of strategy and board reading. The question then becomes whether we can use this to bootstrap ourselves.
HN is free but you as users are the product. HN is a fantastic marketing tool for Y-combinator. They do a pretty good job of keeping the balance right though.
People will occasionally try that, but my point to them is that they should be writing a general purpose BST, which should also allow degenerate trees. So no, I do try to steer people away from theoretically correct but desperately inefficient approaches.
To be fair, it's "desperately inefficient" only in the face of unbalanced trees, no? Which mostly only happens for unrealistic scenarios.
As stated, the problem assumes that time lookup isn't important, even though someone who wants a BST almost certainly chose it to get faster than linear lookup along with fast insert/delete operations and ordered searches. (Otherwise, why not use a hash table?) A self-balancing tree gives that additional guarantee, and in that case an array-based data storage won't be "desperately inefficient".
Indeed I suspect an array will be competitive or even better than an object based version, where each object has its own pointer overhead and associated memory fragmentation.
At the very least, the early AVL work in the 1960s used a tape for storage, and I suspect they didn't waste all that much tape space.
So someone's intuition from real-world use of BSTs might end up giving you a false negative.
That's when the flustered interviewee can either fight (patch his solution) or flight (start all over using a class with refs). The most obvious patch is to use a large hashmap instead of a massive array. Still inefficient, but no longer that desperate (and actually has some added benefits).
Sometimes it's useful, and sometimes it isn't. Ultimately, if it helps to deepen trust and understanding, then that's a good result.