I once signed on to a job where I was told “we’ll get you any environment and setup you wish” — which really meant ‘we’ll give you a 15” MacBook Pro, and hey, VirtualBox is free if you want to run Linux, and we’d rather you didn’t, but we won’t stop you.’
I didn’t leave because of this (I almost did), but I ended up leaving that job for isomorphic reasons, related to something else.
Oh that reminds me of a job I had once where they offered Windows or Mac computers for devs. I despise Macs so I went with the Windows box.
Literally nothing worked right. What little documentation they had assumed the Mac. Every single one of the other programmers at the company used the Mac so none of them had anything helpful to say at all. Build scripts all assumed macisms.
It was awful and I didn’t stick around for very long. Basically the whole experience there - technical and otherwise - was “we offer these things up front but if you don’t choose the same as everyone else you’re a pariah.”
I’m not sure that’s a realistic request to make of the companies. Sure, it would be amazing to know all that beforehand, but I think no company is proud of having a somewhat broken deployment process or no proper CI.
I suspect, that if they were all open about that, they’d have a hard time hiring anyone.
And I can totally see how some of the awful setups described in the article came into existence.
The major thing for me is, whether they let you make improvements. Because if you’re allowed to change things for the better, a worse starting situation might be overall preferable to a mediocre one, where you’re not allowed to touch anything.
I can appreciate how it’s hard, but FWIW I think I’d advocate doing it anyway because having difficulty with employee hiring (when people don’t like what they hear in the interview) is much cheaper than having difficulty with employee retention (when people don’t like what they find out on the job, after you’ve paid the cost of onboarding them).
Separately, this also provides another channel for feedback. Candidates’ reactions to an honest description of your deploy pipeline gives you an idea of where you are relative to the rest of the world.
If a company is honest about their problems during the hiring process there are two reasons that the candidate might pass on the job.
The candidate is turned off by the problems
In my opinion this is very rare. Most people I can think of will be excited by the potential of improving things and making them better.
The candidate understands that the problems are the symptoms of having a broken/non-existent engineering culture and by joining the company they will simply join the dumpster fire without being able to do anything about it
I think the parties involved in a job interview should be brutally honest with each other. It’s like any other partnership or relationship. You can’t trick people into it for long before it backfires so start it right.
My experience recruiting people to a company with a so so dev experience is that people respond really well to honesty. I try to tell candidates what we do well, what we don’t do well, and what we are doing to fix the latter.
Sure, it would be amazing to know all that beforehand, but I think no company is proud of having a somewhat broken deployment process or no proper CI. I suspect, that if they were all open about that, they’d have a hard time hiring anyone.
If a company has a problem so big that it would prevent them from hiring people if it were known, then fixing it should be a top priority. It’s not just that being able to do your job shouldn’t be treated like a perk – but it deserves mentioning that it’s really stupid to hire smart people, and not give them the tools they need to work at their full potential. But if it’s so bad that it prevents them from hiring good people, there’s a good chance it’s also preventing them from keeping good people around, with all the problems that entails: no way to disseminate information, no way to grow expertise and so on.
I’ve worked in a place that had one of… you know what, actually the setup they had was worse than anything described in that article, on every level. I can’t describe how awful it was in detail, because it’s rage-inducing – let me just say, as a first example, that after making a one-line change, it took 15-20 minutes to do the commit, and that there was a reasonable chance (about once per month) that attempting to do it would corrupt your local copy of the repository and you’d have to make a new one from scratch, which took about 4-6 hours.
Nobody left because of that, but as soon as things got a bit tough, it quickly became the straw that broke the camel’s back. Someone would ask you when you’d push your fix – right as your local copy would get corrupted, right before your eyes, and you’d be looking at staring at a progress bar for the next six hours. Hopefully you’d backed up your files, too, otherwise you had to redo it from scratch. If that happened at about 4 PM on the day before the release, you were the lucky winner of spending a night at the office because there was no way you’d even have something to compile, let alone test and push, before 10 PM.
Okay, no infrastructure is ever perfect. Anything can be improved. But there’s a long way from “our deployment process needs two minutes of handholding and our CI pipeline could be better, but we’re working on it” to “our deployment process involves an 80-step manual procedure where step 42 involves rlogin-ing to a server halfway across the globe and ssh-ing into about twelve servers by hand, and we don’t do CI, one of us manually does a test suite every afternoon, by rotation”. Okay, you shouldn’t “advertise” these things in an interview, but if they’re so common that they’re “the dev experience”, not a temporary situation while you’re transitioning to another set of tools or whatever, that is a problem. It shouldn’t be mentioned in an interview for the same reason you don’t mention you have a release tomorrow – because everyone should be working on fixing it around the clock.
IMO it is totally realistic and I’ve done this exact thing. You need to set the tone that you are interviewing them as much as they are you. If you are desperate for a job, then yes, it doesn’t make tactical sense to ask this.
Otherwise if you are not desperate, you can ask this, and it actually gives you leverage. Think about it: your reaction to their answer to this question means a lot. If you react in a positive way, as in, you understand this is common and that you look forward to dealing with it and improving things, it can look really good on you. As an anecdote, the interview process I went through had 3 phases and I got to the last phase. Honesty and by extension courage display self-reliance.
I’m not advocating dishonesty.
When asked about your engineering practices and workflows you should definitely answer honestly. (And I guess it’s a good question for an interviewee to ask at an interview)
What I’m saying is that maybe you shouldn’t always proactively announce all the warts and issues with your workflow (which also requires that you’re aware of them, which I suspect in enough cases is just not the case. If for example all your staff is using MacBooks you probably don’t even notice that this could be a problem until you have your first hire who doesn’t want to use a MacBook).
I’m sure the process has changed (it changed even while I was there) but writing this down and sharing it let people self select.
I think a good way to do this, which might address some of the other comments about companies not being able to do this, would be to highlight the positive parts of your development process. Candidates aren’t dumb and can read between the lines. They can also ask questions during the interview process.
However, I expect that most larger places have different SDLC maturities across teams, locations or departments, so for this to work they’d all have to write blogs. Which may not be reasonable.
Personally, I don’t think I really trust corporate tech blogs enough to gain any useful insight from them.
Did the author have a manager checking what they wrote to make sure it paints the company in a good light?
Even if the post author is given relative freedom to write about their subject, are the blog topics are narrow, marketing-approved selection which, while honest in themselves, do not cover less positive aspects of the company?
Is the development process described a reality, or is this a dream which they agreed on, which subsequently fell by the wayside when things got busy?
My point is not that they’re all lying, but that it’s not always easy to tell which is which.
There are so many tech blogs which just read as the result of a manager saying, “Fred, go and write a page or two about whatever it is you do, so that we look trendy”. No matter how good Fred is at what he does, the results are flawed, and largely uninteresting:
The author has been given a small amount of time to produce the post, so it is not well thought out or well written. Reviewing and revising posts are not considered a worthwhile use of time.
It is mainly focussed on internal methods or processes, but is written for an external audience, so even if it is ostensibly about a piece of open source software, or a development style, it’s often full of vague references to internal tooling which the readers can only imagine.
There is rarely any attempt to engage with the readers or listen to feedback. Nobody has time to “waste” moderating a comment section, and potentially having critical responses below the post would be considered risky (either you leave them, and they sully the pristine image you tried to present, or you remove them and risk driving away the only people who were interested in your posts).
I guess I’d say that some information, even if you aren’t sure exactly what the truth of it is, is better than none. At the least it gives you a sense of the direction of the company. After all, if someone writes about java or clojure, you know something about the internals of their systems.
And it also gives you a hook to ask questions. If you ask about a step of their deployment process and get awkward silence or hems and haws, well, that is useful.
D or E is Facebook — you can run Linux natively on your laptop at FB (you can choose a Thinkpad if you want native Linux support), but I’m not sure how well-supported virtualization on a Mac laptop is if you choose to go with a Mac.
Things also may have changed since she worked at FB, since that was a while ago; maybe they didn’t support native Linux laptops back then, and only supported virtualized Linux.
At least as of a few years ago Lyft was A, as far as I’ve heard (had a former coworker from Lyft). But things may have changed significantly since then.
TBH most startups start with A and gradually move towards something else, typically when A becomes painful to work with. Dropbox was A for a while, Airbnb was A for a while, etc. I think this is mostly a function of tooling investment and maturity at a company.
I once signed on to a job where I was told “we’ll get you any environment and setup you wish” — which really meant ‘we’ll give you a 15” MacBook Pro, and hey, VirtualBox is free if you want to run Linux, and we’d rather you didn’t, but we won’t stop you.’
I didn’t leave because of this (I almost did), but I ended up leaving that job for isomorphic reasons, related to something else.
Oh that reminds me of a job I had once where they offered Windows or Mac computers for devs. I despise Macs so I went with the Windows box.
Literally nothing worked right. What little documentation they had assumed the Mac. Every single one of the other programmers at the company used the Mac so none of them had anything helpful to say at all. Build scripts all assumed macisms.
It was awful and I didn’t stick around for very long. Basically the whole experience there - technical and otherwise - was “we offer these things up front but if you don’t choose the same as everyone else you’re a pariah.”
I’m not sure that’s a realistic request to make of the companies. Sure, it would be amazing to know all that beforehand, but I think no company is proud of having a somewhat broken deployment process or no proper CI. I suspect, that if they were all open about that, they’d have a hard time hiring anyone. And I can totally see how some of the awful setups described in the article came into existence.
The major thing for me is, whether they let you make improvements. Because if you’re allowed to change things for the better, a worse starting situation might be overall preferable to a mediocre one, where you’re not allowed to touch anything.
I can appreciate how it’s hard, but FWIW I think I’d advocate doing it anyway because having difficulty with employee hiring (when people don’t like what they hear in the interview) is much cheaper than having difficulty with employee retention (when people don’t like what they find out on the job, after you’ve paid the cost of onboarding them).
Separately, this also provides another channel for feedback. Candidates’ reactions to an honest description of your deploy pipeline gives you an idea of where you are relative to the rest of the world.
If a company is honest about their problems during the hiring process there are two reasons that the candidate might pass on the job.
In my opinion this is very rare. Most people I can think of will be excited by the potential of improving things and making them better.
I think the parties involved in a job interview should be brutally honest with each other. It’s like any other partnership or relationship. You can’t trick people into it for long before it backfires so start it right.
My experience recruiting people to a company with a so so dev experience is that people respond really well to honesty. I try to tell candidates what we do well, what we don’t do well, and what we are doing to fix the latter.
If a company has a problem so big that it would prevent them from hiring people if it were known, then fixing it should be a top priority. It’s not just that being able to do your job shouldn’t be treated like a perk – but it deserves mentioning that it’s really stupid to hire smart people, and not give them the tools they need to work at their full potential. But if it’s so bad that it prevents them from hiring good people, there’s a good chance it’s also preventing them from keeping good people around, with all the problems that entails: no way to disseminate information, no way to grow expertise and so on.
I’ve worked in a place that had one of… you know what, actually the setup they had was worse than anything described in that article, on every level. I can’t describe how awful it was in detail, because it’s rage-inducing – let me just say, as a first example, that after making a one-line change, it took 15-20 minutes to do the commit, and that there was a reasonable chance (about once per month) that attempting to do it would corrupt your local copy of the repository and you’d have to make a new one from scratch, which took about 4-6 hours.
Nobody left because of that, but as soon as things got a bit tough, it quickly became the straw that broke the camel’s back. Someone would ask you when you’d push your fix – right as your local copy would get corrupted, right before your eyes, and you’d be looking at staring at a progress bar for the next six hours. Hopefully you’d backed up your files, too, otherwise you had to redo it from scratch. If that happened at about 4 PM on the day before the release, you were the lucky winner of spending a night at the office because there was no way you’d even have something to compile, let alone test and push, before 10 PM.
Okay, no infrastructure is ever perfect. Anything can be improved. But there’s a long way from “our deployment process needs two minutes of handholding and our CI pipeline could be better, but we’re working on it” to “our deployment process involves an 80-step manual procedure where step 42 involves rlogin-ing to a server halfway across the globe and ssh-ing into about twelve servers by hand, and we don’t do CI, one of us manually does a test suite every afternoon, by rotation”. Okay, you shouldn’t “advertise” these things in an interview, but if they’re so common that they’re “the dev experience”, not a temporary situation while you’re transitioning to another set of tools or whatever, that is a problem. It shouldn’t be mentioned in an interview for the same reason you don’t mention you have a release tomorrow – because everyone should be working on fixing it around the clock.
IMO it is totally realistic and I’ve done this exact thing. You need to set the tone that you are interviewing them as much as they are you. If you are desperate for a job, then yes, it doesn’t make tactical sense to ask this.
Otherwise if you are not desperate, you can ask this, and it actually gives you leverage. Think about it: your reaction to their answer to this question means a lot. If you react in a positive way, as in, you understand this is common and that you look forward to dealing with it and improving things, it can look really good on you. As an anecdote, the interview process I went through had 3 phases and I got to the last phase. Honesty and by extension courage display self-reliance.
I’m not advocating dishonesty. When asked about your engineering practices and workflows you should definitely answer honestly. (And I guess it’s a good question for an interviewee to ask at an interview)
What I’m saying is that maybe you shouldn’t always proactively announce all the warts and issues with your workflow (which also requires that you’re aware of them, which I suspect in enough cases is just not the case. If for example all your staff is using MacBooks you probably don’t even notice that this could be a problem until you have your first hire who doesn’t want to use a MacBook).
This is why I love engineering blogs. I wrote one for a previous job: https://www.culturefoundry.com/cultivate/technology/the-culture-foundry-development-process/
I’m sure the process has changed (it changed even while I was there) but writing this down and sharing it let people self select.
I think a good way to do this, which might address some of the other comments about companies not being able to do this, would be to highlight the positive parts of your development process. Candidates aren’t dumb and can read between the lines. They can also ask questions during the interview process.
However, I expect that most larger places have different SDLC maturities across teams, locations or departments, so for this to work they’d all have to write blogs. Which may not be reasonable.
Personally, I don’t think I really trust corporate tech blogs enough to gain any useful insight from them.
My point is not that they’re all lying, but that it’s not always easy to tell which is which.
There are so many tech blogs which just read as the result of a manager saying, “Fred, go and write a page or two about whatever it is you do, so that we look trendy”. No matter how good Fred is at what he does, the results are flawed, and largely uninteresting:
Those are fair points.
I guess I’d say that some information, even if you aren’t sure exactly what the truth of it is, is better than none. At the least it gives you a sense of the direction of the company. After all, if someone writes about java or clojure, you know something about the internals of their systems.
And it also gives you a hook to ask questions. If you ask about a step of their deployment process and get awkward silence or hems and haws, well, that is useful.
It would be fun to know which one is Google, which is Facebook, Lyft, etc as we know she’s worked at those places.
Some of this just sounds incredibly broken.
C is Google.
D or E is Facebook — you can run Linux natively on your laptop at FB (you can choose a Thinkpad if you want native Linux support), but I’m not sure how well-supported virtualization on a Mac laptop is if you choose to go with a Mac.
Things also may have changed since she worked at FB, since that was a while ago; maybe they didn’t support native Linux laptops back then, and only supported virtualized Linux.
At least as of a few years ago Lyft was A, as far as I’ve heard (had a former coworker from Lyft). But things may have changed significantly since then.
TBH most startups start with A and gradually move towards something else, typically when A becomes painful to work with. Dropbox was A for a while, Airbnb was A for a while, etc. I think this is mostly a function of tooling investment and maturity at a company.