9 ms·

I've been thinking about low-friction options for getting a sense of the engineering quality. I don't think I'm alone in thinking that technical debt and bad so

by latch 8y ago

I've been thinking about low-friction options for getting a sense of the engineering quality. I don't think I'm alone in thinking that technical debt and bad software development practices are a top concern. Being quite senior now, I'd feel comfortable asking: 1 - To see their CI dashboard 2 - To see a sample of their production systems stdout & stderr 3 - Asking to review a recent non-trivial commit (with the person/people who wrote it) 4 - If you're interviewing remotely for an on-site position, finding out if they have an open office 5 - Finding out how they do deploys / devops

kodisha 8y ago
In scenario of: - If you get the money and opportunity to hire really senior/well known dev to lead your eng. team, would yo do it - Ummm no, we believe in our team, and their strong knowledge, there is no problem they cannot solve (or something along those lines) Run.
- peterlk 8y ago
  I think I understand what you're saying, but I think you're oversimplifying, and that would do a disservice to people who may be new to the job market. Just because someone is a big name doesn't mean they're the right fit to lead a team - some of the best engineers I've ever met have no interest in leading teams, but are very valuable to have on the team. Hiring well, and believing in the team that you've hired is important, and I think it's a red flag to see management churn. To me, the red flags are absolutes. i.e. "Yes, we would absolutely replace our team lead because we only want the best" sounds like a toxic place, and it's not the kind of place I would expect to find (most of) the best engineers that I've worked with. And "No, we would never hire that person because our team is the best" sounds arrogant or naive.
  - kodisha 8y ago
    Exactly, thanks for clarifying. I've seen this behaviour where existing employees were forming a "cult" to cover each other, and promote one another, while technical debt piled up, and at the end basically brought products to a halt. I'm not saying that VIP hire is some magic stick that will fix everything, but if they consider a taboo to even mention such a thing, this is not a environment to be in.
codingdave 8y ago
I disagree - tech debt and bad practices can be fixed with good leadership. But poor leadership will never give you the opportunities to make such corrections. I do agree that knowing the status quo is useful, but the trajectory the organization is on is more important than today's exact position. I ask questions more along the lines of what is wrong, and how are they correcting it. Good answers there can show a good long-term result. Bad answers there... run away.
- qaq 8y ago
  Isn't it a matter of ones preferences though? Even if the leadership is capable if a person finds day to day work with crappy codebase and poor tooling a drag there is no point in joining.
  - profalseidol 8y ago
    Then leadership isn't capable. I wonder if it's simply the balls to tell top management that we need to invest in training, refactoring etc. And selling it that it will payoff. The usual answer I get when I propose this, is that "we're too busy with projects".
Waterluvian 8y ago
In the context of a startup, I would expect almost all of those to be disappointing. But maybe that's what you're hoping to see. In my opinion, if you're a start-up and you've got all those boxes checked, you're possibly doing the right things in the wrong order, and that's a red flag for me. What I hope to hear are responses like, "so this is how we're doing CI. It's awful, almost non-existent. But that's because at our scale it just wasn't important. But as we grow it will become VERY important, so here's what we're thinking about doing in the next 6-12 months..." I've experienced a start-up with lots of tooling and process , none of which matters when you take forever to ship (and stay shipped).
- owens99 8y ago
  This. As I always say, "If you are building a startup, over-engineering is a far bigger sin than creating technical debt."
  - andbberger 8y ago
    That's just a cop out! Such a tired meme!
    - angersock 8y ago
      It's true though. What's your counterargument? Tired memes can be tired because they're true.
      - hobofan 8y ago
        If you want your startup to run for more than a year (= roughly the time the effects of technical debt start to kick in significantly in my experience), you need to find a good way how to handle technical debt, and keep it in check. I have seen my share of startups where a platform plagued with technical debt was the main limitation for growth, which is a very avoidable situation.
        JumpCrisscross 8y ago
dustingetz 8y ago
Idea: Startups, even moreso than mature businesses, behave similarly to organisms and exist on a fine balance between life and death. Corollary #1: all startups, almost definitionally, have the maximum amount of technical debt possible without dying (otherwise they would "move faster and break more things"). Corollary #2: Startups whose core business is selling to developers (as opposed to applications of software) are much more sensitive to technical debt.
onion2k 8y ago
"How do you feel about Friday afternoon deploys?" is a great question for that. Many interviewers assume you want to hear about how they refuse to do them in order to protect your Friday night and weekend time. Really, the answer you want is that they've automated the deploy process and made it robust enough not to break production so it doesn't matter when a deploy happens.
- Cursuviam 8y ago
  Automated deploys aren't a magic bullet and can still break production, even at a big megacorp with tons of infra and tests to keep prod safe.
  - onion2k 8y ago
    Of course not, but the process of automating deploys (or anything really) makes you think through what can go wrong, and ways to mitigate problems, and put tests in place to make sure things worked, and add metrics, and test your rollback procedure, and so on. A company that doesn't have automated deploys is much more likely to have manual processes for more things than just deployment. It's not a magic bullet, but in my experience it's a very good indicator of how a company approaches an obvious problem, so you can get a really clear signal about whether or not you'd enjoy working there.
alain94040 8y ago
I disagree with your checklist. Assuming you are interviewing for a very early employee (first 10 at most), then all those are technical issues that you will be able to fix. That's not a problem, that's your job and you are good at it. I would worry a lot more about the business itself. Does it make sense? Do you see a credible path to paying customers? And the most important of all: are the founders the right people to grow and lead this thing? Could be experience or passion (ideally they should score high on both).
zoomablemind 8y ago
This is almost like meeting your future team-mates. After all they too have to cope with this day to day. So this paints some practical context.
sarthakjain 8y ago
Most early stage companies would have had terrible answers to these questions. Including Facebook/Google/Uber/Amazon. Which just indicates that it might not have been an ideal role for you which is fair. Being the first 2-3 engineers at a startup is not everyone's cup of tea. The risk in most cases makes no sense for a sane individual. Your questions indicate a sense of "safety" that an engineer might want from their next gig. They might not even be able to hire a Senior Engineer in most cases. Maybe you wouldn't even want to talk to an early stage startup at your current seniority level. Having said that for anybody who really wants to join an early stage startup the only thing that should probably matter is what is it that you're trying to do and how can I help you reach your goal? Will you be able to pay me enough on time and for how long?
- cc81 8y ago
  CI/CD can be set up pretty quickly with modern tools. You can of course spend time over engineering with lots of different environments that you can create with scripts but just setting up a basic pull request->build->run tests->automatic deploy->promote to higher environments is like one days work for one person these days.
burtonator 8y ago
Some of these are actually good points because as a software engineer I pride myself in thinks like code documentation, comments, logging, etc. Another idea would be to see their event and analytics dashboard for their infrastructure KPIs. If they don't have one it's a bit of a red flag.
TuringNYC 8y ago
I've found the 12-item Joel Test to be great. https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... PS: Yes! Shockingly not all startups use source control.
- 1_800_UNICORN 8y ago
  Re: source control, this was also written in the year 2000...
apl002 8y ago
open office plans are so terrible. I am job #3 now with them. Thank god for Bose QC35's but still its so unproductive
madrox 8y ago
I think if a company has good answers to these questions, then they aren't really a startup. More often than not, if they're hiring you (being quite senior) it's because they need you to do all those things. But I do get where you're coming from. In my experience, it's better to ask about the team and its CTO to understand how decisions get made, and if the team is capable of recognizing quality. I don't care if CI isn't in place when I join as long as the team recognizes its importance and knows they need to get to it.
tzhenghao 8y ago
I'd like to say this is true, but I think in practice, you want early engineers to have the right technical + mental frameworks around good software development practices, and the current implementation may not reflect this (false negative). It's a good to have, but not a top concern imo. One of the startups I worked with didn't have "good" practices just like what is listed above, and it took a while to get there. The thing is, we're still pulling quite healthy numbers, and we have paying customers. What made it bearable was our engineers knew what needed to be done, and had the technical chops to get there. You'll probably want to avoid very elitist engineering cultures that aren't open to what's considered good practices. Many successful startups run on the shadiest software architecture in the early days, but market pulled product out of the startup. Today, they have the engineering resources to make it a lot better.
xz0r 8y ago
Would you always avoid an open office ?
blablabla123 8y ago
> 2 - To see a sample of their production systems stdout & stderr That's a good one, definitely gonna ask this at the final interview stage of my next job. It very much indicates how people work, whether they spend a lot of time fitting in features into a difficult code base or if things are just working a features a developed at a predictable pace. (On prod won't stop working on weekends)

by latch 8y ago

kodisha 8y ago

In scenario of: - If you get the money and opportunity to hire really senior/well known dev to lead your eng. team, would yo do it - Ummm no, we believe in our team, and their strong knowledge, there is no problem they cannot solve (or something along those lines) Run.

peterlk 8y ago
I think I understand what you're saying, but I think you're oversimplifying, and that would do a disservice to people who may be new to the job market. Just because someone is a big name doesn't mean they're the right fit to lead a team - some of the best engineers I've ever met have no interest in leading teams, but are very valuable to have on the team. Hiring well, and believing in the team that you've hired is important, and I think it's a red flag to see management churn. To me, the red flags are absolutes. i.e. "Yes, we would absolutely replace our team lead because we only want the best" sounds like a toxic place, and it's not the kind of place I would expect to find (most of) the best engineers that I've worked with. And "No, we would never hire that person because our team is the best" sounds arrogant or naive.
- kodisha 8y ago
  Exactly, thanks for clarifying. I've seen this behaviour where existing employees were forming a "cult" to cover each other, and promote one another, while technical debt piled up, and at the end basically brought products to a halt. I'm not saying that VIP hire is some magic stick that will fix everything, but if they consider a taboo to even mention such a thing, this is not a environment to be in.

codingdave 8y ago

I disagree - tech debt and bad practices can be fixed with good leadership. But poor leadership will never give you the opportunities to make such corrections. I do agree that knowing the status quo is useful, but the trajectory the organization is on is more important than today's exact position. I ask questions more along the lines of what is wrong, and how are they correcting it. Good answers there can show a good long-term result. Bad answers there... run away.

qaq 8y ago
Isn't it a matter of ones preferences though? Even if the leadership is capable if a person finds day to day work with crappy codebase and poor tooling a drag there is no point in joining.
- profalseidol 8y ago
  Then leadership isn't capable. I wonder if it's simply the balls to tell top management that we need to invest in training, refactoring etc. And selling it that it will payoff. The usual answer I get when I propose this, is that "we're too busy with projects".

Waterluvian 8y ago

In the context of a startup, I would expect almost all of those to be disappointing. But maybe that's what you're hoping to see. In my opinion, if you're a start-up and you've got all those boxes checked, you're possibly doing the right things in the wrong order, and that's a red flag for me. What I hope to hear are responses like, "so this is how we're doing CI. It's awful, almost non-existent. But that's because at our scale it just wasn't important. But as we grow it will become VERY important, so here's what we're thinking about doing in the next 6-12 months..." I've experienced a start-up with lots of tooling and process , none of which matters when you take forever to ship (and stay shipped).

owens99 8y ago
This. As I always say, "If you are building a startup, over-engineering is a far bigger sin than creating technical debt."
- andbberger 8y ago
  That's just a cop out! Such a tired meme!
  - angersock 8y ago
    It's true though. What's your counterargument? Tired memes can be tired because they're true.
    - hobofan 8y ago
      If you want your startup to run for more than a year (= roughly the time the effects of technical debt start to kick in significantly in my experience), you need to find a good way how to handle technical debt, and keep it in check. I have seen my share of startups where a platform plagued with technical debt was the main limitation for growth, which is a very avoidable situation.
      - JumpCrisscross 8y ago

dustingetz 8y ago

Idea: Startups, even moreso than mature businesses, behave similarly to organisms and exist on a fine balance between life and death. Corollary #1: all startups, almost definitionally, have the maximum amount of technical debt possible without dying (otherwise they would "move faster and break more things"). Corollary #2: Startups whose core business is selling to developers (as opposed to applications of software) are much more sensitive to technical debt.

onion2k 8y ago

"How do you feel about Friday afternoon deploys?" is a great question for that. Many interviewers assume you want to hear about how they refuse to do them in order to protect your Friday night and weekend time. Really, the answer you want is that they've automated the deploy process and made it robust enough not to break production so it doesn't matter when a deploy happens.

Cursuviam 8y ago
Automated deploys aren't a magic bullet and can still break production, even at a big megacorp with tons of infra and tests to keep prod safe.
- onion2k 8y ago
  Of course not, but the process of automating deploys (or anything really) makes you think through what can go wrong, and ways to mitigate problems, and put tests in place to make sure things worked, and add metrics, and test your rollback procedure, and so on. A company that doesn't have automated deploys is much more likely to have manual processes for more things than just deployment. It's not a magic bullet, but in my experience it's a very good indicator of how a company approaches an obvious problem, so you can get a really clear signal about whether or not you'd enjoy working there.

alain94040 8y ago

I disagree with your checklist. Assuming you are interviewing for a very early employee (first 10 at most), then all those are technical issues that you will be able to fix. That's not a problem, that's your job and you are good at it. I would worry a lot more about the business itself. Does it make sense? Do you see a credible path to paying customers? And the most important of all: are the founders the right people to grow and lead this thing? Could be experience or passion (ideally they should score high on both).

zoomablemind 8y ago

This is almost like meeting your future team-mates. After all they too have to cope with this day to day. So this paints some practical context.

sarthakjain 8y ago

Most early stage companies would have had terrible answers to these questions. Including Facebook/Google/Uber/Amazon. Which just indicates that it might not have been an ideal role for you which is fair. Being the first 2-3 engineers at a startup is not everyone's cup of tea. The risk in most cases makes no sense for a sane individual. Your questions indicate a sense of "safety" that an engineer might want from their next gig. They might not even be able to hire a Senior Engineer in most cases. Maybe you wouldn't even want to talk to an early stage startup at your current seniority level. Having said that for anybody who really wants to join an early stage startup the only thing that should probably matter is what is it that you're trying to do and how can I help you reach your goal? Will you be able to pay me enough on time and for how long?

cc81 8y ago
CI/CD can be set up pretty quickly with modern tools. You can of course spend time over engineering with lots of different environments that you can create with scripts but just setting up a basic pull request->build->run tests->automatic deploy->promote to higher environments is like one days work for one person these days.

burtonator 8y ago

Some of these are actually good points because as a software engineer I pride myself in thinks like code documentation, comments, logging, etc. Another idea would be to see their event and analytics dashboard for their infrastructure KPIs. If they don't have one it's a bit of a red flag.

TuringNYC 8y ago

I've found the 12-item Joel Test to be great. https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... PS: Yes! Shockingly not all startups use source control.

1_800_UNICORN 8y ago
Re: source control, this was also written in the year 2000...

apl002 8y ago

open office plans are so terrible. I am job #3 now with them. Thank god for Bose QC35's but still its so unproductive

madrox 8y ago

I think if a company has good answers to these questions, then they aren't really a startup. More often than not, if they're hiring you (being quite senior) it's because they need you to do all those things. But I do get where you're coming from. In my experience, it's better to ask about the team and its CTO to understand how decisions get made, and if the team is capable of recognizing quality. I don't care if CI isn't in place when I join as long as the team recognizes its importance and knows they need to get to it.

tzhenghao 8y ago

I'd like to say this is true, but I think in practice, you want early engineers to have the right technical + mental frameworks around good software development practices, and the current implementation may not reflect this (false negative). It's a good to have, but not a top concern imo. One of the startups I worked with didn't have "good" practices just like what is listed above, and it took a while to get there. The thing is, we're still pulling quite healthy numbers, and we have paying customers. What made it bearable was our engineers knew what needed to be done, and had the technical chops to get there. You'll probably want to avoid very elitist engineering cultures that aren't open to what's considered good practices. Many successful startups run on the shadiest software architecture in the early days, but market pulled product out of the startup. Today, they have the engineering resources to make it a lot better.

xz0r 8y ago

Would you always avoid an open office ?

blablabla123 8y ago

> 2 - To see a sample of their production systems stdout & stderr That's a good one, definitely gonna ask this at the final interview stage of my next job. It very much indicates how people work, whether they spend a lot of time fitting in features into a difficult code base or if things are just working a features a developed at a predictable pace. (On prod won't stop working on weekends)