Red Flags in Interviews
Introduction
This is a transcription of the discussion we had on an episode of FetaReport with many modifications. Although the original content is in Greek, we thought that it might be good to release our content
for an international audience. If you think that such content would be of interest to you even if spoken with funny accents, please reach out to us or leave a comment here so that we will react to your feedback and start recording
in English or blog more.
It is important to note that there is no perfect job. What constitutes a red flag for one, might be a green flag for another. Also, what one wants from a job depends on personality, lifestyle, stages in life (e.g.: single, married, family) or in one word: circumstance.
With that in mind a "we work all day long" signal might be a red flag for a family man but a "Wow, will learn a lot" for a beginner eager to acquire experience.
Hope this article will help make you feel a little bit more prepared for your next job hunt or at least entertain you.
People
One of us is a Software Engineer, one does Digital Marketing and the third member is in the Design industry.
Lots of Work Up Front
First red flag: when a company asks you in the early stages of the interview process to do lots of work just so you proceed through the application process.
In Digital Marketing there are companies that ask the interviewer to implement small tasks that might take 0.5 to 1 hour max.
While on the design industry we encountered briefs so vague that could easily take whole teams to implement them, similarly on the IT field we were asked to make whole applications from scratch.
Usually recruiters tend to be passive aggressive about it saying that "you look great and a good fit" for our company followed by the infamous "but", "... make this thing first, it will not take more than 10 hours," as if someone can manifest 10 hours out of thin air.
Discussing this with people in the design field, it has been brought up as a "scourge" of the industry. An insider has anonymously disclosed that with the main aim of companies doing this is not so much to check how a good fit the candidate is, but rather to check if this person is willing to give them 10 hours or a weekend of his life just to be interviewed by the company.
Another aim could be not so much to test the candidate but rather to block them from applying to other companies in parallel.
On the IT field there is some history. Many years ago there was a research done among a number of many university graduates in India. It was found that a large percentage of those graduates (around 40%)could not implement a small FizzBuzz algorithm in any programming language.
Reference, see this for a FizBuzz video: https://twitter.com/b0rk/status/998972366410735617
As an antidote to this, these tests were invented and many companies that offer "testing as a service", whose purpose was to filter out that 40% of the candidates (see also: Why Can't Programmers.. Program?).
An extension of this was for small tasks to see if people culturally fit within their future team. For example say that there is something vague in the specification, will the candidate ask for clarification? Do what they think is best and move on? Both? Or will they do nothing since they are not certain? All of the above are proper responses and would be unacceptable or not in different teams and cultures. Some companies also invite you to work on their premises for a day to validate you and see your approach. A degraded
version of this is that 10 hour "test".
Apart from the generic test, that remains the same for everybody every year, companies might also adjust their "creative tests" to problems they are actively facing. This is a good way for them to get cheap (i.e free) insights to problems they are currently dealing with. In the form of an "interview test". This has the added bonus that they will not have to pay for the solution or insights provided by the candidate. Typical win-lose scenario.
It is quite common for people in these industries, especially after some years, to have a portfolio or a repository of sorts that shows their work. However this level of past work is constantly ignored and candidates are still asked to perform time intensive tasks and tests for companies.
Update: Discovered that an alternative way to name this is called
"auditioning": https://hbr.org/2018/07/what-to-do-if-an-employer-asks-you-to-do-a-job-audition
Fast Paced Environment
Usually mentioned as "fast paced environment" within the job description. Some alternatives are that "we move very fast", or we "work hard, play hard" - though rarely or never accompanied from "we pay hard".
Recently some of us have encountered a statement read from the person on the other side of the phone in the lines of "... our people stay longer hours every day not because someone forces them but because they (really) want to...". We all stay longer hours in the office from time to time, to
finish tasks or for personal reasons, even personal development. The red flag here exists when the company mentions that (1) everyone (2) all the time, stays late. (3) Perpetually.
This can be an attempt to mask problematic project management or the absence of management altogether. One of us was told that some days he had to stay longer because some clients were located overseas in the US so had to make late evening phone calls with them. He ended up having his working hours
changed starting working from 08:00 in the morning instead of the contracted 09:00 on top of leaving later. That time was mostly spend waiting for other teams to deliver workloads because of bad or no coordination between teams. Nobody wanted to jump in and reform or restructure things.
When this was brought up, management claimed that "we informed you in the interview that sometimes you might have to stay late". So by using this "arbitrary clause", the system was abused and the need to "stay late" was used as a crutch to cover for other more obvious communication and management problems.
Leader of Team of One — Responsible for Everything
Some roles advertise for lead positions then early on on the first steps of the discussion, even in the initial call, it is made clear that the person will be "leading" a team of one consisting only of themselves.
"Leader" in this context means that one will be responsible for all the functions of a team.
In one case a company was advertising for a UX designer but also wanted the same person to do their advertisement campaign banners blending two functions as one position because... creative. The rationale was that the company was entering the space now, with what the UX person was supposed to do was not fully comprehended by them nor they had incorporated this function to their structure and workflows. Hence the UI/UX person would be responsible for doing the "old" thing while the company would be maturing.
Another way was to say that the company is currently expanding so that because candidate will be there early on, first, later on they will "build a team around them". This can be treated as way to bait for someone senior: "we want a person to be responsible for everything" is a hard pill to swallow, while be responsible for everything while in the background we are building a team around you sounds like a fair deal. In the meantime you will hold the title of "head of development" as titles come off cheap.
From past experiences, one of us got hired and found that he was the most senior on his team. Later on when the company grew, he got promoted to a manager and a team was structured around him. This was not discussed and of course not promised in the interview, it happened organically as the team and company expanded. The position was not advertised as managerial hence it was a nice career move, if the same person was being interviewed for a managerial position, he would like to meet the team or influence team's hiring
decisions.
Another member had a different experience: he got hired somewhere with the promise of having a team to be built around him. Tried his best as developer/architect but when the time came to expand he saw that a project got outsourced instead of having someone to report under him. When later on people came on board they reported directly to the CTO not him as they were supposedly serving a different function. At some point he was told that management had found a great developer, something rare in their minds, one they did not want to lose trading him for a manager with an unproven track record, at least within the specific company.
While the above argument might make sense for the company, id definitely did not for the person in question: the person had not taken other positions in other organisations that were more straightforward with him like advertising a position with strictly technical responsibilities. Then he worked hard not being compensated because at the end of the day there would be a managerial promotion.
Puzzle Mania
Puzzles relate to the IT field more than anything. In several interview scenarios where candidates are asked to solve one puzzle after another.
There are algorithmic puzzles such as shortest paths, double linked lists. Generally topics taught in Academia some times as part of how operating systems work or on programming language compilation and execution. The problem with these sort of puzzles is that they act greatly in favour to recent graduates. Sometimes subconsciously, sometimes with intent.
This intent was evident when a company was accused of age discrimination. Their response was "everyone can join, we have an impartial interview process". Although that was correct in theory and the job description was not limited to
a specific age range. The questions asked involved exercises and puzzles that were more relatable (i.e "fresh") to a graduate's mind. A clever, and subtle, way to separate candidates by age, since recent graduates will be more capable in solving these puzzles.
UK law does not allow you to select candidates based on gender, race, age, etc. This is one of the main reasons why sharing personal information such as sex, race or even a photo through our CV is frowned upon. With that in mind if you want to hire only young graduates for a specific reason, you can do so by asking mainly about puzzles. Of course that also applies to "older" graduates; after an MSc at the ripe age of 29 one of us was able to ace all these tests. But when that same person had some years away from academia, they struggled in answering those questions simply because the specifics of those algorithms had wean off their memory.
Update (post publish): This behaviour can be attributed to other ways apart from filtering out candidates, even if this is the end result. It can be attributed to a bad choice of interviewer. It can be that a developer has been asked to
aid with hiring, then knowing not much about the interview process just searches online and uses the first results that come up for "clever programming interviews questions". Another reason could be that big companies adopt these
puzzles with a "trend" and herd mentality; "if Google does it so should we".
Do That Now - One Hour
This is the mental offspring of "Puzzle Mania" with the "Work up Front", where you end up doing some online tests that you have to finish in one hour no matter what.
Problems with this approach have to do with how different people react to strict deadlines. One of us due to previous past experiences has knee-jerk reactions like asking the rationale of assigning an hour before starting the
task. Also how many day to day tasks in real life need to finish within exactly an hour? What happens if one gets finished in half?
In some of these on-line configurations tasks can be easily finished in about 20 to 30 minutes and the rest can be used for assurance, fixing an occasional issue or for buffer. In some other cases it is configured closer to one hour of coding non-stop favoring those who have solved a very similar exercise or puzzle in the past.
Some companies treat it as a stress test to validate how people function under tight constraints. There is always as before the possibility of following the herd: if everybody else does these tests we should also integrate them in our
interviewing process.
That is not to say that these tests are absolute however. Good companies gauze the quality of work you did within that hour. Your rationale, approach and problem solving is interesting to them even if you do not manage to solve
the problem. There are however companies that either have a very rigid or very unpolished hiring approach: for those companies, solving the problem is top priority, no matter the approach. If you miss the mark, even by a few minutes, you fail.
You Will Learn the Domain
It is suggested on and off that by working in a company, one will "learn the domain". For example while working for a bank one will learn the ins and outs of how financial markets operate, similarly how the betting industry works when
building betting software, etc.
This is generally a good idea and something, if anything, expected to happen. It becomes problematic when it is used as a cover for the absence of procedures, proper project management, or infrastructure from the company’s end.
One possible reason is if the company does not have anything substantial to offer in this area. As an example say that a company operates in the health sector so an employee is supposed to interact a lot with doctors. In this case
they will learn how the medical space works by interacting with practitioners on a daily basis. It can mean, and we have lots of prior experience of this, that there is no project management, people responsible for Quality Assurance,
other roles, so the individual does a mix of requirements gathering, customer support, customer service, and project management... on top of their typical duties.
A good way to summarise it is that in these places you do not get out of your comfort zone and expand your skills, you rather do things that are not related to your profession at all. Companies do not level you up from your current level as a professional, more like one step "out". All this has been
historically served as "get to know the domain".
Skills do not Matter
In this scenario evaluation of the candidate's skills, their current and future trajectory takes a back seat. The "Skills do not matter" approach has more to do with the candidate's personality, norms, attributes, hobbies and how they align with the ones of the team they are about to join.
In other words, checking if the interviewee is a good "lad/lassie", not a potentially good employee.
One of us got interviewed for a firm that was building an application for dog owners. The offices were crowded with doggos, puppet posters and other floof related paraphernalia. The interview was going well until the point where the director asked "do you like dogs?". The candidate, not really ever owning a dog, replied with "they are OK I guess". He could immediately see the scorn in he directors eyes, the interview was cut short with a promise of a "future followup" that never happened.
No Career Progression
Came across this while talking with companies from a hiring platform: There are companies that had a very good event like won a big contract or got to a next funding round. This is generally great news and congratulations on their teams for achieving this.
On this stage of their journey they want a number of people to help their offering take off or participate in getting them to their next stage such as contribute to help them scale up.
While talking to them there seemed that there was no clue on what would happen to a potential employee after this stage. How would a person once joining their ranks evolve after the "blood sweat and tears" period. For all one knows after
their offering becomes mature they might even downsize so the person who gave all that hard work would go away.
These positions are good for someone who starts their career and there will get exposed to many different experiences or for someone who wants this know-how in order to do their own company. But generally the offering is asymmetric since the the employer wants the employee to do the "extra" but
there is no compensation for it at the end.
Projects / Departments Build Around Rick
Another red flag is "projects build around Rick".
Rick is an alias based on "We fired our top talent. Best decision we ever made"
and the response: "You fired your top talent. I hope you’re happy".
It describes projects or sometimes whole departments structured around a single person, named Rick for the sake of argument.
One problem with these setups is that when Rick leaves for any reason, even when ill for a couple of days, everything kind of collapses at worst or becomes crippled and cannot function. When Rick is on holiday, or out of the office for
any reason, he still answers to emails or participates in chat rooms.
If Rick prefers a specific methodology then everybody has to use that methodology, the same applies to design approach, programming language, everything. Other employees have to listen to the Prima Donna.
One reason for this to happen is that at some point back in time Rick built something that somehow worked, or was the only one remaining in the same company from the members that did so. From that moment in time everything everything has been cast in stone with Rick being the guardian of that
tradition.
This shows up in interviews where questions that are usually open ended are tailored to see if you answer exactly what that person would like to hear.
Some other times it is brought up exactly as it is: "we use an in-house platform that our lead developer has built". Independent on if that person has done things right, wrong or anything, this is how thing should work and he should be in full control. They found that poor or many times not so poor
soul and all the projects are on his shoulders.
Another way to spot this is places by meeting people in different interview stages all of which have stayed in "Rick's" department for 1 or 2 years maximum. For a "magic" reason after that they tend to disappear. Reason is easy to guess: they either wanted to evolve or they did not work as Rick's satellites.
Be a Company's Rick
A variation of the Rick situation above is when a company wants to hire you so that you will become their Rick: just get all their current and future projects, work 48 hours per day and let everyone depend on you.
Sink or Swim
It refers to when you start working and you have to figure out everything by yourself. Some common red flag phrases you might see related to that are "commit production code on the first days", "impact on the first days", "hit the ground running". Those phrases act as an excuse for not having any
proper on-boarding process or for not explaining how the company infrastructure works.
We are not advocating hand-holding the new employee but rather start from simple stuff and move on to more serious stuff that a person cannot deduce on their own. Something technical like: "we use Jira to manage tickets", or when
to call out a client, when do you call out, does a specific person need to reach out first? Is it OK to interrupt people when they talk to ask questions in a meeting?
An example of this was a place without any on-boarding at all with management was complaining when things were going wrong on top. Once a client asked something in an email to which the there was an immediate response from the marketing person. Then that marketing person was was told from their manager that they should have asked them before reaching out. There was lots of guesswork on whom to ask, when to ask, when not to ask, what is OK, what is not OK; Questions not related with the specifics of the job or the profession but how to function within the specific organisation.
Facebook has a very good on-boarding process, where when a new employee starts, they are being guided by a person that has been in the company for a while so that everything company related can be explained appropriately. Then gradually that person acting as "training wheels" moves progressively more and more to the background as the new employee integrates with the organisation. In other places that the same thing happens when they assign something really
trivial like "change the background colour of that button". By doing a series of trivial tasks or some times janitorial tasks or even cleaning up the back log, one gets their head around the systems, learns how to set up a development environment, and so forth.
When asking in different places about why this happens the "official" answer was usually that there were not enough resources or in a more fake-polite English way that proper on-boarding is a "luxury". In reality it is more a "smell" of bad management: people that became managers just by waiting their turn as other more proper managers were leaving or cases where the only developer (the one who actually got to "build a team around them") got promoted as the company expanded, which is a good thing, but without any training or
learning on the new position. One of those functional idiots gave the semi-autistic response: "I did not have any on-boarding so neither should you", ignoring that different people have different needs or that he was there when there were very few people and minuscule infrastructure so things were very easy to guess while on-boarding for him happened but not formally.
What Would You Do?
We decided to do a follow up Podcast on the subject but do not know when.
Sent us your opinions, procedures, and generally "how you it", or stuff that you liked while being interviewed.
A listener came with his approach which we loosely translated:
One way that I prefer is to give them a small problem,
not a puzzle, and ask them to provide a solution. There might be an algorithm behind it or not. Based on experience and capability the candidate will reach an answer with or without having the specific knowledge taught recently nor fresh.
Top comments (0)