Red flags I saw while doing technical interviews

> Role clarity is a huge one in my book.

While I could agree on larger tech companies, I certainly don't count this as a red flag for startups or smaller and/or younger tech departments within larger organizations.

A lot of times managers know they need more resources and/or skills but don't have a clear idea of exactly roles are divided - and maybe it's an organization with fluid or not defined roles in the first place.

I don't think that has to be a problem at all, on the contrary I thrive in such environments.

I've been at the same company for 3 years and I'm not sure I could give you a good answer to what, precisely, the role of me or my fellow engineers are. It's a pretty flat org. I'm happy to keep it that way.

Obviously there are many people that get frustrated or miserable without clear roles and responsibilities, but I think it's important that this is relative to the individual and not inherently a red flag.

Been thinking a lot about this - right now I run eng for a pretty broad product in healthcare, and there is overlap between eng and product.

In your case, it sounds like you have crappy product leadership. This is _way_ too common.

You need a cohesive product vision from the top down (VP/head of product), which they communicate to their team of PMs. The head of product needs to ensure that their team can make the correct product decisions. This means guidelines on where the product is going, what the company prioritizes, and how products inter-play/work together.

With an actual vision from the top down, these calls which your PM team bicker on should become easy.

An engineering analogy: the CTO/lead architect sets the standard for the direction of engineering, its services, etc. This is followed by everyone in the engineering org (hopefully) with alignment and without bickering. This SHOULD happen for product, too.

Really, I've noticed that at upper management this is literally your job: ensure that people make the right decision, whether they're your team, your peers, or upwards to the CEO.

You could probably reach out to your engineering leader and have them coach the head of product here. After all, that's the engineering leader's role - making sure their peers make the right decision and remove blocks from you, the engineer.

Regarding overlap, a good PM should amplify engineering. You might be a product focused engineer, but trust me: an engineering team cannot and should not be focused on writing user stories, performing research, and deciding the larger impact of features alongside their regular job of executing with code.

There is a reason that "FizzBuzz" is a meme! I love the expression, "Job candidates who can't seem to program their way out of a wet paper bag."

It's too true. A quick search found the source article that I read years ago here[0]. :)

0: http://wiki.c2.com/?FizzBuzzTest

Is it that bad not knowing the specifics of your day job?

Filling gaps can be interesting too, you get to see a lot of different things, and some companies actually try to put you on jobs you find interesting.

On the opposite side, some interviewers have a model job story to tell candidates, and it may actually be your job for a month, until they shut it down and have you join the ranks of turd polishers.

I'd say an even redder flag than not knowing what you will work on is getting what looks like the only interesting job in the company.

You're right to question it, but this is also why testing is so prevalent apart from the deluge of unqualified/barely qualified applicants. It's possible for a single person to spend an hour (perhaps over lunch) with prospective candidates and better evaluate them, with a corresponding better evaluation of the company by the candidate, without needing to do the multi-stage multi-test multi-people rigamarole big companies are addicted to. Similarly such people can usually detect resume BS better and whittle a list of 50 down to a shortlist of a few to spend that hour on each and come away with more than one good fit. But the skills needed to do that aren't widespread or taught or in many cases even acknowledged as existing. Hence tests, where when followed as a script can be given and scored by even the most disinterested programmer who'd rather be programming instead of doing their manager's job. Now you don't even need someone ok at resume BS detection to narrow the list, you can parallelize that 50 hours.

Of course the tests are proxies and often aren't even scored objectively. And most tests aren't very good at proxying anything general (hence companies' tendencies to have several). There's a lot of problems that remain, our industry doesn't take hiring seriously. But testing and trying to test as early as possible have come to dominate for not totally unreasonable reasons, and persist at the large companies despite the well-known negative trade-offs. It's a startup's/small company's advantage to not copy bigco's interview processes.