I interview a lot of software engineers. Some of them are good, some of them aren't. I do see a general trend that engineers who work for startups are disproportionately likely to have certain gaps in their knowledge. This article lays out those gaps, why I think they occur, and gives questions engineers can ask their prospective employers to ensure that they don't end up with these gaps.
A basic premise of this article is that not all types of practice are equally valuable. A particularly valuable type of practice is known as deliberate practice, and will usually involve:
- Regular and immediate feedback
- Practicing skill "chunks", instead of the entire skill
- Practicing at the edge of your comfort zone
I think a lot of startups are unusually bad at allowing people to have deliberate practice, and this article will explain why.
Would you rather have one dollar in revenue today, or $10 in revenue next year? I think startup founders are unusually likely to prefer the one dollar today, and they are correct to do so.
A more relevant form of discounting comes with technical debt: would you rather spend an hour coding things the right way today, or 10 hours fixing your problems next year?
As a startup, it's not at all uncommon to have a single prospective customer which will increase your revenue by an order of magnitude. Throwing a bunch of crap together to quickly prepare for a demo which will fall apart 10 seconds after the customer leaves the room is exactly the right decision to make: if that demo going well means that you will have an extra $100,000 in revenue; accruing technical debt that will cause future engineers to spend 500 extra hours fixing bugs is a lower cost than the benefit of the additional revenue.
All too often in startups the "rational" discount rate is actually infinite: if you will go bankrupt unless some deal goes through, you should throw everything at that deal regardless of what it will cost you in the future.
This amount of discounting is problematic for deliberate practice. People aren't going to do code reviews, because it's much better to just get something in quickly even if it breaks in the future. And forget performance reviews – your five year career plan is peanuts compared to the imminent bankruptcy of the company.
Questions to Ask Prospective Employers
- What fraction of your pull requests get a code review? In what circumstances do you skip code reviews?
- How frequently do you do performance reviews and what is involved in that process?
There seems to be pretty widespread agreement among database experts that you should never use Mongo. Yet Mongo still seems to be the most popular database choice for startups.
There are some extreme examples of companies going bankrupt because Mongo doesn't support what is literally the first example in any database textbook of ACID-compliance, but for most startups I think the use of Mongo just results in late nights for the development team when data gets lost and a bunch of wasted time trying to force schemas on a schema-less database.
If your application requires user input, you will learn approximately 30 seconds into your career that the user cannot be trusted to enter actual dates into a date field. 45 seconds into your career you will learn that the solution to this problem is to use some sort of schema/type system to set the type of that field as "date" and there the learning stops.
But schema-less databases force you to practice over and over the skill of sanitizing user input – a skill you have already maxed out. All this time is wasted from the perspective of your career growth.
And even if you are learning things, it's questionable how valuable those skills are. I often worry that we are creating a generation of engineers who are experts at anti-patterns like duplicating data so that they don't have to do joins.
Mongo is an easy thing to pick on, but in general startups seem unusually likely to choose technologies because they're trendy and not because they're actually useful.
Questions to Ask
- How strong is your database schema? Do you use a statically typed language? Why or why not?
- (One major reason people use weak schemas and type systems is that it allows you to prototype and move faster at the beginning, even though it costs you more time fixing errors later on. This may be an appropriate trade-off for them to make, but you should be aware of their decision.)
- Why did you choose your current technology stack?
- Better answers will show that they actually understood the trade-offs they were making
A lot of engineers seem to think it looks good on their resume to go straight out of college and get a title like "vice president" or "chief technology officer". And who knows, maybe there are employers out there who are dumb enough to find those titles impressive. But if you are the most experienced person on your team – particularly if you don't have very much experience yourself – that doesn't bode well.
Firstly, if the company is running out of money, your investors are screaming at you to move faster and your customer complaints are piling up, it takes a lot of skill to figure out which corners you can cut and which ones you can't. Unless the leadership team has a lot of experience (and a strong backbone), the company's effective discount rate will be extremely high and it will accrue technical debt at an astonishing rate. "Employee growth" is usually the first thing to go in these scenarios.
Secondly, n important part of deliberate practice is finding skill "chunks" and practicing just those chunks at the edge of your comfort zone. Maybe the chunk you want to practice is scaling SQL queries. A good way to do that is to spend two weeks doing nothing but re-factoring old queries to run faster. A bad way is to spend two weeks working on what the company feels is the highest priority while reading SQL blog posts in your free time. But if you are on a small team, and particularly if you are the most senior person on that small team, it's going to be very hard for you to spend two weeks working on things which aren't the company's immediate priority.
Lastly, power corrupts. We've all written methods whose cyclomatic complexity compares favorably to the size of the national debt, and without someone there to throw up on your code you're probably not going to refactor. Over time, writing complex code will become your default way of doing things.
Questions to ask
- Who is the most senior member of the team and what is their experience?
- I want to learn _____. How will I be able to do this at your company? Can you give an example of someone who worked on a project for learning purposes and how it went?
- What fraction of time do engineers spend re-factoring as opposed to creating new functionality?
Short-sighted leadership, stupid technologies and bad coworkers are things to worry about at any company, large or small. I would recommend asking these questions to any prospective employer.
But particularly if you are planning to work for a startup, I would encourage you to dig deep into these areas and not just assume that the leadership team knows what they're doing.
At Health eFilings we have spent a lot of time fixing these problems to provide a good learning environment for engineers, and we are hiring.