10 Amusing Red Flags During a Software Engineering Interview
You’re a software engineer, you’re at an interview, what telltale signs should you be looking for that may indicate a questionable employer?
1. No interview room has been booked in advance
Companies are in business and they survive (usually) by making money. Well, if they’re not ‘disruptive’ startups, quangos, or a department of the civil service, but hey I digress.
Making money is generally associated with having at least a modicum of organisation and an offshoot of this is being able to furnish the interview process with a room in which to hold meetings.
I’ve been there. Admitted to a building, met the interviewer in a busy corridor, been led on an impromptu tour of said building looking for a vacant meeting room. Booking failure mode engaged.
Whilst this failure could be laid at the ineptitude of the interviewer’s organisational skills, the difficulty of the booking process due to bad software or lousy user interface, the failure of the booking process software to sync with the proper calendars, or just someone in management ‘pulling rank’ and stealing the room it all adds up to an epic failure of organisation.
Booking a room is a basic requirement and if the company can’t do it I’d already be thinking what else they can’t do when I eventually get to take a seat somewhere in the building.
Caveat: Sure, natural disasters and accidents happen — burst pipes, heating or air conditioning failures, ‘double booking’ and suchlike but there are also other offices and if all of the conference rooms are busy someone could have volunteered the use of their office for a modicum of privacy during an interview. Surely.
In my own experience, lack of preparation like this speaks volumes about the way the company operates in other areas.
2. No refreshments are offered
It’s a nervous time and no matter how many interviews you’ve attended a dry mouth is something that can really throw a spanner in the works of presenting yourself at your best.
Whether you’re willing to risk an unknown company’s coffee* or go for the safer option of water (still, never fizzy, as burping in new company is seldom charisma building) it’s a basic requirement for a conversation with someone you just don’t know very well.
*A company offering instant coffee to anyone, let along a prospective employee, would cause me to instantly (slight pun intended) dismiss them as a potential employer. Unless it’s a garage. It seems to be the norm there.
Having some kind of beverage on the table** in front of you also acts as a neat distraction which allows you to collect your thoughts by either staring at it, caressing it, or just taking a sip every now and again because you need to lubricate your mouth and not get stuck on pronouncing your words.
**You do actually have some kind of table, right? If you’re interviewing on a beanbag and you’re not at the BBC or an advertising or fashion house then just leave immediately. You can bet they also hot desk, that is if you can find one.
I’ve actually seen interviewers deliberately avoid providing refreshments to put candidates under pressure and to see if they’d ask and how they’d do so. It’s semi-interrogation and frankly ridiculous in the modern age unless you’re recruiting for the special forces or psyops.
3. You discover it’s a panel interview
Oh the panel interview. This is a notorious and outdated method of interviewing primarily seen both in academia and in the civil service and so utterly unsuitable for software engineering technical interviews it actually physically hurts to even talk about it.
Throughout my varied ‘career’ in software engineering I‘ve been subjected to a (surprise) panel interview just once. Since I’d had the good fortune to not work with the civil service for some time this one was in the realms of academia and occurred during an application for a contract IT role at a major university. I thought I was going in for a chat with the head of department and perhaps would meet up with a lecturer or technician but lo and behold when I entered the interview room I had five fairly senior academic sitting behing a long desk facing a solitary chair. My chair.
I accepted this, once I’d got over the initial shock, as I’ve actually been a longtime fan of academia’s modus operandi. I blame watching A Very Peculiar Practice as a youngster and the subsequent realisation later on that that was how academia actually operated. It kind of gelled with my personality.
Anyhow, panel interviews do absolutely indicate an anachronistic and utterly inappropriate approach to interviewing for software engineering. If you’re not applying for an academic role or a (less fun but significantly more bureaucratic) civil service sentence then please do turn around and walk away. You can thank me later.
I actually for the job via the academic panel interview and it turned out to be a lot of fun. Though it’s generally hard to impress a panel as a software person as they’re usually a cross-section of higher ups who still think the telephone is a marvellous way of communicating although significantly less formal than the telegraph and generally lament the passing of waiter service in the senior common room (that’s refectory to the undergrads). Also, make sure you wear the right tie and skip the Simpsons socks if you decide to give it a shot.
4. The Interviewer hasn’t read your C.V.
I’m sure we’ve all been there. The interviewer arrives flustered, a wad of papers flapping about under their arm, and after haphazardly sitting down begins to read through your C.V. for the first time. Most likely they will be tracing their way through with a biro that still has its cap on.
This is usually followed by the interviewer tapping each point with their plastic pen whilst avoiding eye contact and questioning you about your work history, chronologically. They’ll grunt then smile to themselves when they recognise an employer or dated technology and sometimes throw in a tangential question completed unrelated to the job you’re there to interview for.
Lack of employer preparation is an understatement and this often goes hand in hand with the next point, the interviewer not being familiar with the role being offered.
If the interviewer didn’t prepare for the interview then either they don’t care or the company doesn’t care enough to send someone who does. I’d start to wonder at this point whether someone had read my C.V. before I was invited in for interview. Then I’d start looking around the room for the nearest escape route and wonder if I could slip out before they get to my secondary school years.
This red flag often comes hand in hand with the next one.
5. The Interviewer isn’t familiar with the role being offered
You’re sitting in the meeting room, hopefully, and have a flimsy plastic cup of lukewarm water in front of you, probably, and the dawning realisation comes upon you that the interviewer doesn’t know why they’re there.
I’d seen this situation a few times, primarily as a contractor, when a company is dying on its feet and is looking to save itself by completing a project quickly but lacks the necessary skills. Someone is sent to the interview room as they’re non-essential to the project to screen the contractors but hasn’t a clue what they’re being screened for or otherwise doesn’t understand the job specification that they’ve been given to interview for.
Now, this is an acceptable (well, bearable) practice in my book as a contractor — get in, get the job done, get paid, get out — but for a permanent position, again, it’s time to walk away.
How can a company seriously send someone to interview a candidate when they don’t understand what they’re interviewing for? I’ll just leave that with you. Unless you’re a contractor there to bring essential knowledge and experience there’s no reason to tolerate this unless you’re absolutely desperate for work and even then I’d think twice.
Look for the exits.
6. You’re asked to do a standard coding test
I could, and have, go on about this for a long time and have written a whole previous article on this very subject that stimulated an enormous amount of debate. Generally it’s accepted that past a certain stage of your ‘career’ being asked to do a coding test can be perceived as demeaning and trivialising of your qualifications and experience.
As I say in the related article, at length, standard coding tests are a terrible way to judge both people and their knowledge and any company that offers one should be avoided unless you’re willing to jump through hoops and tick the boxes by rote for some ultimate other goal you’re aiming for.
Another point to consider is the kind of coding test that you’re requested to complete. Sometimes this is requested during pre-screening, on your own unpaid time, other times it’s in real time in front of the interviewer during the interview itself.
Obviously the interviewer themselves would have to have some degree of technical ability and the task be suitably engaging to be worth your time. But, generally I’ve found this to not be the case. What tended to happen, before I point blank refused tests, is that the interviewer takes away your work and hands it off to someone else who reads through it and offers some kind of ‘grade’. Without meeting you, of course.
Your mileage may vary here of course, and in some cases when you’re just starting out it may be acceptable, but if you have standing or you’re a contractor just walk away — but do say why — as that’s how we start to rid the world of this demeaning practice.
I’m on a crusade about this, can you tell?
7. Evasiveness about why the role exists
The interview seems to be going well. You have a well constructed chair, a drink, and the sun isn’t shining directly into your eyes through a slatted blind behind the interviewer’s head. Technical questions go well, there’s no coding test just a general theoretical discussion on the merits of different approaches to problem solving and the pragmatism of development methodologies.
You start to smile inside, get the nice warm fuzzy feeling, then the interviewer asks if you have any specific questions about the role.
The sky suddenly turns ominously dark outside.
I’m always interested, as a software engineer not personally, why a role I’m interviewing for has become available — whether it’s new or become vacant.
Sometimes it’s a new one for a specific project and the present team lacks the technical ability so needs someone who has it or they need to expand the number of people to cater for a higher work load. Other times it’s because someone on the team has left the company and it’s in this case where I try to dig a little deeper if I can.
Remember you’re interviewing them as much as they’re interviewing you.
Often enough a well versed human interviewer will happily discuss why the role has become available but a red flag starts its long way way up the pole if they become evasive or flat out refuse to discuss it.
It’s not often you’re interviewing for top secret roles, though they do happen, and discussion of the technologies and sometimes the team are completely verboten. But, generally, if the interviewer avoids the reason then I tend to assume that it’s because the previous incumbent left on uncertain terms or that the role, if discussed, is unfillable — i.e. they can’t find someone to take it once they know why it’s free.
I’ve interviewed for roles with monolithic telecoms companies in the past who operate like this when they have huge legacy codebases and don’t want to let on that your job will primarily be maintenance, i.e. previous employees have lost the will to live and have literally drowned in unrepeatable error messages and the resultant unresolvable tickets.
Don’t get me wrong, some people have to do maintenance and some people even love to do maintenance, but an employer should not try to hide the fact of what the role actually entails. More often than not if you employ someone through subterfuge they’ll either just leave or become more and more unhappy that they’ll just stop doing their job and eventually have to be forced out some other way by the employer.
Always do try and find out why the role is available and if you can’t get a sensible straight answer or explanation then it might be time to move on.
8. Evasiveness about the technologies involved
An employer can advertise a role with a fun technology and get a lot of applicants, pick a well meaning, eager, and even optimistic individual, but once they’re behind their desk they then pull a sneaky bait and switch.
Oh the times I’ve seen this one happen. The technology you’re employed for seems to get further and further away the more you approach it. And it’s so easy to be flattered into altering your own goalposts isn’t it? This is a lesson you learn when you become a little jaded through experience. Like me. That’s why I’m here, writing this, to help you. Honest.
Be very, very wary about an interviewer when they become evasive about technologies. Perhaps they’re ‘evaluating’ the technology you’re interviewing for (and subsequently decide against it when you’ve signed on the dotted line and have a few weeks on the books) or they’re ‘looking into a rewrite’ (rewrites never happen, at least not coming from a management direction).
To take a role you need commitment — on your side for sure, but also on the side of the interviewer who should commit to the role being offered being what it actually says on the tin.
If they’re evasive on technology it’s most likely a lack of commitment.
Note: I do understand that when recruiting for a project that some technologies may need to be evaluated but you don’t generally employ new staff in order to do that. Well, not permanent staff anyway. Contractors or outside third parties should be the go-to people not permanent staff as they can be taken on and dropped on a whim. I loved contracting, still do.
Perhaps you’re Linux (that’s UNIX to us old people) but they want you to work with their proprietary editor that only functions with their proprietary Eclipse plugin. You know Vim does the job, but they insist. It’s company policy. It’s company policy that they never told you about or avoided mentioning when you asked about specifics of the technologies involved.
I remember a time when all HR functions, including bizarrely email, were only available through Lotus Domino at a particularly large multinational and it was a living nightmare similar to wading through corrosive hot treacle.
More time was spent struggling with the ‘all-in-one’ mail, room booking, time management, scheduling, ‘tool’ than was ever spent coding. Similarly I’ve seen whole teams of developers brought to their knees by the enforcement of Rational Rose and Clearcase.
Ask about technologies for design, development, and collaboration. Absolutely do not forget to ask about the edge cases!
9. No time for your questions
The ‘conveyer belt’ approach to interviewing gets the interviewee in, grilled, and out of the door as quickly as possible without giving them a chance to ask any questions. Also known as the ‘rubber stamp’ process.
Often this can indicate that there are a lot of candidates and/or that interviewing is such a regular occurrence that it has become more of a production line than an actually productive process.
Either staff turnover is exceptionally high, the company is undergoing somewhat rapid expansion, or everyone is leaving and it’s all hands bailing out the water as fast as they can to try to keep the company afloat.
Do some due diligence on this one — find out about employee numbers, how the market’s looking for the company, or even try to find someone in the know either at the company or in an agency for some insider information.
The only case I’d consider a company where there’s little time for questions would be as a contractor. Even a well funded startup should have time for questions, don’t let the money or share options blind you unless you’re willing to put up with whatever is thrown at you.
10. The stationery setup is abysmal
Finally, a pet peeve of mine. Something that can poison the waters with even the most well meaning company interview process.
You have the freshly ground, optimally brewed coffee. Your seat is ergonomically designed, with arm rests, and a firm yet rounded cushion for your posterior. There’s even a glass, a real glass no less, of cool refreshing still spring water on the table. The room is a soothing pastel colour, there’s not a ball pit in sight, the sacks don’t involve quinoa, and the employees aren’t even wearing employee branded clothing.
Then the interviewer asks you to run through a theoretical approach to a wonderfully engaging, yet esoteric, problem in software design. Bliss.
Then, they push a shabby loose leaf faintly yellow lined what can only vaguely be defined as a writing pad toward you along with a cheap blue plastic blue biro
You start to hear a rumbling sound in your ears and your vision mists over. That’s usually the point when I slowly rise from my seat, casually approach the window, and jump out to freedom. (Or, if I’m on an upper floor, head for the lift and drop my badge in at reception on the way out.)
I absolutely require smooth, quality, graph paper in a hardbound cover and at the very least a gel pel. Ideally real ink, never a sharpie or felt tip. I also quite like whiteboards (not the flimsy ones that ‘copy’ what’s written on them, proper hard ones that are at least magnetic with little circular coloured plastic things you can stick on)— one that’s been used and yet is clean but no underlying marking going back several centuries showing the original design of the steam engine is still visible.
Spend some money on decent stationery and office supplies, dammit!