You'll find that outside the startup, the director/vp/cto title doesn't translate. Larger companies will often write you off as being "not experienced" enough which is often code for "you don't look old enough for this position". Unlike engineering and the startup world, big companies want you to look the part not just know the part.
> Larger companies will often write you off as being "not experienced" enough which is often code for "you don't look old enough for this position".
It's not about age, it's about what you actually had to do. Company size, company age and political complexity are strongly correlated.
A successful large company engineering director spends their day mostly doing politics across the org, while a successful small company engineering director spends a lot of their day writing code, being an architect, filling in for product management.
> Unlike engineering and the startup world, big companies want you to look the part not just know the part.
Big companies want you to know how to play the long game.
That latter person sounds like a normal L6 at FAANG. Director is 8. They truly haven’t had the exposure to build the required skills for that lateral transfer.
A CTO of a startup might be coding day to day, making technology decisions, and have a team or two underneath them. In F500 or Corpro world, this is more like a engineering manager or tech lead. In most big companies a manager does zero coding and rarely makes a tech decision, you go up to a director level, they might have 100-200 people under them, direct reports are almost all managers, and they never touch tech. Go higher up to VP or CTO levels and they are just so divorced from code that it doesn't make sense why a CTO in a startup would translate.
The corporate world is simply a different environment with a different set of rules and a different set of engagements and thus requiring a different set of skills. A director or VP at a startup and a director or VP at a Fortune 500 company are two totally different things.
Every developer I know (myself included) that has worked with QNX has a story about some insane bug that took significant effort to uncover. At this point, I would say the only reason one should look at QNX is for cost since it is pretty cheap. The low jitter on context-switching to the highest priority thread is a nice thing but the dev process is absolute garbage.
yep. it's really trash. used it 20-25 years ago when they were just introducing "neutrino" vs. the classic QNX4. the former had a good rep with auto and medical usage.
- very bad port of GCC was buggy and generated bad code. it was the result of some idiot blindly haphazardly applying a ton random incoherent patches to try to get it to build instead of porting it properly. (to be clear mainline GCC at that time was fine; we re-ported it ourselves instead)
- and, of course, they used their own faulty compiler to build their libraries and services ;) causing unknown carnage waiting to be discovered.
- malloc broken (heavy use under multiple threads causes heap corruption). replaced with dlmalloc.
- serial port driver broken. rewrote a new one.
- intel network card driver crashes. replaced hardware with 3com to survive.
- certain math library functions broken (iirc, fmod). replaced.
and so on and on.
it doesn't matter what certification your RTOS (or whatever) has. if you cannot examine the source, rebuild it, etc. (oss or private source available) - it cannot be trusted. this was one of the worse examples, but it's always like this with "proprietary" OS/toolkits.
My favorite part about this tax is that it was passed in the same year that the state had a budget surplus and actually cut checks to residents because of it.
