Finally something I can answer! I've been doing tech consulting for over six years now.
- Straight up ask them if they're an MSP, lol. MSP isn't a bad business at all; I highly recommend it for juniors needing an in or people who want a lot of exposure to a lot of companies simultaneously. But you don't want MSP work.
- Avoid avoid AVOID WITCH companies (Wipro, Infosys, Tata/TCS, Cognizant, HCL). While they have _some_ A-team strategic work, the lion's share of their business is butts in seats labor arbitrage.
- Also avoid WITCH-adjacent companies (Teksystems et al). Same reason.
- Do a LinkedIn deep dive. If a majority of the company's employees work in an offshore location, they are more than likely butts in seats. This isn't always the case, but it's generally safe to assume so. If you're really interested in what they've got going on, bring it up in the interview and turn your bullshit meter to 11.
- This gets a little tricky for big tech shops, though (Red Hat, IBM, Accenture). They have a lot of butts-in-seats stuff, but they also have a lot of very interesting, very high-impact projects. There are ways to monitor what you're being considered for during the interview process; see below.
- Ask about some engagements they've done (client names don't matter), generally ones they are proud of. Ask about how those projects were structured, the number of people involved, and the objectives. Huge implementation projects usually have a high BIS factor, but some consulting companies charge through the roof for onshore consulting with an emphasis on high-quality software craftsmanship. This usually comes out in the interview; the interviewer mentioning xDD, hard 40 hour limits, and first principles is a good sign.
- Ask them "in your opinion, what's the ratio of staff augmentation to strategic work at this firm?" BIS work is called "staff augmentation" or "staff aug." Not all staff aug is BIS (some better firms take staff aug since it's much easier to sell than strategy but the consultants assigned to those still have autonomy, i.e. they can roll of when they've had enough/they can contest decisions with support of their engagement team/etc), but a high ratio of staff aug to strategy work smells like high BIS.
- The technical interview should be focused on your thought process and experience. "Tell me how you designed this system/explain this decision/if I changed x, what would happen" are some questions that should come up. If they are asking you very-specific trivia (what command would you run to do x/what is the name of y component that does z), then expect a high BIS factor.