Joel Spolsky (the guy responsible for Trello and Stack Overflow among other things), wrote an article on his blog about questions you should be asking potential employers as a software developer.
Talking to newer developers I realized that most of them have neither heard of this guy, nor of this set of questions. Not surprising since this famous blog post was written 19 years ago!
I think this test is still relevant and really will weed out some bad employers, but we should update it! Actually, wait it needs a ton of updates... This was written in the days when you went down to the store and had to physically buy software on disks! π€’
OK, here is the original test:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
The idea was, if an employer did all of these things then chances are they would be great to work for as a software developer. So this is a checklist to help you consider if a job is worth taking or not.
Is anyone not using source control?
What sounds outdated here? How about the source control, question - who doesn't use source control? For that matter, who doesn't use git? If they don't use source control they are not doing any of this other stuff. How about the build step - people don't build much desktop software anymore and we are not thinking much in terms of passing builds. The master branch should always pass tests and build!
Lets ask this to cover the question about builds: "Do you have a CI process in place?".
And furthermore, maybe a more relevant question in the age of SaaS apps is this: "can you do one-click deploys?". Or maybe even, "How fast can you deploy a hotfix", that might get an interesting answer.
Do you fix bugs before writing new code?
This is a tricky question. I think most software projects have tons of outstanding issues that maybe can't be fixed or are too hard to fix and you have worked around them. Again, this is more of the mindset of building desktop software you are going to ship in releases once a year and you fix the bugs before the next release... If you are working on a web application you care more about the bugs that are actively going to cause users trouble.
Maybe a better question is this: "How do you monitor you application for errors in production?"
Do you have a schedule?
I'm not exactly sure what he means here even. I think he is talking about when you did desktop software you were going to ship a certain set of features, and when you decide you are done you go mail off the CD-ROMs to your customers. π€£
Let's skip this, and the spec question, and ask about development methodology. Are they doing Agile, Scrum, Kanban? What?
Do programmers have quiet working conditions?
Keep this question! In my opinion open offices are the worst possible thing you can foist on developers. Really? Shove us all in a bullpen with people running around everywhere having loud conversations while we try to do a job that requires insane levels of concentrations. Really, that's a good idea huh? π€¦
Do you use the best tools money can buy?
Here he is talking about things like nice chairs, servers and services. I think this is important but the most important things are basically free these days. You don't need to buy specific compilers and editors. VSCode is free. You just need to hope your company got you a nice computer. Maybe ask about that if you are worried, but in my experience most companies are now getting devs new MacBook Pros.
Do you have testers?
I like having dedicated testers on my team but many places don't anymore and if you have a good process in place for automated testing you can do just fine.
Instead I would ask this: "How do you test code before you deploy to prod"? Then you can decide if you like how they answer.
Do new candidates write code during their interview?
It makes a big difference if you work with good people or not. There is no substitute for seeing if somebody can code or not. You have to actually see it to know (in my opinion). I think this is still a good question to ask.
The answer is yes if the company does any of these things:
- Take home test
- Whiteboard problems
- Pair programming problems
Do you do hallway usability testing?
This is again, about desktop software. You had to test with your users before you shipped the box of CD-ROMs to Circuit City (RIPβ°οΈ).
Now, with web applications people use telemetry services to monitor users and track what they are doing, like Hotjar. You can set up A/B testing and see what users prefer, and you can do it at scale with real users in realtime.
Here is a better question: "How do you collect feedback from users and make design decisions?"
A proposed new set of questions:
- Do you have a CI process in place?
- Can you do one-click deploys?
- How do you track issues?
- How do you monitor you application for errors in production?
- What development methodology do you follow?
- Do programmers have quiet working conditions?
- How do you test code before you deploy to prod?
- Do new candidates write code during their interview?
- How do you collect feedback from users, and make design decisions?
Yeah, I know, originally you could simply say "YES" or "NO" to all of these so it was an easy metric to measure. Now, you get to judge if something is a "YES", but it's still pretty easy.
If you ask "What development methodology do you follow?", and the answer is "We Don't" - well then they fail that question!
I think it's better that some of these are open ended. You can ask them in an interview and sound thoughtful. π€
By the way I originally posted this blog here, which is the blog for a side project I am working on called Alcamine. Basically it is going to be a system where you get a special email you can use to sign up to job sites and we will score and filter all of the junk recruiter email coming into it!
Top comments (2)
This was an interesting read, thank you.
One thing to consider about the original questions is that they are all yes/no questions to easily determine if someone is following no-brainer best practices. I think most of your questions can be re-worded to be yes/no.
For the Agile/Kanban/Scrum question though, I think that can be dropped. They are all equally valid in different situations. Everyone is going to say that they are Agile since you can't easily disprove that. I think that maybe a better question would be "Do the engineers get to do what they believe is important for the company's success?"
Great write up Aaron.
If I may, I am skeptical about questions 5) and 8).
I don't like homework assignments. Devs tend to be perfectionists and end up too often spending too much time working for free on those.
"We do agile/Scrum" in my experience is quite meaningless, everybody do it differently and one should not get bonus points just because one use the right buzzwords.
Two suggestions instead:
5) How do you decide between two solutions for doing something?
8) Who are your clients, which problem do you solve for them and how do you earn money?