CodeBork | Tales from the Codeface

The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.

Project maintained by Hosted on GitHub Pages — Theme by mattgraham

A little while back, I posted up some interview questions for employers. You know, to ask at that awkward moment when the interview is basically over and the interviewer asks you if you have any questions for them. I didn’t receive a great deal of feedback to the post at the time, but my friend Steve recently came across another blog post that provided a much more comprehensive list.

Warning: Do not simply ask the interviewers these 100 questions in the first interview! Your first priority in an interview process is to convince the interviewers to hire you by selling yourself. The important but secondary priority is to determine that the company is a good fit. It does not matter how good a fit the company is if they will not hire you … I would not recommend asking all of these questions directly of the interviewers, especially those from the human resources department, as they likely do not know what the specific working conditions are like and may sugar-coat the facts. I recommend instead talking directly to a few regular employees, preferably in a neutral setting outside of the office.

So, in short, don’t wander in with your four sides of A4 and reel them off one at a time! :-) In fact, you will be able to find some of your answers in other places: the majority of the “Organisation” questions Basil poses can be answered by reading the company’s annual report, for example. It’s always a good idea to read the annual report before going for an interview (it’s an invaluable source of all sorts of information), and, if you’re not sure about financial measures, get someone who is to help you out. The last thing you want to do is get a dream job at a fantastic company that is going to go out of business in 6 months’ time. Publicly-trading companies (PLC in the UK, Inc. in the US) are required by law to make their financial statements public; in this day and age, they will more than likely be posted up on the company’s website under “Investor Relations” or “Company Information” or similar. If you do struggle to get hold of a copy of the annual report (for example, if the company is small and privately held), ask at your first interview for a copy; it shows interest in the company beyond the narrow focus of your own role, and will likely impress the employer. Even with the annual report at your fingertips, you may want some clarification of some points. Be sure that you target these at the right person; the technical lead interviewing you is not going to be interested (or, more likely, even able) in answering these sorts of questions.

Many of the remainder of the questions fit better into the “talk to employees at the pub” category, and the 101st bonus question Basil lists will get you a long way towards a situation where you can ask these questions. Interestingly, Basil refers his readers to The Joel Test I mentioned in my previous blog post on this subject, and also Jeff Atwood’s excellent Programmers’ Bill of Rights. Both are well worth a read. However, I’d like to use the remainder of the post to pick out a few of Basil’s suggestions that I think are particularly important, and why.

What is your strategy for empowering employees? Employees that feel under-valued and under-developed are unproductive and unhappy. Empowerment is about giving employees the means (knowledge, political power, whatever) to do their job, and do it to the best of their ability. As an interviewee, you need to know that your employer will invest in your training, and will not micro-manage you or ignore you.
How do you minimise interruptions for developers? Developers, like many other professionals, "get into the zone". This is when they are most productive and produce their best work. It takes time and effort to get to that mental state, but once obtained it is easily broken. Telephone conversations, noisy open plan offices, and many other factors will interrupt a train of thought or break a developer's concentration, dropping him out of the zone, or preventing him ever reaching it. There's even some evidence to suggest that open-plan offices are bad for your health. Sadly, though, open-plan offices are the norm these days, so you will be incredibly lucky to find a company offering private offices, but beware companies that put sales guys in the same room as developers.
What opportunities will there be to work with new, interesting technologies? A developer's greatest asset is his knowledge; it's the main reason he is hired. Learning new technologies drives innovation within the company, and keeps developers' skills fresh and up-to-date. Companies should be careful not to lock developers into their existing role, however, as they will then be harder-pressed to adapt to changes that might occur at a later date. Role-specific knowledge is great whilst within that particular role, but pretty useless outside of it. Rocky Lhotka's article on Domain-Specific Languages makes a pretty compelling argument against DSLs on account of the lock-in effect they can have on the company, the product and the developers themselves, but the ideas apply to more general situations too.
Are high quality chairs provided? Comfortable and fully-adjustable chairs are an absolute must, as I've found out the hard (and painful!) way. High-quality chairs do not come in cheaply (check out the range of prices charged for the Herman Miller "Mirra" model that I have at work), but they are worth the investment. High-quality chairs last much longer than entry-level models and keep you more comfortable throughout the day. You will regret spending 30 hours a week in an uncomfortable chair, and it will have knock-on effects for your health. From the company's perspective, an uncomfortable developer is an unproductive developer, and they are more likely to take time off because of back/neck problems, suffer from RSIs, etc., whilst using a cheap chair.
Will I have the freedom to install the tools I want on my workstation? Again, this ties into developer productivity. Every developer has their own favourite Notepad replacement, their own preferred IDE (or Emacs), and they will be sufficiently practised with these tools to have achieved an excellent level of productivity. If you lock down your developers' workstations, or require them to use specific tools, then you are taking away some of their freedom. You are giving a left-handed person a right-handed pair of scissors; a carpenter a spanner. Sure, they can still do the job, but there are better options available. Money should be spent on buying the best tools available, too; the best tools will pay for themselves many times over in increased productivity.
Do projects have realistic schedules, resources, and scope that are actively managed and adjusted? No one likes a project that over-runs, suffers from requirements' creep, or is under-staffed. You want to work for an organisation where projects are efficiently managed. Take time to learn a little about project management methodologies so you can effectively evaluate the interviewing company.
What development methodologies do you use? Describe how they are put into practice. If you prefer the up-front style of the waterfall model, you might struggle with an Agile environment, and vice versa. Feel free to get into specifics, such as TDD or DDD, if there are areas of particular interest.
How much paid training do you provide to each employee per year? This relates to the question of empowerment earlier in the list. If a company does not provide much training for their developers, the skill sets of their employees will become out-dated and the company will find it harder to adapt to new trends and technologies. Equally, developers with out-dated skills will find it harder to get a new job when leaving, and so they might choose to move on sooner. A good company will invest in their developers' skills to retain the best minds and safe-guard the company's own future.
What open source software do you support? What form does this support take? This one interested me, as it's not one I've ever thought to ask before. Probably more companies than you might think contribute to open source software in some form; even Citrix does so now, following our acquisition of XenSource. This shows good community awareness, and, to an extent, good business smarts too, as most software thrives around a community these days. The company doesn't necessarily have to contribute code to an open-source project; it could be that a company has a particularly high presence in the project's community because they use it a great deal themselves. For example, a company using Ant a great deal may give something back to the Ant project by maintaining a good presence on the support lists, or donate a modest annual sum.
Who are you competing with locally for recruiting software developers? Who are you losing developers to? This is important, as it provides a basis for comparing the role for which you're interviewing, and might also give you ideas of where else to apply for a job!