My list would probably look something like:
- ability to use a proper debugging stack (not just tests/printf, use of microbenchmarks for optimisation, systems tracing for services)
- optimisation of how their app interacts with the environment (kernel, network stack, cache lines)
- debugging beyond application level issues (e.g. ability to use core dumps, knowledge of how the JVM works)
I've seen others (and have myself) supported costly features of questionable value. Sometimes a few conversations with product managers and customers have resulted in us entirely dropping a feature.
I could go on.
Notice I didn't mention any specifics (i.e., knows compiler xyz, can use 3D CAD tool abc, etc.). None of that matters. Virtually none of the tools and technologies I use today existed when I was getting started. A simple example of this are FPGA's.
What matters to me isn't what list of "tools and features" a person brings to the table but rather who they are and how they got there. Someone who has the right drive and approach can learn anything, and thrive. That, to me, is what makes a strong engineer.
A couple of decades ago I hired an engineer out of Intel. I though I was going to learn a bunch from him. Quite to the contrary. The guy had spent so many years living in a professional silo that he did not do well in an environment where you have to do more than one thing. At Intel all he did was design power supplies. He didn't even deal with suppliers and order parts, he had groups of people who did that for him. He also didn't do much in the way of PCB layout and did no embedded software at all. It was a very rough start with us. He required a tremendous amount of coaching. In the end what made him keep the job was a strong work ethic and the desire and willingness to learn.
A good attitude, persistence and willingness to "muddle through" Complex/Complicated/Foggy Requirements/Understanding to arrive at a solution is the prime requirement.
Basically, by knowing quantitative bounds of your system, you can make much better / quicker decisions.
1. Being able to spot the point at which the cost of cleaning up convoluted and fragile code is lower than the cost of continuing to work with it. And evaluating that it’s worth the long term investment.
2. Actually being able to turn the ship around.
Knowing when the cost of cleaning up convoluted and fragile code is higher than the cost of continuing to work with it, and when it's not worth the long term investment.
2. Ability to comfortably and independently iterate within unfamiliar problem domains and reason about potential solution paths at varying confidence intervals.
3. Ability to break a complex problem in to multiple smaller problems and document the rationale and assumptions for doing so, with a particular eye to interfaces, maintainability and the human domain.
4. Writes clear documentation and enjoys it.
5. Errs toward solving categories of problems rather than instances thereof, but understands how and when to yoke this tendency.
Ability to communicate clearly to a non technical audience.
Engineers draws plans of their problems, and use them as a starting point for discussion and thinking about design.
Everytime a software developer in my team fails to represent a problem graphically i know they're limited.
One of my colleagues from whom I learnt much used to put assertions instead of print statements and rerun the test suite. Sometimes those assertions were quite complex; they would do a few sanity checks of entire data structures.
While doing benchmarking or profiling, knowing to do back of the envelope calculations to know the minimum and maximum metrics, such as IOps, messages per second, the average queue lengths, database writes and so on. The same colleague above had it honed to a fine discipline. He had memory and cache and db query latencies in his head and could tell if and where something was not right.
“Are we working on the right thing?”
“Is this valuable to work on, right now?”
“Is doing what I am doing the most effective use of my time?”
“How cheap or expensive is it to support what we’re doing? Is feature X worth its cost?”
“Is there opportunity to simplify the solution? Should we reduce scope? How?”
I think in my mind, it’s not always about the tech stack or a specific technical optimization so much as thinking in terms of costs, trade offs, and most importantly, why do something.
On other thing is being able to work with legacy code or code written by others. If your immediate solution is to rewrite something, you lose some points with me.
I'm not joking.
