I do not have ADHD but also struggle to "sell myself". It's something I had to work on. My view is that the industry can be kind of obsessed with these kind of stories. It's kind of like the "great man of history" world view, but in the small. A common challenge for me is in companies that have a "cultural" interview where they want you to talk about some conflict that happened and how you resolved this, either I'm incredibly naive or I just don't see conflict in this way that makes it a story. I just try to treat people with respect, I try to talk to them in a way that makes them feel open to talk to me. If I have hit conflict it didn't strike me as a moment where I had to think about it in that or it never escalated to being a problem. And it can be the same for programming. I don't have a cool story about the "hardest bug I ever solved" because it's just the same iterative process as any other challenge I have and it feels the same to me in the moment and after, just sometimes it takes longer. And I am no way trying to imply this represents some exceptional behaviour on my part, it's just by nature or nurture how things work, I didn't choose it.
The way I've interpreted conflict in these contexts is more of a "You have ticket X, but it can't be done because Y. How did you communicate about that to your PM/Team/Manager/Relevant Stakeholders?", not literally "How did you handle a fiery argument in the office". It also doesn't hurt to ask the interviewers directly to define "conflict" for you, though.
I think using the word "conflict" is idiotic, but it helps to rephrase it. Because indeed, like you, I've never in my life had "conflict" with anyone in a work setting, I've had plenty of disagreements though and that's just part of the job/life.
I tend to just make something up here on the spot honestly, because as you said, I'm not keeping a book of grudges where I record every single disagreement I have with a colleague. I'll say something like "On Project X (which I've been talking about during the interview) we had a disagreement on how to do Y. I resolved this by gathering the facts on the pros and cons of method FOO vs method BAR, and we sat down as a team and discussed the approach we preferred to take". The anecdote is usually completely made up, but there's been enough situations during my career where the approach has definitely made sense.
I really hate some of these questions too. I'm going to talk at the hypothetical interviewer a lot so "you" isn't you.
Name a time I had an angry customer? Lol, like, all the time forever? I almost feel like this one must be a trick question designed to catch people who can't deal with the job. I forget about such customers as immediately as possible. As a matter of fact, over the years I've relied on my ability to not reflect other people's temperature or allow their demeanor to take up a lot of space in my field of attention in the first place. I'm not sure if anyone with good chances of coping in this line of work [IT/support/sysadmin was the context when I originally posted this self-quote elsewhere] should really have any honest answers to this question readily available.
I can only name one time I had an angry customer, but obviously I've had countless angry customers. I can name that time because he left a voicemail like four minutes long ranting about how unacceptable it was that we had a full call queue and that he was asked to leave a voicemail, and demanding to be put in touch with various executives. I keep that one in the toolkit because it's easy to twist into inspiring stories about above-and-beyond customer service, or taking ownership, or whatever.
How do I explain something technical to a customer in simpler terms? It's not just me, is it? These seem patently ridiculous, like if they had bothered to do some kind of trial run or think for 30 seconds about how they might answer them, they would have realized...
Or is it just me? Does everyone else have an overt methodology for doing this that they can articulate on demand? I would probably come off like some kind of idiot in that interview. Uh, I dunno. I guess I, like, you know, use the context of the interaction so far to gauge their likely understanding of the salient points? And I audit the explanation for unnecessary tangents and jargon and opaque concepts? I then tailor the explanation to what they need to know and what I think they'll understand in the most useful way in that context? So I guess, in a nutshell, I would say that I explain something technical to a customer in simpler terms by just, like, doing it. This is, like, a bespoke service, sir, perhaps you should try the TJ Maxx down the way.
How do I deal with different personality types? I just, like, do it? This feels like another one where having an answer is a red flag. I've never needed to handle this overtly/consciously either, and I think that's a good sign.
Can I give an example of a situation where I had to go above and beyond for a user? No, and I don't think you grasp the core concept of "above and beyond". If you want some stories about times I didn't have to, let me know.
Edit: Actually, you know what, I do have one of when I "had to go above and beyond" but probably not in the way they're hoping for: https://i.vgy.me/7ZAwjj.jpg
Where do I rate my office suite skills on a scale of 1-10? I'm terribly sorry, I must be in the wrong interview, have a nice day
