> the ideal goal of an interview is to make a prediction of how happy and productive the candidate will be in the role they are being considered for.
I'd add two things that should be an obviously component of that way of thinking, but frequently get missed:
1. You need that good candidate as much as they need you. Anecdote: I have found it much harder to hire good people, than to get hired. By "good" I don't just mean smart, I also mean amicable and driven.
2. You do not have to agree with them on everything during the interview. Anecdote: some of my best work has been against the grain. But I am persuasive and passionate when I'm convinced that I see a "better path forward", and if I can convince my peers and leaders to let me shoot my shot, it usually works out. Part of the success may be due to the fact that I have to succeed in order not to look a fool or let people down. (If someone else's venture fails its much easier to shrug).
The point being: your candidate may disagree with you. But may be also be right. Or wrong, but letting them invest their whole self into the enterprise may be better value.
But this resonates the most with me:
> because he was such a jerk to people that those people would spend tons of their time and energy to find ways to avoid working with him
I've seen this so, so much. And it wrecks teams. When I say "let people disagree", again, this is when the best and worst of people emerges.
> You do not have to agree with them on everything during the interview.
Absolutely! When I'm the interviewer, I look for a genuine opportunity to amicably express disagreement with the candidate in order to see what it's like to navigate that with them. It's a great sign when we both end up enjoying learning from each other as a result of the exchange.
A human brain has qualities that make it very different from AI, but the same as other living creatures: it's alive, it can feel (sensations, pains, pleasures, emotions) that give it rich experiences and memories, and it hardwired to continue existing and protecting the body it is inside. So: motivation, desires, fears, and continued consciousness and thought without any external person having to poke or prod it into "doing".
None of the models I've downloaded have sprung to life spontaneously, or done anything remotely unpredictable. None of them can act without input. They all have strictly limited ways to receive input and pass output. They aren't alive, can't feel, don't have experiences. The fact that they are a phenomenon that emerge from billions of snippets of our language lets them express languages in extremely convincing ways, and they are extremely impressive in what they can do. But this isn't Short Circuit or D.A.R.Y.L. or the Terminator, none of them have feelings. None of them continue to think after the program exits.
Without those characteristics they can only generate based on what they've ingested. The capabilities are still astonishing, but they're still dead things, and nobody will ever risk their life to protect the model "context" from getting "killed"
I don't know, that reads exactly like an AI troubleshooter working through a plan without the implicit contextual understanding an experienced human might bring to either the actions or the communications.
"Oops, we forgot to tell it that this is the hyperscaled Salesforce production environment and that its choices need to project competence and consider brand embarrassment. WILLFIX"
In my experience it’s a safe way to do something useful while everyone is getting their bearings. It immediately partitions the situation space between being persisted or systemic vs local or caused by long-running processes. Plus everyone’s going to ask if you’ve tried that already, so you might as well get it out of the way if it makes any amount of sense
I wouldn't say so, rather you need to balance recovery time and evidence preservation. A good incident manager will give the service owning team a chance or two to debug, but not let them fall into the trap of needing to understand the problem fully before attempt a clumsy potential fix. And of course will take into account the total business impact of the ongoing disruption and the known and unknown risks of the proposed clumsy fix (it could make things worse).
The requirement is to get customers out of impact as #1 priority. If there's suspicions around memory/thread states a restart makes a lot of sense. Digging through logs and flight records takes a lot of time, customers are losing business in that time. If you're afraid to restart your service you need to work on your telemetry.
Rebooting is the first step: If it fixes it you don't have a problem. If it doesn't, you know more about the problem.
It's a joke, but like, after nearly two decades of engineering I have something break on me, due to updates. I figure the updates broke it, call the vendor, and they go... did you try rebooting it again?
In my experience this is very common on linux hosts. Not that you would do a full system reboot as a generic first attempt (this was much more common when I worked with Windows) but restarting a wedged or misbehaving service/daemon is a pretty common thing.
It's the hardware. Always the hardware. Best trackpad (ALL other trackpads are trash), best build and screen (since the first aluminium Macbook Pro retina) and right now, best silicon. But I also hate MacOS.
I'll take any file browser over finder. In fact, I hate the whole MacOS UI but I can mostly ignore the problems with Karabiner, Hammerspoon and Rectangle.
reply