If I knew then, what I know now…
Questions for developers to ask potential clients
I’m giving up freelancing soon. (Going over to the light side, I am). While I ponder this life change, I wanted to share my list of questions that I ask of myself and my potential clients when interviewing, to find out what kind of environment I might end up in.
I had a good list already (I thought — it covered the basics anyway) but I have to thank my super partner Zac for suggesting, a few times after I kept coming home grumpy from exhausting days at the HTML factory: “well, what questions could you ask in your interview next time that would prevent this?” (and that’s really the first question).
So here they are — and I’m sure this isn’t all of them! But this is what I’ve found out so far.
Starting out
I used this list mainly for picking contracting roles, but there’s definitely crossover with permanent employment too.
As well as my partner, I owe a lot of this to reading The Joel Test at an early stage in my career. It used to be probably the canonical reference for developers looking for new projects, and it’s now somewhat outdated, but lots of those questions still stand, with some changes.
I’m going to ignore the things from that list that really are irrelevant now (surely everyone does user research and has Git and Jira/Trello/Pivotal/something, and if not.. well, it’s nice to be able to introduce people to modern software development practices!)
So what are my key questions that will tell me how my potential client’s team functions and whether I’m a good fit for it?
1. *Can* I do this?
This one is kind of obvious, I hope. I don’t like surprises, and I like to be useful quickly. So what does their tech stack look like?
I like to hear this from the people on the team directly, due to a bad experience once with a recruiter who was confused between Java & JavaScript — not to bash recruiters, it’s an easy mistake to make until you have to write some! It doesn’t have to be another developer, either, on a good integrated team everyone should be able to talk intelligently about other parts of the project, even if it’s not their speciality.
Make sure you’re clear with them — and yourself— about what your skills are. Maybe on a longer term project they won’t mind you learning a new templating language on the job, but someone on a deadline might want you to be an expert before you walk in the door. Either is okay, as long as both sides know what they’re getting into.
2. Do I *want* to do this?
Do I agree with the company’s mission & values? Do I actually enjoy working with their technology choices? (As opposed to just being able to use them). Is the office easy to get to? (Because I am very lazy).
Does the team seem happy and into their work? Or are they overworked and stressed? Don’t forget to ask to meet the team and see the office you’ll work in. This is where you can quiz the product managers about their specific roles in the process (coming up in question three!)
Not all of these questions have to be answered in the positive. Maybe it’s a boring widget shop but you’ll get paid to learn a new framework. Maybe it’s not very well paid at all, but the office is five minutes from your house so you’ll be able to sleep in later or pick the kids up from school. Maybe it’s eBay for arms dealers and really quite lucrative and a few months here will allow you to finally take that sabbatical (okay, please don’t actually do this). The point is that you get to decide — this question is about figuring out your own personal limits and lines, and where you’re prepared to make trade-offs.
3. What project management processes do they have in place?
To be honest, I personally am not married to any particular flavour of Scrum or Kanban or whatever an organisation has picked out to work for them. What’s important to me is that whatever they’re doing, the whole team is engaged and involved with it. Everyone you meet should be able to describe not just how they’ve implemented whatever-it-is, but also know the good and bad things about how they’re doing. Hopefully some of these answers will even match! This is a good time to ask: what will my actual daily process of development look like? — will I be working with designers, or do PSDs just get “thrown over the fence”? Does the entire team sit together? (ie, will I just be throwing templates and CSS over another fence?) What is the ‘flow’ of a feature from start to finish?
How do they give feedback?
I am especially interested to find out “how do I get feedback on my code?” (Pairing? Code review? How often? How long does it take a feature to get reviewed?) and “do they have coding standards/guidelines?”. With tools like EditorConfig and automated linters it doesn’t really matter what the standards are, as long as there are some and everyone (tries to) abide by them.
I want to produce work that is useful to everyone— there’s no point toiling over something if it’s not going to be acceptable to the rest of the team or the end users of the product. So knowing when you go into somewhere that the team already has a known process for building and improving their codebase is important.
What is the release schedule for this project?
Apart from deciding if I’m happy to take on a project with a stiff deadline, what I also want to know here is “How long does it take a developer to get feedback from stakeholders on their specific piece of work, and how long does it take to get that same feature into production?”. Hopefully these two answers will be similar (and also short) amounts of time, because it’s frustrating to work on something and see it sit in a release queue. If they don’t know this or can’t show you someone who does, run fast in the opposite direction. You could be in that holding pattern for years.
4. What development practices do they follow?
There are a bunch of technology-related processes that make your life as a developer much much easier. Make sure your client follows them.
Do they have automated builds and tests?
Great! The missing question here is: and how long does it take to run them? Locally, in testing/staging and to actually deploy? If anything running tests locally/on staging is more important, since it’s what keeps the automated testing feedback loop tight. There’s hardly any point in doing a daily build if it takes the entire day. That way lies branching merge conflict hell in an office. Even Git isn’t up to merging twenty feature branches, hotfixes and releases every day if the process isn’t there to back it up.
Do they do daily (or more) builds?
Yes please! But — build to where? What if your project is one of those “Yeah, we’re totally releasing daily or even continuously to our test server and we’ll do a big production release at the end”? That can work out badly when it turns out your project manager never got the client to actually look at your staging server and you all find out they didn’t actually want what you built six months down the line. There are few things more demoralising than nobody ever using that amazing thing you worked on. Ideally there will be a short time frame from when you work on something, to when you get it out to end users.
Do they have suitable separate staging/UAT environments?
“Don’t deploy to staging, the CEO is demoing!” — ‘nuff said. Of course there are other ways around this problem that the above questions can help you ferret out. But if you start to suspect that some of the above might not be true, this one is useful.
5. Logistics (AKA, can they afford you?)
Do a credit check. Definitely check the organisation at Companies House and make sure they are at least registered and look like they’ve got money in the bank (or did however long ago the report is from). They still might pay your invoices late anyway, but it’s worth a small amount of piece of mind.
Ask about revenue, projected income, growth and future hiring and firing plans. (On the latter, you might be able to recommend other developers or designers and get to work with that amazing person from your last job).
Start date, end date, daily rate. Get your contract reviewed by a lawyer whose actual job it is to read them and explain them to you in smaller words. Contracts are stupidly hard and dangerous (and expensive) to get wrong. Make sure your contract specifies your invoicing terms and what happens if they aren’t followed (on one painfully memorable occasion, this would have saved me several months and thousands of pounds if I’d done it earlier). This is enforceable law and it’s there to help you, so use it!
6. Has anyone else ever even heard of them? (AKA, use your network)
Not like, are they the Kardashians or anything. But ask around — has anyone you know worked for them before? Got a recommendation or a horror story? Check LinkedIn (sorry, gross, I know) and see if you have a connection there.
Keep your friends and colleagues in the loop — your fellow developers & freelancers on Twitter, mailing lists, IRC, Slacks, or at meetups are your colleagues too— anyway, keep them filled in on the details. The tech scene is relatively small and words about bad clients get around. People like to help if you just ask them.
7. Tune your bullshit filter
Okay, now I’m just ranting, this isn’t really a question. Sometimes people will try to give you a different idea of their workplace because they just really really need people. Get good at noticing changes of subject that don’t really give you an answer to your questions. Notice when people disagree about aspects of their environment, and think and ask about why their experiences might differ. This is the hardest part for me, so if anyone else has any tips I am all ears!
8. They’re at an interview too
It took me longer than I’d like to admit to add some of these questions to the list, and if it seems like I think you should be interviewing them as well as the other way around, that’s because I think that’s true. Any interview is very much a two-way process, and good developers are very hard to find, so they should be lucky to have you — which means you can afford to be picky. Happy hunting!
Nicky Thompson will soon be joining the FutureLearn’s product team as a Front-end Developer (you could join her at this amazing team too!). If you have any questions for her about freelancing or software development then feel free to add your comments to the piece. You can also follow her on twitter @knotnicky.
