Engineering time also depends on who's doing the job. You'll work much faster and better if you work with something you're already familiar with. From the boss' point of view - if I employed nctnico, I would make sure to give him ARM based jobs. On the other hand, Siwastaja would have zero chance of getting ARM job - all the ARM jobs would go to nctnico!
What the heck is an "ARM job"? If this is about designing ARM processors or MCUs/SOCs using ARM cores, I understand this. For a PCB/software design work that only utilizes "ARM things" as components - nope, you want a broader perspective. The core is just a single detail. Complete MCU architecture (peripherals!!) is more meaningful - and how you use it. Experience on many different product families (and preferably several manufacturers - still my weakest point, I mostly know about AVR, STM32 and Altera FPGAs) really helps here. OTOH, you can't be deeply experienced in too many different things. It's a trade-off.
This is exactly why I love to work in a fairly small startup, where I can be in the "CTO" role as well, and be employed by my own company. In-depth knowledge and ability to bring results matter, and we have basically no cargo cult on technical matters, which is absolutely great. Small engineering team of about four people is easy to work with, and everybody trusts me 100% on matters regarding electronics and low-level software. I can choose who I play with, and I have a lot to say to who gets hired. So, simply put, I don't
need to be hired by people like you, and I don't need to play your office games.
I rather take the business uncertainty and risks of a small startup.
The perspective-less belief in "getting things done quickly" by using trend tools - typically chosen with Powerpoints, by people who are
not actually writing the code - and reusing other's code as much as possible works on a small timescale.
This is the inevitable way to work when the engineers don't have the skills to do it otherwise, and it always seems like the right choice - short term. It also works on larger corporations with established tradition to bring out mediocre mass products where large engineering costs (by using ineffective design practices and teams too large) do not matter.
Long term, and when you want to develop something really ground-breaking (not just a new coffee maker), it's well worth investing some years of time so that the engineers learn. For me, it happened during two decades of "hobby / enterpreneur hybrid", and thanks to me being able to insist on not listening those who tell me how I "should" be doing things. According to masses, I have always been "wrong". Funnily, during that time, the way things "should" be done changed so many times that you never learn any of those ways properly, anyway. Also, no one remembers those "right ways" of doing things after a decade.
Suddenly, I was able to start saying "yes" for complex work on projects involving other people. And suddenly, I could say "yes" on taking the leading role.
Gain experience on real projects, always do it your own way. Believe in your skills and your intuition, even if it goes wrong sometimes - that way you learn, and after a decade of doing it like this, you suddenly realize you are not going too wrong anymore, and can make fairly good estimates of the project timeline, cost, and communicate with others, using their terms as well - while still doing it your way.
Don't be arrogant.
Would I hire you or nctnico? I don't know. I don't see too many problems in your or nctnico's posts, and see a lot of good points, most of which I totally agree with. But this kind of forum babble doesn't give enough information about how you would really succeed in a complex, real world project, with real-world constraints.
Also, I trust that a real team doesn't need to agree on everything; but instead of arguing, or even worse, compromising trying to find the "middle road", they should be all doing things in a way which they are most productive; summing their (different) skills.