HPC programming library. It has to be fast, correct, secure and has strong compatibility guarantees so design decisions can have never ending repercussions.

Previous to this job I laughed at the goofy CS questions asked in interviews. "I've been doing this 30 years and never needed A* or a graph algorithm." I have to retract that statement now. Not that the modern coding interview isn't a little overdone, but there is a point to it.

There's also the question of dedication. When you work on a very driven team you have to show a similar level of drive or you're just going to get burnt. I'm not saying the level of work/life balance is fair or the way it should be, but it's the way it is and it has taken me quite a bit to get used to. It's a toxic environment on many levels. That said, it's by far the most impactful job I've ever had. I'm immensely grateful for the opportunity to contribute 0.0000000001 pct to some amazing work.

How did you transition between the previous state you describe and when you found success getting into your current role, in terms of prepping to do that sort of testing, as well as motivation?

I'm very close to 30 now, and have been burnt out enough times that it's a struggle to imagine how I could care about tech enough to attempt to re-transition into almost only caring about sort of climbing that ladder.

I got divorced, lost almost everything, and had to do it or accept living on sustenance net pay for the rest of my life. I really didn't want to do this. I had a cozy gig in my past life, but I couldn't make it on the engineering salary in my town.

I don't come from a CS background. I'm a EE. I just happened to get an embedded job right out of college and kept getting more and more software work. The only algorithms I'd dealt with were linked lists, circular buffers, and synchronization.

Burn out is a constant worry. I still question if my chosen path is even worth it. If I didn't still have hope of having a child someday... I don't know. I don't think I could find the motivation to keep going.

I don't try to climb the ladder. I hit a level I'm more than happy with and now I just need to try to stay on. I find I'm much more compatible with my team because I'm not trying to make the next level. I can share advice freely with the younger folks because I'm not trying to block them. On the contrary, I want my teammates to go far and kick ass.

I'll also add that the first couple of years of my code reviews were a bloody mess. It's frustrating to have people who constantly out-think you and provide better ways of doing nearly everything you come up with. I was lucky to get my foot in the door and then built my skills up even more with a lot of pain and extra hours put it to get things right. I'm a better programmer now than I ever was, but I still have so, so much to learn and practice.

Thanks for your reply. I'm sorry you had to go through that, truly, divorce is a traumatic experience unlike any other, but it does bring some solace to know I'm not the only one who's either been in or is in some sticky situations. Unfortunately I haven't been as lucky in finding something early on to build on. I was about a year and a half into my first position after diploma, and was laid-off, then terminated from my next 3 months in, then again, then again, then again. The only light in that dark being a decent python oriented thing in a research department. Reflecting on that, I might have been in over my head, too cocky as well, with really nothing to base it on other than a passing capability with programming and intense motivation to produce good results. But I was also in the wrong places that I wasn't well-suited for; a constant learning process that has taught me a bit about myself. Looking at the future seems rather bleak, as I'm sure you've felt many times, and I'm pretty much just counting on getting lucky at some point.

I am curious though, what were the more mechanical aspects of how you made that transition? Did you have a plan to practice algorithms in a certain way and then wait till you were contacted by the right recruiter? How did you go about it? Did you more simply just try and do 1 problem a day and then build that up, or did you find useful projects to apply more obscure algorithms to, that might be more interesting and motivating?

Mechanical aspects... I grabbed Cracking the Coding Interview. I started doing online coding tests. I started studying modern C++. I was fortunate that I had a relatively easy, 40 hour day job at the time so the nights and weekends weren't too bad. It took a few months. I interviewed with Amazon and it opened my eyes to how much I didn't know(Also, I am so incredibly glad I didn't get that job). I kept studying. I kept interviewing. I tried to think of things I would be expected to know. As an older engineer with a lot of Linux driver experience I had to refresh my knowledge of the Linux kernel's various subsystems. It was a lot of work. It helped that I've been at this game a few decades though so it wasn't like this stuff was exactly new. The algorithm stuff was, but I'd done a fair amount of Linux stuff, C++(but C++ pre 11), lots of C and Python... I wish I could say I still remember a lot of what I learned.

As far as interviews go, I think I tend to interview pretty well when it comes to social skills. Problem solving is tough. I had to do a lot of whiteboard practicing. I probably over practiced this part because, in my experience, you're not really writing tons of code on the whiteboard. Yes, you need to write some, but it's typically short snippets or pseudocode.

I remember telling my interviewers that I didn't think I was a good fit for the job. It seemed more 'CS' than I could handle. I don't know why they went with me. I know the company was rapidly growing at the time so I probably just got lucky. Not what you want to hear, I know.

Thank you! That is a very interesting world indeed.

But, just focusing on the algorithms part of it, I never could answer how exactly a specific algorithm worked, but I've had to use many algorithms in my "normal" job. I just know "oh this needs a modified DFS, or A*, with custom heuristics, or a priority based permutations generator". I cannot answer how any of this works in detail on the fly, but I know where to look. Isn't that sufficient? I certainly would fail a FANG interview, but have gone toe to toe or even better when pow-wowing on some real problems with googlers. Wouldn't consider myself any inferior because I don't know how a specific algorithm works in the interview. Just my two cents

Is it sufficient? Depends on your interviewer and other factors. I personally wouldn't fail anyone for not knowing absolute specifics(unless they claimed to know as much). I would expect some 'algorithmic thinking' and basic familiarity. The interview is also based on a fair bit of luck. In my case, I was asked about virtual memory, and I had literally just days before done a deep dive through the Linux VM subsystem. If they asked me a week before I wouldn't have gotten the job.

When I started interviewing, I couldn't even do tree traversal. It just wasn't something I was familiar with, and never directly used in decades of coding. I don't blame Amazon for passing on me then.

> gone toe to toe or even better when pow-wowing on some real problems with googlers

I don't think making blanket statements like this is a good idea. Sure, you might be able to code better then them, but can you think of a new solution which is better than the current best practice based on some practical consideration(behavior of your HW, caching behavior, some niche use case, etc)? I think a lot of people are great coders in many ways but that's not always the skill folks are looking for. We don't necessarily crank out a lot of code, but it has to be really good code. You also are expected to come up with self-driven innovations and ways to push the industry forward. It would be nice if there was just a set of problems someone handed me and had me solve, but that's really not what they're paying me for.

That's fair. I think we are saying the same thing, it is just about what you know at that moment, rather than your true capabilities.

Also, my statement was not blanket statement, nor that I wrote more code than others. I was referring to a very specific set of problems that I was working on and not generalizing that I'm better than all googlers. There are many people who are way smarter/better than I am. I'm just saying not being in FAANG does not mean one is not good enough.

I think the interview processes put a bar on if one willing to put in the amount of specific kind of work needed to get in or not. In its own way, it is a good filter (for them)

Mostly reversing binary trees obviously