I'm a similar boat. Diagnosed with ADHD recently but later in life, and it's likely why I never settled into a single domain. I consider myself a strong software engineer but tend to fall apart in interviews, particularly with unstructured things like being asked to "tell me about yourself." I am also planning a shift into a management role.

My main regret in life is spending a lot of time trying to apply advice that seemed reasonable and how Other People did things. Only adopt things that work for you.

• I highly recommend at least trying stimulants. I inadvertently self medicated with caffeine for years, which might work in a pinch. My secret sauce is frankly 90% Concerta and 10% behavior modification things like carrying a notebook around.
• I would not mention that you have ADHD to interviewers since you can't count on anyone to properly understand it. Showing weakness is just blood in the water. Hopefully this won't be an issue for future generations. Yes, I am extremely bitter about this.
• Approach this as doing whatever you have to do to get yourself over the finish line, and know that trying harder at a failed strategy never works. Don't limit yourself to how things are supposed to be done.
• Security requires a flexible mindset and attracts square pegs. Data centers are where all the real weirdos hang out so devops might be worth considering. I'm confident most scientists I've worked with have ADHD, and prototype R&D work is definitely more ADHD friendly.
• Insist on knowing the structure and expectations of each round of an interview. I pitch this as "I need to know how I'm being evaluated so I can properly prepare and demonstrate my abilities."
• I'll be honest: the interview process is mostly nonsense and should be treated as such. Anything that puts a thumb on the scale in your favor is fair game, short of unethical behavior like lying. Telling people what they want to hear is a great way to counter dumb questions.
• I've built up an Obsidian 'database' of bullets to help during interviews, including a prepared statement of why I have it and need to have it available.
  • "Tell me about yourself", "what type of role are you looking for", "why do you want to shift into management" open ended questions. The key thing is respond in a coherent, organized way without showing any negativity or weakness. Yes this is ridiculous, but it's how it is.
    • Turn your generalist background into the strength it is. I use: software engineering is a problem solving role, everything else is a means to that end. Solving problems is what I do; I've done so in a wide range of fields and domains and always drive them to completion. What I'm looking for is a great team to join, which is independent of industry or tech stack.
  • "Tell me about a time" behavior questions. I like the STAR format. I do well on these but need an outline to work with. Make sure it's polished into a coherent narrative. Put an emphasis on what you did, but also how you enabled your team. Numerical data points are great if you have them
    • If the company posts their values or principles then that's likely want they want to see out of these. Match your scenarios to the values beforehand. The idea is previous behaviors indicate future ones.
  • System design questions. I have my own checklist of questions I go through since I don't like the popular format. I expect this is where you shine, maybe just need a bit of scaffolding to help organize your thoughts.
  • Leetcode programming tests. Like it or not, it's part of the game.
• If you are serious about going into management, you'll need a prepared philosophy of how you see the role and will approach it.
  • This is also a great question to ask hiring managers. The best indicator of what the job will actually be like and you can't wiggle out without raising red flags.
  • The two books I like are The Manager's Path by Camille Fournier and the classic First, Break All the Rules by the Gallop folks. Again, not all advice is good so only take away what you think will work for you. Worth reading if only to understand what you should expect out of a manager.
  • Do not make the mistake of feeling like you need to go into a people management position. Shifting into project management is perfectly fine. Topping out at a senior or staff software engineer role is also perfectly fine. Frankly, topping out at a mid level engineer is fine, just watch out for ageism.
• I also have check lists for all sorts of random things. Even dumb things like how to respond to a question I didn't prepare for: repeat the question, write it down, jot down what I think they want to hear, write down points, and give them an order.