How to Evaluate Engineering at a Technology Company
How to Evaluate Engineering at a Technology Company
Evaluating companies from the perspective of a software developer.
Evaluating companies from the perspective of a software developer.
This is the second in a series of posts looking at how to evaluate your current or future employer as a company. Read Part 1 here.
Last time I gave you an idea of what to look for when evaluating top level management at a company. But when we look at truly great technical companies, this is only a part of their story. Just as important as great leadership (or possibly even because of great leadership) is the engineering team.
What does engineering mean?
When I say “engineering” I don’t necessarily mean fancy UML diagrams or the quantity/speed/deployment of the servers. I really mean answering two fundamental questions:
How are technology decisions made?
How good is the technology being used?
How are technology decisions made?
The first component of good engineering has nothing to do with the actual tools, but the people who make decisions about those tools. These people are part of a balancing act, an act which any software developer has participated in on an almost daily basis:
Do we want to make money or do we want to build the best software we possibly can?
Sometimes, building great software and making money go hand in hand. Systems that are well constructed are cheaper to maintain and thus save the company money. Speed and efficiency in the code often translates to happy customers, who are willing to spend more money on the software.
However, there are many times when YAGNI is an appropriate response to a complicated design, even if that design is better.
The best kinds of companies are able to walk the fine line between developing beautiful software and developing software that makes money.
In fact, writing terrible code quickly can actually work for a while, but it limits growth and usually ends up collapsing under its own weight at some point.
How do you know if a technology company is walking this fine line? Here are a few things to watch out for:
“This is Joe and he knows everything about the software!” — A lot of software companies have one developer who wrote a lot of the code, failed to document anything, and is used to working as a lone wolf. These people are great, and can succeed on teams, but if you hear this a lot about a piece of software you can expect that maintaining or changing it will be no picnic.
Buzzword Bingo — If you hear a lot of buzzwords from a software team make sure to ask a lot of questions. Many software developers are guilty of chasing the next big thing without justification for why they are doing it or what the cost of that chasing might be.
In software development, “why?” shouldn’t mean “why is this good?”, it should mean “why does the business need it?”
In fact, many times the buzzwords can cover up the reality that large portions of the mission critical software don’t actually implement those buzzwords. If a team says they are using React or Angular, how much of their actual software uses React or Angular? Is it the whole web application, or are they just now working on the first React/Angular page and the rest uses jQuery?
Know Your Customer — How much do the developers really know about their end user? How much do they know about the business they are in? If they don’t know enough about the product then they won’t be effective at making judgement calls when it comes to the technology vs. business needs.
How good is the technology being used?
Every company has a Pentium 4 desktop somewhere, covered in soot and cobwebs, that runs an Access database used by 4 people to coordinate spreadsheets about widget production. When I ask how good the technology is, I’m not talking about this Pentium 4. I’m asking about the core technology the business is based on.
As a developer you will have to draw your own conclusions about what this technology actually is, but it should be the intellectual property that, if given away, would allow someone to compete with this company.
When you think about this technology, you don’t necessarily need to know how it works to understand whether it is good or bad. You should be able to pull some wisdom from company employees by asking a few questions.
What do you think about your technology stack?
To be clear, almost no-one loves their current technology stack, even if it is built with the latest and greatest javascript framework from Mars. In fact, if you meet someone who does love it, there is a good chance they are either: (a) a young developer who hasn’t learned to self-hate yet, (b) an old hand who has given up learning the latest and greatest, or (c) a member of a cult.
If you run into a company who can’t find fault with their technology stack, you should run away as far and as fast as you can.
On the other hand, the amount of hemming and hawing you hear about a core technology from the development team should tell you something. How much do they really like working with it? How far do they believe this technology can take them?
If the core development team at the company has a bad feeling about how good their proprietary technology is, why doesn’t the business recognize it?
A technology business built on an aging or fragile technology isn’t a place you will want to be in a few years.
Of course, all technical stacks eventually decline over time. Some get replaced and many live on for a long time. But do you really want to invest your future in one that is already aging?
How are you storing your data?
This may seem like a silly, and very specific, question. However, many times it can tell you a lot about where a technology stack lands on the hype curve and how decisions are made about which technologies to use.
A lot of progress has been made in the last few years with the advent of the NoSQL movement and Big Data. We have seen the rise and decline of many of these technologies along with subsequent backlash and talk of RDBMS strengths and weaknesses.
How a company stores different types of data, and what they do with it, can tell you a lot.
How do they store unstructured data? — For all the back and forth about new tools and technologies, one thing seems to have become clear. Unstructured data, like log files and tracking information, is usually stored in a NoSQL/Big Data format these days. If someone is storing massive amounts of unstructured data in a traditional RDBMS or on the file system, you might want to question some of their technology decisions.
How do they store structured data? — Just as important as unstructured data is the typical application configuration and user facing information. There have been quite a few advances in technique over the years for sharding data, building data warehouses and creating data stores that make sense. You should turn a critical eye to how much attention an organization pays to storing this data.
What do they use for a caching layer? — At this point, the rise of caching mechanisms (particularly Memcached and Redis) means that almost no one should be doing their caching or session storage in a database or other system. If they are, you should seriously question how advanced they are as a technical organization.
Just like with management, engineering is an important component of any great company. Also, just like management, finding the ideal combination is nearly impossible. When you evaluate the team you should always be asking yourself:
How are technology decisions made?
How good is the technology being used?
Next time I’ll finish up with the third component of a great technology company: Product Management.