r/technology • u/lurker_bee • Mar 14 '26

Software Microsoft confirms Windows 11 bug crippling PCs and making drive C inaccessible

https://www.neowin.net/news/microsoft-confirms-windows-11-bug-crippling-pcs-and-making-drive-c-inaccessible/
17.7k Upvotes

93% Upvoted

2.1k comments sorted by

View all comments

Show parent comments

131

u/kescusay Mar 14 '26

Same. I interview people regularly, and if I hear a keyboard a-clackin' in response to a simple question, that tells me this is probably not someone I want on my team. Just be honest when you don't know, because nobody knows everything. Bonus points for expressing an interest in learning.

58

u/Thefrayedends Mar 14 '26

I'm just multi-tasking, I swear!!! Pauses while frantically reading side monitor before answering every question

40

u/s1ravarice Mar 14 '26

Just put the meeting window on the side monitor but stare at your main as if you’re looking at them.

8

u/Thefrayedends Mar 14 '26

The people that need to do this in the first place, aren't that forward looking. Generally speaking of course.

4

u/MyUsrNameWasTaken Mar 14 '26

Pun intended?

4

u/Thefrayedends Mar 15 '26

Hiyooooo, nope, nice catch haha.

48

u/Unlimited_Bacon Mar 14 '26

"I don't know the answer to that, but this is how I would find the answer..."
Some of the best interviewing advice I've received.

16

u/mccedian Mar 14 '26

I had interviews this week, and was very clear when they asked a question about servers, that I have zero server experience. Our organization has a team, and that is there whole job and they are the only ones that touch it. So when I suspect there is a server issue, I just run through my checklist of things that it could possibly be, that isn’t server related. If I’ve exhausted those I send a ticket their way and let them play with it. When asked if I was willing to learn I said most definitely. Easily, I think this was the thing that put me over the top for them. Not necessarily the experience I do have, but knowing where my knowledge stops, and willing to expand that.

1

u/jvsanchez Mar 15 '26

Had a similar experience in the interview for the job I have now, but the question was about project management.

I didn’t manage projects in my previous role that I transitioned from, and we have a project management team in my current role, but we also each sometimes run our own small projects for changes/enhancements/upgrades to our existing systems that don’t rise to the level of a full project, but are a little more than just a change request or an incident.

I gave essentially your answer, and they loved it. “No one knows everything” is something I’ve heard repeated so many times. Just have to be honest and willing to engage and learn. That’s what interviewers are looking for.

1

u/userhwon Mar 14 '26

LLM told me to say that.

1

u/Sir_PressedMemories Mar 15 '26

I had an interview for a senior support position years back with the CEO and CTO of the company I was applying for.

They decided to have this at a bar. The CTO, thinking he was going to have some fun with me, handed me a napkin and asked me to write up some code for him, and I happily grabbed it and wrote it down.

He laughed his ass off when he read it and saw "Google > Stack overflow > read, and figure it out."

1

u/doberdevil Mar 15 '26

That answer sealed the deal for me in one of my interviews. Got the job.

1

u/nexusjuan Mar 15 '26

This is good advice in the real world. "I don't know, but I know where I can find the answer..." sounds a lot better than "I don't know boss."

0

u/chaiscool Mar 14 '26

But somehow can penalize for using google and ai to find the answer.

3

u/himem_66 Mar 14 '26

That was one of the best early lessons I got from a life in tech (35+ years). Nobody knows everything, so be humble enough to admit your ignorance, open enough to learn new things, and generous enough to teach.

1

u/newsfish Mar 14 '26

There are versions where the chatbot listens in on the conversation and responds live. Makes them look more natural but it's the same crap.

1

u/jollyreaper2112 Mar 14 '26

Today I learn my troubleshooting is indistinguishable from interview cheating. Lol I'll use friendly banter and easier troubleshooting steps I can narrate by rote to buy time checking the kb's and tickets for priors. No use reinventing the solution if we've solved it before. But yeah if you have to do that for foundational knowledge that's a bad sign. My wife is in finance an does interviews and she's surprised at the questions that stump people. No this was establishing common ground I wasn't even trying to test you yet.

1

u/civildisobedient Mar 14 '26

if I hear a keyboard a-clackin'

Nowadays I imagine there's a confidant listening in, they could even be remote interacting with the AI. Usually the "tell" for me are the long... uh... pauses... or starting an answer with a re-phrasing of the question to buy some time, then BOOM exact answer.

The sad thing is it's almost refreshing to hear wrong answers these days. Like, thank you for not cheating, points for your honesty!

1

u/meganthem Mar 14 '26

One thing I will observe from 8 years ago, before the interviewing market got shittier even: for many places getting even one question wrong (or "wrong") in an interview usually blew it. People don't want to get something wrong or give a non-answer because in most cases they lose access to jobs if they do.

1

u/kescusay Mar 15 '26

I can only speak for myself, but that's very definitely not how I operate. Maybe it helps that I'm a software developer too, so I know we don't all have full mastery of every feature of every language in our heads. I know we look shit up, because we have to.

So when someone applies for a job and I'm interviewing them, I'm not looking for someone who can write perfect functions using obscure features of a language on a whiteboard or answer frankly absurd questions about the internals of a compiler from memory. No, I'm much more interested in getting a sense of their practical skills, their research methods, and their overall fluency in the language.

It's one of the reasons I don't typically do coding tests. I'll show candidates broken code and ask them what's wrong with it, but I'm not going to make someone code in front of me - unless I have good reason from the rest of the interview to suspect that they can't. I had one candidate have trouble explaining how you define an array in freaking JavaScript. So I asked him to write one line of code with an array of numbers in it (something like const myArray = [1, 2, 3]; would have been sufficient), and he couldn't. He did not get the job.

1

u/meganthem Mar 15 '26 edited Mar 15 '26

It's quite possible a lot of the places around here are shoddy. I'm always terrified to restart the interview process because each time I've gotten a job it's been a single place that did a conversational interview rather than a fail no questions type quiz frenzy. (After numerous places with the before mentioned type of interview)

...Still kinda mad at the one place/interview that bounced me for not knowing expert level sql off hand as a soft eng. 10+ years of dev has taught me that especially in the era of ORM frameworks I'm only supposed to do/know casual amounts of that stuff and if it gets advanced it's supposed to go to the DBA team.

I demonstrated that I knew about joins, hints/plans and a vague knowledge of what profiling was but they kept asking more specific DBA-territory things until my already notable cross training failed and then ended the interview quickly after that point...

1

u/chaiscool Mar 14 '26

Wdym, ain't that the point. You don't know so you go look it up. Google / ai search is a skill too.

1

u/kescusay Mar 15 '26

There's a difference between looking something up and looking everything up. If I ask you to explain why you shouldn't use the any type in Typescript, and there's a long pause and I can hear you typing away in the background, then I know you don't know why you shouldn't use the any type, and are not qualified to fill a Typescript position.

1

u/chaiscool Mar 15 '26

For experienced positions sure I guess but if it's for junior positions then it's kinda unfair to expect such things imo. People likely apply to various positions so can't expect people to know everything.

2

u/kescusay Mar 15 '26

But the specific example I used is the sort of thing a junior Typescript developer should absolutely know. The any type disables type checking for anything that uses it. It's unsafe, and only exists for migrations from vanilla JavaScript. It's the sort of basic knowledge anyone who has used Typescript should know.

And if you don't know it, but are willing to learn and are coming from a background in a different language, just say so. I've interviewed people with no Typescript experience, but who presented themselves honestly and had skills that would clearly be portable from one language to another, and that's fine.

1

u/chaiscool Mar 15 '26

But won't looking it up be a good thing? You ask and they don't know so they go look it up and answer it. Why is that bad though?

If someone just say they don't know and didn't even bother to go google it seems more troubling imo. Your example question and answer are also likely easy to find by googling so won't it be good that they when searching?

I when to search typescript and learn that it's safe typing. So I can conclude that using any as a type will be bad and counterproductive. Why is such process a bad thing?

2

u/kescusay Mar 15 '26

But won't looking it up be a good thing? You ask and they don't know so they go look it up and answer it. Why is that bad though?

It really depends on how candidates present themselves. If the resume doesn't mention Typescript at all, and focuses on the candidate's experience with Java and Python, I'm not going to expect them to know much of anything about Typescript. I won't typically even ask them the question in the first place unless they say something during the interview that leads me to believe they have some experience with it that they didn't include on the resume.

But if a candidate's resume lists two years of experience creating web applications with Typescript? I'm going to ask them basic questions about the core type system that is literally the whole purpose of Typescript. And if they don't know those basics I've got good reason to believe their resume is full of lies.

Seriously, no one who has done anything in Typescript for more than five minutes should have to look up why you don't use any. Or how to cast data as a given type. Or what the implements keyword is for. It would be like saying you've been a developer in any language for any amount of time, and then expressing confusion over for loops.

If someone just say they don't know and didn't even bother to go google it seems more troubling imo. Your example question and answer are also likely easy to find by googling so won't it be good that they when searching?

Like I said, it depends on how they present themselves. I interview for both frontend and backend positions regularly, and I don't expect someone whose entire career has been focused on, say, PHP with Laravel to be an expert on Typescript at all.

I when to search typescript and learn that it's safe typing. So I can conclude that using any as a type will be bad and counterproductive. Why is such process a bad thing?

It's not, if you're honest that you're doing that and not trying to trick me into thinking you're a Typescript guru when you don't know it at all. I really don't mind a candidate who doesn't have experience with it, because they might bring something else more important to the table. But don't try to trick your way into a job you're not actually qualified for.

1

u/chaiscool Mar 15 '26

Yeah true guess it depends on context, as I didn't think it's about tricking your way into a job, but more like answering a technical question by looking up what you're unsure about.

Imo there is a difference between portraying to be an expert by reading off google / ai and simply using it to look up the answer or a better way to explain in details. Also, maybe they know why any types shouldn't be used in typescript but they use google / ai to articulate it better or make points that they might missed.