* If they are a small company who outsources any step of their interview process to another company. If you're only interviewing for a couple positions—people you will work with every single day—take the time to do it yourself.
* If they are a startup that says they are looking for people who are interested in solving exciting problems. For some people, this is going to be an enticement, but based on my experience, what I hear is "we're going to work you like a dog and pay you in equity, and at the end neither your work nor your equity will matter because we're definitely going to go out of business". I recognize this is a bias, but it's happened to me a couple times, and I'm in my 40s now and just not having it anymore. Plus, the problems are never that exciting, they're usually "how to sell a SaaS product that is basically a CRUD app, in a crowded marketplace with lots of competitors".
* If the interview is composed of like 10 rounds of 30 minute interviews, each with different groups in the company, that to me is an indicator that Conway's Law is at the helm of that organization: lots of groups that want input into everything, nobody empowered to make a decision on their own. Plus, it's just not a very good format. Give me a smaller number of hour long sessions where we can actually get into it, rather than racing through pro forma questions.
This and other grandiose language is an immediate red flag. I fully expect the people writing these to be the equivalent of used car salesmen.
I guess in this day and age, I need to add "using a chatbot as a stand-in for a real person".
I'm torn on this. Having dedicated recruiting staff isn't cheap, and I'm not sure a small company could justify this unless they're constantly hiring. But I've gotten soooo much low-effort, generic recruiting spam from third-party recruiters that, were I running a company, I'd only resort to those sorts of recruiters if I had no choice.
I'm specifically thinking of the time I was asked to do a karat technical screen when applying for a position with a small company, and it was a big red flag for me. This is a service that does a remote, screen-share-based technical screening. My view is, you're only going to get a worse outcome with this approach compared to doing the screening yourself: either you're spending a lot of time going through the recording afterward, in which case you might as well have just done it yourself in the first place, or else you are just looking at the feedback by the third party company and deciding based on what they tell you. Since the third-party screener doesn't know you business, product, culture, or tech stack, that seems like a terrible idea.
People will often acknowledge that hiring (or not hiring) is the riskiest thing a company can do, and yet take stupid shortcuts to save a little time on it. That's the mentality of companies I want to avoid.
* No remote or hybrid
* Unlimited PTO can potentially be a red flag depending on other aspects
* Dinners at the office
* Business model that is not generating any revenue
* Needing 5 references for a junior position and they had to be people I worked with(my team was 3 devs). So, I listed other people I knew. One of them a VP of a tech company, who worked for large tech companies. They called him and grilled him. He told me he did his best but not to take the job and maybe just come work for him.
* Another time, I was told my code was wrong and wouldn't compile during the interview, I said "I am certain it will", but the dev said unless I change the answer is wrong. I changed it, he was wrong. I got the offer, and did not take the job.
The key on this one is to then ask your interviewers how much PTO they usually take per year. If the answers are below what would make you happy, then that's a problem.
At my last company with unlimited PTO, at my height I was taking ~8 weeks per year. I was highly productive and my boss knew that even losing me for two months out of the year, I was getting much more useful work done than most people who were taking 2-3 weeks. (At least I hope that was his thought process, and not just that he wasn't paying attention.)
> Business model that is not generating any revenue
Do you mean profit? Not generating any revenue either means they're very young and don't have a product yet (fair to not want to work on something like that, but every company has to go through that phase), or that they have a product but are somehow not charging for it at all, and don't have any other monetization strategies like ads (gross) or selling user data (even grosser).
But if you limit yourself to only companies that are turning a profit, you're essentially saying that you'll mostly only work for older, established companies, and for the most part nothing that's VC-backed. (Which, again: fair, but also pretty limiting.)
I also disagree with asking interviewers how much vacation they take in an unlimited PTO situation. Instead just ask, “What’s the limit?” Any company that offers an unlimited PTO policy should be able to answer this easily. The only objectively incorrect answer is “There is no limit.”
- The interviewer is wearing a suit.
- The interviewer asks "you've worked with [person who now works at our company] before, what do you think about them?". Bonus points if they insist after I give a diplomatic answer.
- "Why are you using microservices?" "Because everyone is doing it"
- Not following up. For weeks.
- "Can you send us your high school diploma?"
- Take home assignment with a time limit.
- No feedback on take home assignment except "we didn't like your approach".
- Developers use separate laptops for coding and for internet access.
- There are three architects on a single project.
What's your concern there? (Honest question!) I feel terrible about asking for home assignments but I feel like it's good for people like myself who are terrible about coding live. (I usually have a choice of live or homework.) I put a "limit" as a guideline about what kind of quality to expect, usually with language about things not to worry about. I don't expect/want folks to burn a bunch of time on things.
But a hard limit (you will get the assignment at X o'clock and you will have to turn it in within 3 hours) is just bonkers. It's totally unnecessary and artificial time pressure. Maybe I'm having a bad day and I make a silly mistake that takes time to fix - or the assignment is complicated and it takes me half an hour to even understand it and decide on an approach. Or I could implement the assignment in a maintainable way, but the time pressure requires me to do it in the most hacky way possible. Basically, I don't do my best work under time pressure, so I have no idea why you would impose it on me. In my professional experience, there's very rarely ever been any time pressure like that, so it's not like it measures something important.
That said, as I wrote elsewhere, if you can't pull a reasonable version of a work product out of a folder, I may be asking you to create one. I'm not necessarily talking code but I absolutely am looking for some proof that you can do the work if it's not already in the wild.
If not, why?
How would you feel if they insisted on you doing home assignments?
There is nothing wrong with wearing a suit, and it may be common in some workplaces/cultures, but in others it can be corollary to a work culture you are not compatible with.
--- "We need you to take a typing test." No thanks!
Came here to say this, specifically.
> - "Can you send us your high school diploma?"
Related: asks questions about that McDonald's job you had in high school, even though you have a master's degree and years of experience in the actual posted job requirements.
> - There are three architects on a single project.
Related: there are more than three layers of management between you and the Big Boss. Two is better. One is best. Too many layers means that it's probably going to take months to get approval for anything, meanwhile management is giving you the stink-eye for "not producing".
* They don't leave time for you to interview them.
* They're stuck on looking for particular, specific answers to their questions, even if other answers are valid and workable.
* The questions/problems given are one-sided and don't invite discussion. I really enjoy interviews where the interviewer will kick off a design or architecture question, and then instead of just sitting there, waiting for me to respond, taking notes and moving on, they engage with me on the problem and we discuss it mutually, like peers, with a lot of back and forth. This might not be a strong "nope" signal (some people just aren't very good at interviewing, and often that doesn't reflect all that poorly on the company), but it's definitely concerning.
* Being inflexible on compensation mix. If I think the salary is too low, I might ask for more equity. If they can't budge on the financial part of compensation, and have fixed/accrued PTO rather than unlimited, I might accept starting out with more vacation days instead. Answers like "sorry, this is the standard that everyone gets and it can't be changed" are big red flags.
* If we get to the offer stage and they want me to sign things that I'm uncomfortable signing, and their response is "oh, it's just standard boilerplate, we'd never enforce something like that". Well, I'm not comfortable with selective enforcement, either. "Never" really means "as long as we don't end up having an axe to grind with you later on".
An interviewer looked at me with this vicious, incredulous look when I described my side project in ~2019, which was a weather network built on the sensors inside phones. Guy said, “a weather app, really?! You think that’s a good use of your time in 2019? What makes you think a weather app is useful to make today?”
MFer, it was a good idea in 2011 and it’s a good idea today and it’ll be a good idea in 10 years.
And it wasn’t just a weather app omg! But he didn’t care, just kept pressing me for like 5 mins why I would ever think making a weather network service was useful. No amount of explaining the complexity or novel recently-developed techniques that made it possible would convince him I wasn’t wasting my time.
And ignoring that, even if the project was just a toy that isn't particularly useful, that's not really the point. Developing and building a project/product from the ground up is useful experience, whatever it is. Demonstrating a valuable skill should never be a prompt for scorn.
A heat map heat map, so to speak.
Forest fires? Outdoor events on hot days? This is a good idea.
And yes, I am a marketing guy.
Relying on these kind of signals as a main input is a sign that company didn't think through their hiring process and rather just cargo-culting.
But all that are still secondary concerns: good people can make bad process work, bad people tend to ruin the best of processes.
So for me the only important "flags" are specific people I contact — their attitudes, levels of professionalism, questions they ask, answers they give, their decision process etc.
On all steps of the interview process.
Some people I've worked with in the past scoff at this idea. When I ask them how they would prefer I evaluate technical ability they seem to all meander around the question basically saying you know a good hire when you see one.
It's tough to hire good people. I've been in the hiring process for Stanford graduates who could barely code in their take-home. I've also hired candidates who freshly changed their careers later in life and wowed us with their take-home. The 4 hour take-home for us has been wildly helpful in identifying the best hires, but I do get it can feel like a burden to some.
I just don't think I could really trust the outcome of leetcode. To me, I feel like anyone can grind leetcode for a couple months and ace a test on it. Does that mean they can create anything of value? Not really.
I've been involved in hiring developers, and I get it, you want to make sure. But just because something can be measured that doesn't mean that it's a good idea.
I like to suggest a time limited evaluation period instead.
That said, when I was a tech industry analyst, a writing sample--maybe a presentation--on a topic (probably of your choice) wasn't really a negotiable requirement and if you couldn't just pull one out of a folder that you could share, you were probably going to have to spend a bunch of time creating.
But also some of these examples could be from companies who understand the bidirectional dynamic. E.g. if you consider wearing a suit to be a bad sign the company might just as well be glad you don't want to work at a place like that. Win-win!
My contribution to the argument: people who use vapid business buzzwords/ like "win-win" except in the rare cases where it really is appropriate.
To be fair, I think that's a more recent phenomenon, at least when it comes to hiring low- to mid-career rank-and-file (in the past I think this was a consideration mainly only when trying to hire executives or people with specialized talents). And even then, that only works in a job market that is relatively at equilibrium, or one where applicants are in high demand. Beggars can't be choosers, as the saying goes.
2. Interviewer asking template questions and doesn't show any interest - if interviewer asking those basic questions and don't understand even what the job means, it's a sign that they don't even bother, they are just there to filter you
3. Interviewer pushing for the interview ASAP - it's very likely the position is needed as soon as possible, sometimes this could be something really serious and they are hiring someone to put out the fire, sometimes it's already a crisis and they expect someone to save the day
Things that I think indicate a poor fit for me include places where it's expected that people work more than 40 hours per week (I have no problem doing that in unusual circumstances, but if it's part of routine practice, that's a problem); where it's expected that you'll take part in extra-curricular activities; where they take agile methodologies too seriously; where there's too much social stratification in the workplace; and such.
Concrete red flags include using leetcode tests, using personality tests, absurd interviewing hoops (too many interview rounds, too many days to complete the interviewing process, etc.).
Not being interviewed by (or at least meeting) the members of the team I'd be working with is a bad sign, as is the interviewer not knowing the position I'm being considered for. The interviewer not answering my questions (or being vague or evasive in their answer).
I pay attention to the other devs I see. If most of them look unhappy or stressed, that's an enormous red flag. If in-person, most of the desks in use being pretty bare (little in the way of knick-knacks, personal photos, funny or interesting things hung on the cube wall, etc.) is bad. A lack of enthusiasm about what the devs are working on is bad.
Immediate showstoppers are having an open office plan or hot-desking.
Having too fancy of an office is a bad sign, but more of a yellow flag than red.
I'm sure that I've omitted a bunch of things here. I don't have a literal list in my mind. What I tend to do complete the interview process and then put it out of my mind until the next day. Then I go through my notes and examine to totality of what I observed, both things that pleased me and things that didn't.
Yes. Not just because it's an unpleasant environment (though it is), but it's a sign of major management cluelessness. "Wait: you're hiring me to think, and putting me in an environment that makes it harder for me to think? Um...okay."
The other side of the coin is that there needs to be somewhere to hang out when you do* want company. It doesn't have to be one of these places where every floor has its own executive chef. A comfortable break room with a selection of hot and cold beverages is fine. Snacks aren't necessary if there are food options nearby.
Engineering leadership doesn't understand (or care about) the business side.
Trying to shoehorn you into a role obviously you're overqualified for.
A focus more on time spent and dedication rather than achievements and outcomes.
No clear business model. Maybe it isn't an issue today, but for 99% of businesses it will be an issue soon.
A pattern of getting interns or juniors to do an initial chunk of work, and then getting seniors to clean up after them, rather than letting seniors lay a foundation and the juniors/interns filling in the gaps.
Specific red flag signals:
1. Dominated by Windows
2. Too many people in formals
3. Nobody wears badges (and other indicators of a lax security policy)
4. Old/worn out office furniture
5. Low resolution displays
6. Old laptops
7. No evidence of people collaborating or chatting at a microkitchen etc.
Depending on the size and age of the company, most of those hint towards a product-focused organization that often cultures careful, reliable engineers. It might not be fun or flashy, but there's good odds that a place like that knowns how to build their product and does a consistent job of it. They're often a great place for senior engineers to settle down and focus on low-drama productivity and for junior engineers to witness durable best practices in action.
Salesmen have Mac Pros or fully decked-out gaming rigs, programmers are still on Pentiums.
But seriously, we'd fail 1, 3 (we've never had anything like badges to wear), 4 (some of it is old, not too much us worn out though - chairs get replaced, desks are pushing 25 or more now), 5 (every one, including receptionist has multiple monitors but they're standard 300dpi), 6 (depends what you mean by old), probably 7 as well as most folk are remote now.
I guess we're not for you.
On the up side we dress very informally.
I wasn't offered the job, but I regret nothing.
I've done plenty of code tests in the past, these days it would take A LOT to motivate me.
Usually I just say thanks, but no thanks if they insist on testing me.
* Live coding during an interview sucks. I'm not convinced interviewers actually learn all that much useful during those, and I know a lot of people who perform well on the job but choke up during interviews when there's a live coding component.
* It's not like there isn't precedent for this sort of thing outside tech. For example, marketing/sales positions will often require the interviewee to prep a mock presentation specifically for the interview. (That is, not something generic they can use for multiple interviews.)
I get that people have commitments outside of work, and that the ideal situation is that you're interviewing for a job while you already have one (so interviewing work is going to be on top of all your existing responsibilities). But at the same time, take-home assignments in tech are becoming more common, and refusing to do them is going to limit your options. And I don't think the usual "well I probably wouldn't enjoy working at a company that does $THING during their interviews" really applies here.
2. I once had a technical interview where I was given a Jupyter notebook that set up a problem and then asked me several questions about it. The interviewer was on the other side of the desk watching me on a separate monitor. The interview itself was 1 hour long but he wouldn't stop talking for more than a minute or so. I didn't have time to read and understand the problem, nevermind design and execute a solution. Instead, he kept asking me questions, breaking my concentration... just a total nightmare.
3. Keeping me locked in a room all day. I've interviewed at several places over the years where I'd go, sit in a meeting room, and have a day's worth of interviews. Sure, I got a brief tour of the office, but even my lunch I'd eat in that meeting room. If I can't talk with employees in their natural habitat then how am I supposed to get a real feel for the office culture?
4. Interviewers who don't seem to know why they're interviewing you. I've had this happen many times. They don't know what the position is for, they never work with the person in that position, why bother?
5. Your potential boss can't give you a reasonable description of the work you'll do. Huge red flag.
6. Too many detailed questions about work I do at my current job that I obviously cannot get in to. If they can't respect my inability to tell them company secrets then there's a problem.
When one or more people on the interview panel behaves extremely unprofessionally. ie, ridicules the interviewee, or makes inappropriately offensive comments.
When the interviewer decides to give an interviewee they particularly like a tour of the premise and introduce them to other staff before they've even offered the person a job.
When there are heaps of relatives, or best/close friends within the management structure of the company.
This was for an open ended coding test. I just wanted to know if they wanted to see if I could work fast, or produce a better structured solution.
I should have left right then. The interview did not get any better. At the end they asked repeatedly how I would deal with problem employees. I had just about figured they were problem employers by then.
My current role has a somewhat misleading title, but to offset that I make sure I really highlight my experience and the projects I've worked on. If an interviewer starts asking me about my title and why I'm applying for something more 'generic' I immediately know they didn't read my resume or pay attention and I'm out.
Years ago I walked out of an all day interview, maybe 2 hours in, because one of the engineers was on his phone the entire time, seemingly just scrolling and not paying attention.
These are all signs of an immature data science function- which predicts working on ill posed problems and a problematic business justification. If the people already there are mediocre it’s not a great place to join. A strong sign of that is if the interviewers don’t know enough to construct thoughtful questions about real, non trivial, issues from their work. There are too many people in data science who, sadly, are at this level.
- how many hours a week does a typical dev work?
- what source control do you use
- what ticket system do you use
- how long does a typical, at-desk incremental dev build take?
- do you have automated builds (CICD, Jenkins, pipelines, nightly build system, etc)?
- not offering full-remote for all jobs actually doable from remote;
- trying to start selling itself as a super-duper-enterprise naming vague roles with unclear responsibility and so on;
- choosing external recruiters who have no clue about real opened position so they just run HR games and absurd questions;
- talking about proprietary software they use, requirements like "you will use this IDE", finding normal using a laptop for desk-fixed works;
- not possessing anything themselves living on someone else iron and even worse develop on someone else services.
Or will interviewers actually be sending me homework for an interview where I have to code something when the job is a SOC analyst or incident response?
I once got a whiteboarding problem and proposed a solution, and the interviewer gave me a flat out "that's not the one I had in mind". I'd already asked clarifying questions and thought my proposal was reasonable in light of the constraints as I understood them. After a few minutes of trying to play mind reader, I asked, "Is there some constraint or requirement I'm missing?" and they said no. I retrospect, I should have walked out on that one, too. I still have no idea what they wanted from me. Communication goes both ways.
Did a round of interviews for staff engineer at Catawiki that felt more like trying to guess the right words than actual problem solving.
But I get it. People get dragged into the process, usually without compensation. And it's much easier and safer to reject than to accept.
The tragedy is that everyone knows that the approach isn't working, I haven't met a single person who thinks SWE hiring is working; but we still seem unable do fix it.
Oh jeez. The impatient, combative side of me would want to respond, "so you're not open to other people's ideas, or open to the possibility that your approaches may not be the only good possibilities?"
A more diplomatic response might be, "can you tell me what you think about my approach is unworkable or at least suboptimal?" I think your question about a possible missing constraint/requirement was a good one. Actually, I think after asking that question and getting no reasonable responses, my original combative response seems a bit more appropriate...
Unwillingness to compromise.
Unwillingness to evolve.
Lack of empathy.
Lack of trust.
Lack of flexibility.
A fetish for telling people what to do.
Another time went for a code screen that said we could use any language on our own machine. When I go there the hiring manager handed me a Mac and told me I'd be using Angular to code a given problem. That's great. I had no experience with Macs, no experience with WebStorm, no experience with Angular. What a waste of time. I asked why he even brought me in if I didn't have any of this listed on my resume and the recruiter told me it'd my choice of machine and language? His response was that maybe I had the experience but just didn't list it on my resume. Fuck you too.
Again, not sure if that’s what was happening in your case, and giving someone a different OS would only hamper them if they were unfamiliar with the environment. Personally I like the challenge of learning a new framework, so long as that’s the intention of the interviewer.
- Any job ad for a FOO Dev, where FOO is a language. They're hiring code monkeys.
- A panel of interviewers suggests the company doesn't know how to interview.
- "Gotcha" trivia questions.
- Giving me a take-home assignment that takes much longer than their estimated time to complete . . . then asking me how long it took.
- Telling me what IDE to use (even if it's one I would prefer).
- Interviewer is another dev and is unwilling to tell me what they wish were different.
- Whiteboard coding where interviewer says nothing. Maybe they stare at me. Maybe they do work. Either way . . . no.
- Any question where the goal is guessing "the correct way to answer."
- Hiring managers who clearly want to hand off responsibilities instead of just delegate. Seems more common in small startups.
- Interviewers are late to call or join the video conference. Especially if they're at least 5 minutes late.
- Have you ever had to work on the weekend or well beyond 5pm outside of your own personal interest/initiative?
- Are we required to be on-call
If there's any hint of "nah, we don't really write tests because we just need to ship stuff, y'know"
I realize that probably doesn't describe a lot of people in which case it's probably the right job for them.
