Red flags I saw while doing technical interviews
blog.interviewing.io
blog.interviewing.io
From the secret FAANG that likes to pretend what they are doing is defense contractor level top secret, and even after your hired you might not know what your actually working on, to the big companies where its clear the hiring manager only has a vague idea what to do with someone because they are simply building an empire.
At least some of them are more upfront and say stupid things like "you get to define your role". Which is fine, if it comes with a grand vision, or your selling them on one, but frequently the grand vision is little more than "evolve our huge product, and justify it". Which is frequently just make work, and you won't be provided resources to actually implement a vision. And you can see this stuff in the public releases of products. Its the split personality of the windows control panel, where someone decided the current one wasn't good for a touch environment, but only had the manpower/political will to fix like the 5 most common things people want to change. So the results are garbage, and are the functional equivalent of 1/2 a wing glued to a car because someone wants an airplane but they only had a car.
To pile on to the Windows control panel for a minute: If you open the start menu and search updates, you bring up the settings menu for updates. Likewise for network settings or any other section of the control panel successor.
But if you open network settings from the start menu while you already have updates open, the updates window is replaced by the network settings.
Maybe they are working towards renaming the OS "Window".
What truly blows my mind is when the same settings are scattered among four different windows. See: Anything to do with sound.
In the old days billg / Balmer would have shouted at people until this was fixed
e.g.:
win+r:
desk.cpl -> monitor resolution/refresh rate settings
main.cpl -> mouse/keyboard settings
mmsys.cpl -> audio device settings
ms-settings: -> new Settings page (the : is required)
They don't understand why they are talking to you, "but maybe you can, I don't know, maybe do something of value here, but we don't know what that is. So here's a bunch of money. FIX US".
It's usually a sign of lack of vision by leadership in the company, so they are grasping at straws.
If you want to kill your morale, look for roles like this. They are great.
I know they will be mad the day we deploy this to production and everything fails, but I honestly dont know what else to mention.
(In my interview I said I had minor experience deploying to AWS, but in this company they are using Azure)
- voice of experience -
You get used to it...
Embrace the devops engineering for now - at least until you change jobs, if that's what it comes down to.
See it as a great learning opportunity.
Basically if you’re in a “Shut up and hire me!” mode and will self-manage and come up with what others also need to do. I find it tiring, but some people thrive in these roles.
That said; I've tended to look for small companies, or companies that are in startup mode, where roles do not seem very rigid, and boundaries between teams are not so impenetrable.
I tend to be miserable where roles are rigid, or the culture does not encourage cross-fertilization between teams.
Another difference is that design is top-down at Apple. Any UI redesign was driven by Johnny's team which was responsible for a holistic and consistent across-the-board implementation. I don't believe you were allowed to deviate from the design language. This one I have less visibility into as I worked on technology pieces rather than things that had a user-facing component.
So you have non-designers enforcing their personal "vision" without cross-team collaboration or user research.
Project managers basically do something that the devs, especially dev manager, can handle themselves. It seems like a leftover process for when software contracting was more common. There’s no reason a developer can’t just manage the Kanban board and write a quick report.
Product managers can be really good but in a lot of cases they just devolve into stakeholder management with poor/no vision. Because they talk to upper management a lot they can get a lot of credit for things they didn’t have a lot to do with, because they’re the visible face for it. This can sometimes lead to the Product org getting too big because they get promoted up to Director and now need 10-100 reports for something that only needs like 3 Product managers max. Then you’re in a really bad spot because you’re going to be bothered by PMs with small scope a lot about stupid shit
I'm glad I can delegate them the reasoning about which task is more urgent, and them acting as buffer to clients frees me from a lot of time trying to understand what they want, how they want it and all the back and forth about how much they want to pay for it.
good project managers, that aren't just bossing internal people around but working with the team at different part of the projects like communication and operations, are rare, but are a joy to work with.
The role is not as useful in tech companies where developers are working permanently. It's actually hurting collaboration across teams if you start budgeting projects and people tightly.
The Devs who are permanent employees and maintain a set codebase/application/etc do not fall into that. They know what to do, they have a defined Change Management/SDLC abd they are challenged into finding the technical solutio. The project management includes tracking the requirements, sequencing events, getting resources/contractors, etc.. A dev should be spending '8h' per day coding, not figuring out budgets and interviewing contractors. Of course different companies have different approaches, but ballpark and from experience I think my above writings are pretty valid.
Then I actually ended up in the position where I took on the responsibilities of a Project Manager in the course of building a department. I see it much differently now having worn both those hats as a generalist. You're tracking two different sides of the same body of work, and there is solid value that a good project manager provides in terms of producing a meaningful skeletal specification on which more in depth technical analysis and work can be done.
In addition, not all devs are full on gung ho let me throw something out there that I know will be mostly wrong until the details get filled in by everyone else. As a PM, you're as much the Rock in a pot of Rock Soup as you are the guy in meetings all the time. I've had to eat a lot of humble pie since getting saddled with building a department. The challenge is as much making sure things are in the right place at the right time, defining what the right time is, and making sure to unblock people as they run into obstacles.
It's a completely different type of work from straight up technical work, and is fundamentally destructive to maintaining the fine grained technical context you need to accurately implement something. You don't want to have to do it all at the same time.
Especially this is key: > The challenge is as much making sure things are in the right place at the right time, defining what the right time is, and making sure to unblock people as they run into obstacles
> It's a completely different type of work from straight up technical work, and is fundamentally destructive to maintaining the fine grained technical context you need to accurately implement something.
Exactly! Thank you for putting this so succinctly.
Just being aware of what needs to be done and in what order is critical. For that you need a bird's eye view of all relevant pieces, which is almost impossible to do when you are in the weeds.
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.
To expand on this, there has been one defining difference in good companies and bad companies I've worked for.
In good companies, everyone has expertise. Your PM can talk about details. Your director can talk about details. Your VP can talk about details. They do this because it's culturally expected that they know this. So they spend enough time to familiarize themselves and do normal paper-pushing responsibilities.
In bad companies, that's just... not there. If you ask anyone of those roles about details, they don't know and can't speak intelligently.
Consequently, in the former, you get much smarter decisions from all players. In the latter, you get ignorant decisions because there's less shared knowledge.
The strangest thing is that it seems more cultural than training / education. Either the company has this expectation of its people, or it doesn't. If it doesn't, no amount of degree will paper over that. If it does, it doesn't matter if your people are sharp but lack degrees.
There's a famous story from Microsoft back-in-Gates-days, whereby Gates was notorious for his detailed questions in meetings: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
Apple definitely has PMs but they work differently than they do at most other companies.
There really wasn't one huge Bell Labs, there were literally hundreds of hundred person teams run as if they were little companies, but with a huge bureaucracy providing funding, guidance, and all sharing a knowledge pool.
If you changed teams, you could find a completely different team culture using completely different tools. And like biology, some teams thrived, and some failed.
https://en.wikipedia.org/wiki/Multi-divisional_form
Usually contrasted with unitary form (U-form).
I have worked with some amazing project managers, but almost all of them were more hybrid-somethings than purely business-degree folks. Usually designer-PMs or SWE/DS-PMs who drive the vision for the product at large. They make sure everyone in the loop buys into the same idea, is on the same page and stays in sync.
However, to do it effectively, the PM must have deep insights into the product. even better if the make-or-break aspect of the product is their specialty. A PM who facilitates communication without insights of their own is being treated like an expensive secretary by the company, and IMO, hurts the development of both the product and the individual.
I maintain that an amazing PM has scope to make a far larger impact than an amazing SWE. On the other hand, an average PM actively slows down progress, when an average SWE meets expectations and still gets their work done.
The best PM I ever had the pleasure of working with couldn't code worth a damn. And yet, he could recite details he'd heard from developers 3 weeks ago, and apply the understanding he'd gleaned to current decisions. Furthermore, he had an unvarying nose for bullshit and ability to gently push if developers were trying to make lazy decisions.
Unfortunately, I don't think that's something you can test for or train. Either someone is that type of person, or not.
... Really? I do not get that impression at all after Catalina and Big Sur. Every release these days seems to have more problems than the last. I'll put up with macOS until High Sierra is unsupported and then I'm done.
As an Apple employee commented here last year, "I am awed by the fact that we manage to release any software at all, let alone functional software."[0]
My PMs at Microsoft were all good at tracking tasks/projects and managing blocking issues. At a minimum they saved me a lot of headache having to answer why a task was late when I was blocked by a dependency. They also had quite a few technical PMs, my brother was actually a PM there before I started after getting his Bachelors and Masters from MIT.
AT&T's PMs were a totally different story. Not only did the PM team outnumber our dev and test teams, most of them were tasked with being product owners for insanely small features. Consider having a PM literally responsible for how a light switch works in home automation, that's the level they broke it down to. Some of the PMs lacked skill or experience, but all were expected to do very little of value and were considered to be successful if they were in meetings nonstop to take notes and give them to the next team in line.
PMs can be vital parts of a tech business, but only when they are given real responsibility and expected to create value rather than countless piles of noted and calendar invites.
And when working through their two-factor-auth process, I kept getting redirected to a version that wouldn't accept my one-time-password because the javascript on the page wouldn't load for some reason. The trick was to switch from Chrome to Firefox.
I wish I didn't understand why it's possible for stuff to exist on big-company websites like AT&T.
Anyway, sounds like an absolute horrorshow for both PMs and devs alike.
Same, from FAANG companies. The feel that I get is more like, FAANG companies don't even know what you're going to do. They just want to hire top talent and figure out what you're working on later. They want someone "smart" who can ultimately work on any team, since whatever team you initially land on might be gone in a few months.
The consequence of this made the interview process for these companies feel much more like a "drinking the kool aid" test. When I asked what I would be doing, the sales pitch I got always boiled down to "you'll be working for X" as if that was enough. That might be enough for a fresh grad, but I'm an experienced specialist. Understanding my role and impact are key to my job happiness.
I don't think the intent is to be secretive, its more about - the people in the recruiting pipeline don't even know themselves, or if they do, you might get rearranged quickly, so focusing heavily on the specific work is more of a detriment. You kind of NEED to drink the kool aid since you're buying in to the company moreso than buying in to a specific team, work, etc..
The shortens the time that it takes to fill headcount, because there is a constant pipeline of ready candidates.
This also means that you won't get yanked around at the eleventh hour of the interview process with a "Sorry, we know you did great on all your interviews, but the headcount for the one team you were interviewing for filled/canceled earlier today, don't let the door hit you on the way out."
You get 1-5 different team offers if you pass the interview. You can speak to the managers of those teams, prior to saying yes. Those managers, if they are any good, should have a pretty good idea of what you'll be doing. If you don't like any of those teams (or their managers), you can tell your recruiter that (I said no to all 5 of my initial offers, and got 2 counter-offers), and they'll come back to you with different interested teams.
Your recruiter gets paid if you get hired. If you don't care what team you get slotted in, they'll slot you into whatever's available first. If you've passed your interviews, but do care what team you're gong to work with, they are financially incentivised to work with you.
Or you could just switch teams after 12 months, if you don't like the one you were hired into.
Leaving aside recruiting events (universities, etc.), candidates are interviewed with a specific role / headcount slot in mind. Sometimes there will be several; it's rude to drag a candidate in multiple times to talk to different teams and so sometimes several will pitch to the same candidate on a given day. But the search always starts with a team or teams that are looking for someone.
In my experience the managers usually have a pretty good idea of what work they need filled, but because the hiring pipeline produces generalists, there's some after the fact matching of interest and experience to the available list of projects.
FB reached out to me twice with a specific project and position proposal (SWeng/lead). YMMV
The past 10 years I've often been the first employee - or one of the first - joining or building up the company's security organization. The combination of (1) having a specialist skill and (2) being around very few other people with the same skill, naturally leads to a situation where too much clarity can be a bad thing. If a non-specialist define a security role, they will probably screw it up. And that's okay.
If you've worked in startups long enough you eventually get a lot of experience in how to hire people whose expertise you do not understand. As an employer and employee I enjoy the collaborative process of defining the role around the candidates strengths and weaknesses.
"We don't actually have anything for you to do, we just have funding for three more people, and we need to hire people for those slots or we'll lose our funding. And our team size is in the second quintile for headcount, so we need to grow a little."
So basically hiring bench warmers. I actually encountered that once in my so far 37 years. It was a total wtf moment for me.
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.
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.
Yes, if you want to be a cog in a machine.
That said, it seems you're complaining about FAANG-type companies. These guys are hiring "top talent" only as a defensive measure, so that upstart competitors don't get them. It's not expected for "top talent" to actually contribute to something useful.
Citation needed
I agree that's weird. Edit: although when did this happen in the interview process? It's pretty common to first decide if you're interested in hiring someone in general and later do the match-making to a particular team/project. Maybe not at this level though...
> Facebook is notorious for this, lots of friends get absolutely eye-watering salaries to sit around and provide 1% lifts on click-through-rates.
It's worth it to Facebook to pay someone an absolutely eye-watering salary if they can get a 1% lift on click-through rates. This work doesn't interest me, but it's absolutely not the same as otabdeveloper4's claimed "These guys are hiring 'top talent' only as a defensive measure, so that upstart competitors don't get them."
Disclaimer: I work for a FAANG. I don't work on advertising but it obviously supports my salary.
IMHO hiring engineers to hyperoptimize advertisement platforms is a bit wasteful.
Sidenote: I had taught dozens of week-long corporate training classes in software development (specifically native iOS development, Android device driver development and some ReactNative classes) to their senior staff through my training agency at this company several years prior.
I wasn't terribly interested in working at the company, because I had seen inside the machine from my earlier teaching experience and wasn't too thrilled about being a part of it, but thought the interview itself would be a valuable experience and good practice. I also expected to bomb out of the interview process early because I have heard that their algorithmic questions are notoriously hard and I consider myself a below-average developer.
I tried to get the salary expectation -- the expectation, not the negotiation -- out of the way early in the interview process but unfortunately they wouldn't come to the table so early and wouldn't even have a conversation about it.
I seemed to have done well enough during the technical part of the interview that a tentative offer was extended for a Principal role, "doing ML or something like that" was the pitch from the one wrangling the interviews. A grand but ill-defined picture was painted of roles I would be ideal for based on my years of experience and reasonably solid education (MSc CompSci, MS ML, MBA, MBA Entrepreneurship/Marketing, MA Project Management)
Towards the end of the interview process we did the usual dance around compensation and I said "$150K base and you start to have my attention, and we negotiate from there." I stated the opening figure because I was getting tired of the hemming and hawing from the other guy. I had heard of this famed, well-greased hiring pipeline but I wasn't experiencing it.
"That sounds do-able." said the person handling everything. We wrapped up quickly and then the weekend happened.
Early the next week I got an offer. I was excited! I most likely wasn't going to take the job because there were a few red flags during the interview that made me think it wasn't a company I'd be interested in working at. But to have passed the technical interview and all the other hoops! Okay! That's a small ego-boost for me even if I probably couldn't do it a second time with a different part of the FANG.
I opened up the email, and read through the offer, and read through the offer a second time to make sure I understood.
The $110K base (there was zero mention of TCO or bonuses or options or RSUs or anything else) was a significant drop from what I currently get paid (and I don't consider myself well compensated) to work on-site in the Bay area. I'm in L.A.. This was just prior to full WFH/lockdown so there wasn't even the excuse of "well you're WFH so we offer less for that."
I pinged the company back and said "That's an interesting opening offer, it's much lower than I expected for relocating to that geographic area and the position I would take, how firm are you on that number?"
"Take it or leave it." came back the one-line response a few hours later.
I didn't even bother responding.
I have heard of other people's eyes watering at their salary offers. Mine have yet to shed a single, salty tear.
And whilst I was overly surprised at the low offer -- $110K was the total comp, there was nothing else in there, I read the offer thoroughly, twice, because I was taken aback by it -- I also wasn't all that surprised at the low offer. I'd heard wild tales of high offers and I'd also heard tales of absurdly low offers. I was kinda caught off guard by the take it or leave it attitude.
$110K. That's all she wrote.
And after the "take it or leave it" I almost replied with "Fuck you", thought better of it, and went on with my life.
I've interviewed at two of the FAANMG over the years, and did an initial phone screen at Amazon. I turned down all three for differing reasons. The $110K was just the cherry on top of a pie decorated with little red flags.
I've done some mentoring of junior developers in the past. Many of them get hyperfocused on levels.fyi and HN comments talking about $400K salaries from FAANG companies. This leads a lot of them to become permanently disgruntled, convinced they're being severely underpaid.
When I started mentoring, I never thought I'd have to cheer people up about $150-200K offers in medium cost-of-living cities. Too many people are convinced that $400-500K is an easy-button. This is especially true for people who coasted by at the top of their classes at average universities who aren't used to being anywhere other than the absolute top of their local community.
Issue #1: "doing ML or something like that" is not a job description that would ever make it through HR at Facebook, Amazon, Netflix, or Google. (I could imagine slightly more flexible job descriptions at Amazon, given that hiring is more team-driven there, but not to that degree.)
Issue #2: ignoring Netflix (which only has one "title" for SWEs, with pay starting at ~$300k for 2-3 YoE, but more commonly $400-450k+ at 7-8), the rest of those companies have fairly standard ranges for compensation based on level. $110k TC is below the bottom of the entry-level SWE range in SF. At a stretch, it might be the bottom of the range in Arizona or Texas (for Amazon). Entry-level, mind you.
But Principal Engineer? Amazon's Principal Engineer is the "lowest" one, where it's parallel to Staff at Google/Facebook. Comp range is pretty wide, but bottoms out at $450k. This isn't the sort of thing where a bad recruiter can screw you over; it would require getting sign-off from senior management, probably in both HR and Engineering, to make that sort of exception, but why would they bother? If you passed an interview for a Principal-level engineering role, extending you an offer of $110k would almost have to be a deliberate insult, because of how trivially you would be able to get other offers of $500k+ from the other players in the acronym.
And, in fact, there is evidence that you could trivially provide: the email with the offer. I don't expect it will be provided, even in the exceptionally unlikely universe where there exists an email from a Facebook/Amazon/Google recruiter offering someone $110k TC to work in San Francisco as a Principal-level engineering IC.
To reiterate: if you are interviewing for a software engineering role with a FANG company for a role in California, you can expect the following TC pay bands:
Entry-level (L3 @ G/F, L4 @ Amzn): $140-180k
Mid-level (L4 @ G/F, L5 @ Amzn): $200-280k (Amzn might have a lower floor, but not often)
Senior (L5 @ G/F, L6 @ Amzn): $300-400k
Staff (L6 @ G/F, L7 @ Amzn, called Principal): $450-650+
As always, there will be some exceptions. Exceptions at the bottom will tend to be web dev/full-stack roles, which at most places have slightly lower pay bands. ML roles, contrariwise, will tend to skew higher... (at least, adjusted for experience level).
I could maybe believe it, if, out of the thousands (tens of thousands?) of engineers hired at mid-level to work at Bay Area G/F/A offices in the last couple years, a few of them were offered $110k TC. It'd still require some pretty substantial deviations from their usual process, but it's imaginable. I cannot imagine that happening for someone offered a senior+ role. Like, literally, I cannot imagine what set of organizational and procedural failures would have to align for that outcome to occur. It's not worth factoring into one's calculations when deciding whether or not to spend time applying to and studying for FANG interviews.
I've seen this many times and I find it baffling: I already have a very high paying high quality job, I want you to sell _me_ on the position before demanding I do stressful work to prove myself to you.
The vibe I get from that is: they're not interested in senior or experienced talent. What they want is new grads. So I just tell them I am not interested. Either that or the hiring market isn't nearly as tight as people claim. There must be a surplus of talent if companies can get away with this.
I don't like whiteboard coding exercises, but would be willing to do them for the right position. We need to see if this is the right position for me/them before we proceed to that phase. That means that that process comes as one of the last steps, before an offer. If they're not willing to do that, I just politely decline.
I've been on the other side of this process where the "solution" to a technical case study is flat out wrong, but most of the people training to do the interview didn't realize this to the point where the most skilled candidates would likely (and luckily for them) fail the interview by giving the correct answer!
This means that for many interviews at these wannabe-FAANG companies, if you really know your shit, you often have to proactively guess what the interviewer thinks is the correct answer.
After a while you can get a feel for whether you're going to get anything out of the interview process other than a black hole (and probably lowball) offer and just abort the whole process before it starts. There's no point jumping blind from a good position into the unknown, especially given all the ??? are a bad omen.
I recently broke my own code at an interview and was rewarded with complete nonsense. Never again.
The FAANGs practically (sometimes, actually) give you a study guide, at least. Lots of smaller places act like knowing anything more than the names and titles of the people you'll be talking to would be cheating or something. I'm not gonna burn half a day or more just to bomb a question about graph traversal I haven't brushed up on lately, and I'm not gonna study everything unless I'm shooting for FAANG. Tell me what to expect, a few days out, with decent detail, or I'm not interviewing. I don't need to know exact questions but "first thing in the morning we'll ask you to do something with very basic data structures, like one of [short list of possibilities], and it will be on a whiteboard".
Then if you tell me the day is packed with 6+ hours of whiteboard problems I know not to bother, because I'll definitely be tired AF and bombing them after hour 3 no matter how much I study, because I'm not built to literally perform in front of people for hours on end. It saves us both some time.
The study guide is hundreds (thousands?) of pages. How is that helpful?
But frankly most shops out there are not worth it, but if they are, let's talk about how. Many very smart people I know would willingly leave their high-salaried FAANG job for a more rewarding or interesting job even with a steep compensation cut -- and there are many places that would benefit from that talent -- they just need to learn how to recruit it.
I agree though, if the company isn't willing to let you talk to them about the role and requirements upfront, then I don't think you're being actively recruited for your talent and background, and the recruiter is just looking to meet quotas.
I do technical interviews for other teams within my company. I may not know much detail about the role, beyond just generally knowing with the team in question is responsible for and the topics they asked me to cover during the interview. I wouldn't ever think to ask for more details about the role because I assume that's a question for the manager or internal recruiter.
I honestly see it as a way to streamline the interview process and make it more fair. My role in the process is to determine how well you understand the core concepts of a handful of technologies, not to necessarily to sell you on the position or evaluate "culture fit." Of course, I try to be pleasant and want you to come away with a good experience. But sticking to the script is largely me being mindful of everyone's time; interviews are time-consuming and you probably don't want to be answering / asking the same questions to four different people.
The process for new grads and interns should be different from senior talent.
I don't care about the division of labour. Want to hire people away from Google? Don't be a pain in the ass. People expect pain in the interview process, but not before they are sold on the company.
So like I said, what I get from this is on the whole there's an aggregate trend away from wanting experience.
I think it's a worrying sign that the market may be either saturated with talent, and/or that companies are totally fine hiring only junior/mid-level "framework" developers.
But I see recruiting as a team effort. The recruiter should sell you on the company, the manager should sell you on the job, and I should sell you on the quality of the team. If companies aren't meeting your expectations, you should let everyone in the process know.
I'm sure lots of technical employees have no idea what the recruitment process is like at a company, especially if they've been there for a long time.
Why would you want to work for a company which has such a hard time recruiting and retaining senior talent that they need to pander to them?
For 99.9% of the companies this is not the case.
For example I like working at my current employer and enjoy the challenges compared to earlier employments. But looking at the job postings, I can't see that. It's generic crap about competitive compensation, challenging problems, modern technologies, a flat organization, etc.
If this job posting landed in my mailbox I would skip it. The only reason I applied for this job is because I was jobless and desperate at that time.
You can guess where that ended. In case you can't: "Who did I think I was to refuse their offer to come to America to partake in this great opportunity?".
Interesting attitude change, turning on a dime they went from all smooth and friendly to outright hostile, and that on a track that they initiated. Very weird.
The follow up is usually "Why do you want to leave your current company?" replying with "I'm not, your recruiter said this was a cool place".
"Why do you want to sell me this apple?"
"Be... cause... I grow apples? To sell? And you said you want one, and are holding money?"
This was at the end of the process, after I'd already interviewed with all the technical folks and all the managers and they all wanted to hire me.
Apparently the desired answer was "no." My actual answer was something like "WTF are you talking about," and I somehow managed to get hired anyway. I later heard that if I'd answered "yes" it would have been difficult to overrule HR and get me hired. LOL
Programming is not sports. I'm not a coding athlete. Maybe it is for some people, but not for me. That's not what the job I've held for all this time has ever been about.
Plus you get to a certain age and experience and the thought of "proving myself" to some 25 year old is just... Really?
If you just don't like hand writing and prefer typing, then that's cool with me and you can just do that during the interview (the content of interview is important, not the medium you write with).
If you're mentoring a 25 year old you'll have to prove yourself to them every day.
No, you won't. If they don't want to listen to you, they don't have to. As a mentor it's my job to listen to them and guide them with experience as my context, not joust with them over irrelevant, stupid, gotcha contests. And I'm happy to help them realize that just by not engaging in it.
Every senior engineer I've worked with including myself is able to write a for loop with a few lines of code in the body, because doing basic coding like this is important when training new grads and doing code review (not to mention when writing your own code).
Not sure if you are trolling.
That's an extraordinarily simple coding problem, and the usual ones you have to pass to get into Google are much harder.
Getting the job @ Google was worth that stress. The original comment I made was to the effect of: before you dump a coding test on me, you better make sure it's worth the stress by convincing me why.
Fizzbuzz wasn't designed to test people's prowess in coding. It was designed as "This is one of the simplest possible programs one can write. Can this candidate do it?" While many people may go through their whole career not dealing with dynamic programming or most data structures, almost all programming is fairly similar to FizzBuzz.
As an analogy, it's like giving someone who claims to be a circuit designer a basic circuit where he's failing at Ohm's Laws or Kirchoff's Theorems. Or an electromagnetics person who cannot integrate a basic polynomial.
If you have test anxiety that's one thing, but if your reason is "I need time to think this through", it's a huge red flag. Kind of like the person saying he needs to consult a table of integrals to integrate x^2.
I'm against intense Facebook/Google style whiteboarding. Fizzbuzz is at the extreme other end of intensity.
But I'd probably want to, just to piss off this person (the throwaway account who came on here to argue...)
Weeellll, I mean it doesn't totally succeed in meeting that design criteria. Fizzbuzz weeds out three kinds of candidates:
- candidates who are (currently) unfit for any programming job
- candidates who freeze up during the interview
- candidates who have never used the mod operator
A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator".
edit: Oooh! "How many ways can you implement multiplication" would be a much more interesting warm-up/weed-out question! Allows the quality candidates lots of room to shine.
> A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator".
While possibly a fair question, this is a whole order of magnitude more difficult than FizzBuzz. It requires more domain knowledge as well (lots of people have forgotten how to multiply).
> Allows the quality candidates lots of room to shine.
But this is precisely the opposite of FizzBuzz. The goal is to weed out horrible candidates, not identify great ones.
Sorry, in my mind the input was restricted to positive integers. My fault for not making that clear.
def mul(a, b):
accum = 0
while b > 0:
accum = accum + a
b -= 1
return accum
> But this is precisely the opposite of FizzBuzz. The goal is to weed out horrible candidates, not identify great ones.
This accomplishes both at once. That's a super set, not an opposite.
Granted, that may be counter to the spirit of the question, but it's a valid answer lol
I'll give an easy question, but I'll have them do it ssh'd on to a remote machine. I'm more interested if they know how the environment works and how much coaching they need to navigate around.
I haven't been a professional developer for anywhere near 25 years, but I could write fizzbuzz while blindfolded, on a wet bar napkin after a couple of drinks, in any one of at least half a dozen languages.
If someone asked you to write down the answer to 3+5 would you struggle with that as well? To me, fizzbuzz is barely a set up in terms of complexity.
``` case $input when $input % 3 == 0: “Fizz” when $input % 5 == 0: “Buzz” when ($input % 3 == 0 && $input % 5 == 0): “Fizzbuzz” end ```
It's quite ironic that you had all the time in the world to check your code and the ability to silently walk away when the pressure would've been too high and yet you included 2 obvious bugs in your 'proof' of how easy this is.
Thank you for your time, but I'm afraid you would not be a good match for this position at this moment.
Given a 32-bit unsigned integer, return true if the binary representation has two consecutive ones in it.
And...that's it. And people that have passed the recruiter gates and made it through the phone screen just completely lose it here. Let's be clear - I really don't care how you do it. There are 3-4 ways right off the bat ranging from a state machine to a shifting mask all the way down to a single inline math statement.
If you're as comfortable as you say, it will be a no brainer. As a check I took an intern and told him to meet me in a conference room to get the same stress level out of him. I posed the problem and got an answer in five seconds.
Now let me tell you about the candidate that wanted to turn the integer into a character string and then search the string for “11”...
However I understand that may be part of the discussion afterwards.
After years of asking the same questions to intern candidates and to senior+ candidates, interns did consistently better. There are a lot of "experienced" but not very skilled people out there. They exist already inside ompanies too (Principle level checking in hundreds of lines of code with many classes and tests, purportedly to add logging support to something, but the code was ultimately a NOP as it did nothing) but even if it's impossible to put out the tire fire it's best not to contribute to it.
The thing is, when you look for a job, you will often go for 5 to 10 interviews.
On the other end, when I'm looking for someone to fill a position in my team, I will interview at the very least 50 candidates.
That is to say, all things equal, the interviewer has most likely more incentive than the interviewee to go straight to the point, and thus perform a technical check early in the process.
Also, you have to realize than the vast majority of candidates applying for a position are highly unfit for it. Seriously, even for very senior positions, you would be amazed at the sheer amount of people applying with grossly pumped resumes, and overall low skill level once tested.
Even after careful picking of resumes, I would estimate that 80% of candidates end up being obviously unfit after the first 10 minutes of a technical interview. That's why, as an interviewer, I'm not very inclined to have a long open discussion about the job until I have at least some degree of confidence that the candidate is worth it.
Of course that process is unfair for the "good" candidates. Those who apply to positions fitting their skill set. But when you have more than 50 interviews ahead of you, and an actual job to do, you have to make compromises and tailor your process for efficiency.
Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.
However, the particularly insidious candidates are the ones who have developed a skill for talking about software/programming but can't actually write code no matter how much help or prodding they are given. As soon as you accidentally hire one of those, the case for technical interviews becomes a lot stronger.
Once he joined the company he proceeded to actually be completely unable to write a single working piece of code. Everything he wrote needed to be reviewed and had major glaring issues. When confronted about it, he would say that he couldn't figure it out so decided to just commit his unfinished code.
That guy was senior, had worked for 20 years and is really good at talking but when it comes to actually developing software, he is completely utterly incompetent.
I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk at length about them. But when given a task to do on the computer, given 2 hours alone to sit and code, couldn't do even the first part of the exercise - despite it being something you could literally copy and paste from the documentation that we gave them a link to!
I think the type of problem and structure we use for interviews is bad. Let the candidate code alone without you watching. Give them internet access. Come back in an hour or two, or let them do it remotely or as a take home. This is more like our real jobs; and gets rid of cutesy "do you know this algorithm?" questions, which many whiteboarding problems are. Instead of going for pure data structure / dp / search / sort algorithms, have them implement things like business rules.
In this scenario, having someone literally be unable, in 2 hours, to replicate the first example code of some library, when they have access to almost identical code in the docs, is a pretty good filter.
The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me. The problem is specifically about doing a programming performance in front of an audience, in an interview rather than co-worker context. I'm god-awful at that unless I'm heavily prepped for exactly what's going on. No tools? I'll forget basic syntax, yes even in "a language I chose". Let me use tools? I'll forget how to use them, or get self-conscious and avoid things I'm not entirely sure will work, overriding my own muscle memory. It's a very specific problem but I doubt I'm the only one who absolutely can do the job just fine, but is also entirely capable of coming off like a complete "faker" in an interview.
[EDIT] to make matters worse I can talk about programming just fine in that setting, which probably adds to the "he's some kind of social engineering genius who learned to sound exactly like a competent programmer while somehow also not learning a single thing about programming" impression. It's not usually an issue, but I'm quite sure I've reinforced some interviewers' notion that it's a good thing they do whiteboard screening because they're overwhelmed with lying applicants, and that I was one of them.
I've met one developer who couldn't do their job, and he moved into a pre-sales role shortly thereafter.
Everyone else was fine and did a good job but send them unprepared to a random interview on any given day of the week and I'm sure it'd be another one of those "well we dodged a bullet there".
The signal to noise ratio is Garbage.
Sure a "whiteboard interview" basically optimizes for people who can actually pass whiteboard interviews rather than people who can do the job.
But to claim that there is a NON-NEGLIGIBLE number of people who basically become 100% ignorant when under the stress of a whiteboard interview BUT are excellent employees in any other stressful situation is, to say it in nice words, [requires citation].
And if one really has this apparent rather unique type of handicap, then better mention on CV to try to get some empathy from the hirer, or just _train_ to avoid it. Yes, most people do _train_ for the express purpose of passing interviews.
Tech interviews are remarkably scattershot in the form they take (outside well-known big companies), and are unusually anxiety-generating, even in the notoriously anxiety-filled field of interviews. Describe what one might (emphasis on might, part of the problem is that it's so often a surprise) expect in a tech interview process to some people outside the industry, and gauge their reactions. I definitely think it's likely they have even worse signal-to-noise ratio than is commonly thought.
[EDIT] Certainly I find it far less plausible that there's an absolute army of people out there, dwarfing the count of actually capable programmers, who are brilliant con-persons but too dumb to figure out that that skill itself is more valuable than programming, outside the top couple percent of programming jobs by comp, and apply it more directly to business roles that actively want it.
And I'm quite confident it's not the interviewer. Usually the panel is quite anonymous when it comes to calling a "bullshit" candidate. We ask panel persons individually to avoid the "no one wants to contradict someone calling X bullshit'" effect.
I don't think tech interviews are _any_ worse than the ones outside. If anything, we have less standardization than other industries. I work for a engineering company first (software second) and the engineer interviews are basically _manufactured by HR_ (not engineers).
The problem is when you apparently _forget_ the syntax for a function declaration in a programming language you claim N years of experience in your CURRENT position. This is just absurd. Our you suddenly get completely stuck with counting odd numbers on a sequence or the like. And this happens surprisingly frequently. I just cannot believe you can have this type of anxiety (I am extremely shy myself) outside your first or maybe second interview.
Languages like C that have a single official for loop syntax are a bit easier to remember, in part because it's a syntax I have previously used on a whiteboard rather than exclusively in actual code.
So if a candidate can't write a loop on a whiteboard, maybe let them try in a non-IDE text editor, or have them glance at a formal grammar for the language as a refresher that won't give away the game to someone who can't actually code.
And if I start showing them an EBNF grammar for the language, now that's TWO languages that you will show you don't remember rather than one. I find this even more absurd; you don't remember anything of the syntax of the language you used at work for years, but you think you can rediscover it from the FORMAL language specification in a whiteboard?
I've interviewed enough people who don't even know the syntax of a for loop for the language that they chose to use.
As a general matter for how the industry as a whole interviews, I agree though; I am no longer a fan of tricky algorithmic or esoteric data structure questions in whiteboard interviews. The problem I find with other people's interviewing questions is that most people are still asking things that are way too difficult, and they don't end up judging anything other than "Did this person just cram hundreds of hours of algorithms questions?" or "Did this person get lucky and happen to know this type of problem ahead of time?".
For better or for worse, my company schedules me for like >90% system design questions now, which I prefer anyways. Start with a very simple problem and system, and then just throw wrenches.
Most loops are covered by a foreach or by LINQ (think: map and reduce, buy nicer).
The few times I actually need a for loop I type: "for" <press enter> <type the limit for i> <press enter> and then I focus on the loop body. If my needs are more complicated, I _modify_ the for loop my IDE gives me.
This is it, in a nutshell.
In all my years of interviewing candidates, I've never run into the mythical experienced developer who doesn't know anything about programming. Yet according to HN lore, there are hordes of them out there.
My theory is that the only thing there are indeed hordes of, is experienced developers who can be made to look dumb by subjecting them to whiteboard puzzles, algorithm trivia and other such questions which are completely unrelated to the job performance.
It's too true. A quick search found the source article that I read years ago here[0]. :)
From that page:
> We can't understand why so many people "fail" the Fizz-Buzz test unless we understand why it is "hard" (for them).
But the article doesn't even talk about the environment, which is what it's all about.
It's hard "for them" because they're being asked to write the code on a whiteboard, with a job/income on the line, with stress and anxiety dialed up to 11, with someone breathing down their neck watching, while expected to simultaneously provide cheerful ongoing commentary to "show how they think".
Under those conditions, I totally believe close to 100% perfectly competent developers will fail at it. But of course it has nothing to do with the programming part.
Most of us have heard of FizzBuzz while chillin at home reading articles and immediately thought "that can't be hard" and tried it and indeed it is laughably easy. So we can't understand how "they" could fail at it because we didn't experience it under interview hazing conditions.
So the "them" is actually all of us.
To me that is the key takeaway of FizzBuzz.
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.
I ask because 50 is not completely unreasonable. I've had positions where we've had to interview dozens of candidates, in our small company. In larger companies, often someone else does some initial interviews though and that filters out candidates who e.g. can't code at all (sometimes - not always!).
Like I said, I think if you have to interview that many, your filtering process is really broken further up the pipeline. You don’t know what you want, what the job really is, the or application process isn’t properly structured.
Interviewing large numbers of people is also a huge liability unless you’re extremely consistent and well-documented in your hiring process (something which I’ve found to rarely be the case).
I interviewed at Google. The position description versus what I was interviewed on were two worlds apart. Like the position mentioned front end CSS and HTML. I was grilled on SQL in two of the 4 interviews. This wasn't a SWE position, it was more of a client support role, but I was given a coding test. I did poorly on the test, but I still consider it difficult for a role that was not a SWE.
It didn't even seem like Google knew what role they were hiring for they just wanted "someone technical" to do something. I left this process feeling pretty confused and turned-off at their hiring process and questioning if I really wanted to work at a place like that.
I'll give you a pro-tip: Candidate Interview Packs. Cook up some Google Slides with the main info about the position, the company, the team, what you expect from the person, what you are looking for, the interview process, etc; beyond the dry JD that HR shares. Give it the personality of your (Engineering) team and generate a PDF that you can share with the 50+ candidates.
It has worked for me in the past.
The annoying ones are dudes who want you to somehow do a big O proof of some NP complete problem, with tests, proper code, and in front of 3 people in 45 mins (with 5 left for you to ask any questions). For something you may have not touched in 20+ years. I do not want a guy who can create the proof. I want a guy who can explain it in plain English to the 3 other guys in the group and maybe take a few days to get it right and make the code easy enough to understand so when we have to change it in 8 months they can pick it back up.
Some people ask more clarifying questions than others, but in any case a few minutes gets spent on this, we have a laugh and move on with our lives.
Of the failing candidates, around one in three or so spend nearly the entire interview on this or fail to answer entirely because they can't get the maths right.
Is that a "math trick"? It doesn't feel too different to fizzbuzz. It's not complex. It relies on high school maths, and except for very junior positions, for a job where you are expected to solve much more complex problems every day without handholding, even if you can't remember how averages work so I have to hand you the math, not being able to reason through the problem from first principles seems like a pretty big red flag for your problem solving skills to me.
What do people think?
Once I show someone the 'mod' trick they instantly get it (if they have any sort of math background) but I want to avoid as much as possible anything tricky in a interview. I want them relaxed and not tense. As that is a different kind of test. Throwing in a trivia trick can hurt the interview. I have run across many programmers that are decent at it and have never used it.
Also for your problem it would depend on the level you are interviewing for and how much time you want to allocate for it. As it is also a balance of filter and getting to know them which is mostly time management on your part. Remember you probably are going to be working with them. So a bit of chit chat goes a long way too. You can also use 'fizzbuzz' as a question 'do you know the trick of fizzbuzz'. If I show them the mod trick and they get it right away they show aptitude to learn. If they already know it then see if they can explain it. etc etc... Get them to talk. Also talk back to them like a peer as they very well could be! They should be interviewing you too.
I just try to avoid tricky bits in interviews and expecting tricky results from them. It would be like asking the to write a swap two values function and expecting the triple xor solution. Tricky is for something you have been working on for 3 weeks and need a better solution, plus two spike stories. It is not for interviews. :) Just ask yourself would you be massively annoyed if someone asked you this in an interview with no context as to why and expected a particular answer. If the answer is you would be annoyed then do not do it. If you feel it is OK and you would expect it then go for it. Just remember your time management.
But if you are applying for a programming position and claim a decade of programming experience - and literally can't come up with any path towards a solution - I smell a rat.
I have worked in the embedded industry for 6 years, and have worked on a wide variety of projects (from WiFi to drones/airplanes to medical devices), and have never needed to use this, yet the interviewer expected me to know this.
Anecdotally speaking, when recruiters throw this kind of curve balls, it's because they already have someone in mind for that position and are interviewing candidates just to fill paperwork.
Honestly, the latter guys are absolutely fire to work with. I think recruiting is like security engineering: 90% of the guys doing it are total rubbish so you just assume that's what it's like. But that last 10% are super good, and the top 1% are really freaking good.
I remember when I first encountered a recruiting pipeline put together by a guy who was good at it. Literally every person I spoke to was a good engineer. We did tech-screen them, but only after the initial call where we talked to them about their interests and our company objectives.
Literally every one of these engineers knew:
* What sorts of problems they wanted to work on
* What stage of company they wanted to work at (seed, series-A, ..., big established company)
* What risk they were willing to take
* What sort of team they wanted to work on
This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot.
Anyway, I was very impressed. Also, the fact that almost every one of them didn't bat an eye at the tech screen. You read some of the comments on HN/Reddit and you see that these guys are a cut above the standard dudes.
Like, just the social nous. Way off the charts. On HN, people talk about an interviewer mis-sizing the problem: "Haha, so I told him I'd do it on a single SGI UV 300 with 3 TB of RAM. The interviewer got stuck. I got him.". These guys are like way better. If you mis-size, they'll just be like "Ah, okay, so you can get this done on a single machine these days, they have a lot of RAM, but that's trivial. AWS has the u24s for 24 TB or something. So let's say the problem is even bigger or that we want the other advantages of clusters" and they'll take it away. No chip on the shoulder. No insecurity. If some constraint doesn't make sense, they'll say "Okay, if we were doing this in prod, I'd push back on that, but let's say it's the case" and just go on.
We didn't convert everyone - not everyone wants to work in our domain or wants to deal with the quirks of our team or whatever, but that's life. It was way more enjoyable as an interviewer.
I think that's probably more the rub than anything. I never had a happier time being an interviewer than my time at hypergrowth startups. The sheer caliber of both candidates AND resource allotment towards landing them was far higher than what I was able to see in the BigCo environment. It made things a lot more pleasant.
I would think that any "straight to the point" hiring process would be "straight to the point" because it avoided the technical interview process:
A) there's not much you can do to entirely avoid problems with work performance and B) technical knowledge can only be sussed out so far in an interview, period, before actual work performance in the context you're hiring the person for can be evaluated.
Why? IMO this is about an order of magnitude too many. I typically interview about 3-4 people, on rare occasions a few more. I've been interviewing candidates for about 25 years now.
If your recruiter is sending you 50+ mismatched resumes for a role, get a better recruiter. But even in that case, you should notice and weed these out while reviewing the resumes yourself, before getting to the interview stage.
I literally cannot imagine any scenario where I'd interview over 50 people for a role. Or even ten people.
A few startups ago we had to grow the team from 20 people to ~120 in a year. Your approach would result in interviewing well over 5000 people in a year. That would be over 20 people a day, every single day, zero work getting done meanwhile! I suggest a re-think of your hiring strategy.
> being obviously unfit after the first 10 minutes of a technical interview
Which one is more likely:
1. Senior people who have built many successful products don't actually know how to do what they've done.
or
2. Interview techniques that focus on skills unrelated to the job (e.g. whiteboard puzzles, algorithm trivial pursuit) have an inordinately high false negative rate.
Let me clarify first that 50 interviews include phone screening, where we don't do specific technical questions but rather just poke around what the candidate is looking for and whether they seem able to explain what they have been doing without drowning.
As for the process we use, we are a hedge fund of 30 people, we have no HR, so I directly deal with head hunters. That means the numbers I gave are "raw".
I see a lot of comments arguing whether it's even possible to assess technical skills during an interview, and overall spitting on whiteboard brain teasers.
For the former, really, you need to be in the front row of hiring to understand it. I'm not talking about filtering candidates that can answer library specific trivia or solve red black tree removal on a white board here. I'm talking about senior Python developers that cannot remember the syntax of a for loop, data science specialists that cannot ELI5 the intuition of a linear regression. That's the degree of "low skill level" I'm talking about. I think a lot of people here are biased toward thinking the average programmer on the market should be the same skill level of their average colleague.
This is Wrong.
You are reading hacker news, you are very likely to be passioned and dedicated about what you are doing, you are most likely working in an above average company, surrounded with above average colleagues. Your perception of the average programmer is biased toward your own surroundings.
Now I see that the whiteboard interview seems to be really dreaded. And man, do I feel you. I also used to hate them as an interviewee. But that does not mean they are all the same.
When I do a whiteboard interview, I am perfectly aware that the candidate is obviously stressed, uncomfortable, and not at 100% of his potential. That's why the questions I ask are typically not too intellectually challenging. Some variations of the fizzbuzz mainly, along with a small exercice on recursivity in case the fizzbuzz is too easy.
"Whiteboard interview" should not become a strawman for "24yo fresh grad throws B-tree inversion at you to feel superior". Really, the only thing that should be tested in these interviews is your programmer muscle memory. And from my experience, it does work.
Agreed, I'm totally confused and put off by this as well.
Those 24 year old interviewers are the ones you'll have to train, so you need to, at minimum, be able to do their jobs.
(FWIW, I am also a senior engineer, and I have seen this play out from both sides of the table.)
Sometimes folks overestimate their value as senior engineer for certain types of companies, and under-appreciate the risk companies take in hiring an employee. Large companies, for example, generally do not need yet another L6+ that cannot get their hands dirty. They usually have plenty of folks that fit that role already. Additionally, senior engineers are expected to mentor junior engineers, and doing so often requires whiteboard technical skills.
I cannot tell you the number of L6/L7/L8 interviews I've done where it was clear the person had no idea how to write simple algorithms, or put together a basic design. They may be great (or not) at the job they have been doing for years, but that sort of information is not accessible to the interviewing company. If the skills existed, it is a red flag if the candidate let them languish. Or perhaps those skills never existed, and that's a very large risk the company ($100,000s/year) is taking, especially for companies (cough FANG cough) that have a "you must be smart if you made it here" attitude around letting people go.
If one agrees to interview somewhere, it should come with the understanding that it is a mutual exchange. The company is not doing the interviewee a favor, and the interviewee is are not doing the company a favor. Both sides are expending work, which involves some tradeoffs and annoyances. As an interviewer, throwing in a technical question early is an easy sorting check to make early in the interview process before it gets into the nuanced details around role fit.
And, to be honest, as a well paid senior engineer my time is pretty valuable. Doing a skills test and then finding that the job is not of interest to me is pretty frustrating.
Of course people in these positions don't code, they couldn't be further away from developers. It's fine that FAANG want heads who can code AND run a department but it shouldn't come as a surprise that candidates don't match that.
That's precisely the sort of things I hire for and I have mixed feeling about that :)
First, infrastructure has a bazillion technical things to deal with between OS, systems, architecture, networking, hardware. Most of these are not even expected from software engineers so it seems disingenuous to make them a hard requirement for a management/lead position.
Second, it's irrelevant to the job. Senior candidates will be mentoring younger developers, developing the team and the department, coordinating and working with other teams (potentially hostile), taking architecture decisions a thousand step above coding a loop, handling hiring and promotions, taking care of budgets and schedules, etc... they should be evaluated on that.
People can't be perfect on technical aspects and soft skills and management. That's an impossible high bar.
After seeing tens of candidates, some of whom would certainly have done the job just fine, yet all got rejected for one minor thing or another. I have mixed feelings about the interview process. Yes, being rusty on algorithms should not be a blocker for some roles.
I understand that you are highly compensated and may not want to spend time trying out for a new job when you already make so much money, but from my perspective: I have a team of highly compensated individuals who are evaluating a candidate for potential hire and I don't want to waste all of their time if the candidate can't even write a simple algorithm to rearrange the characters in a string.
Since it sounds like you're pretty happy where you're at you have the freedom to choose to participate or not. I am guessing that the only way to pull away a candidate like you is by referral anyway, so I am guessing there's not actually a problem here.
If I am getting someone via referral, then interviews can focus on what you find valuable - I can sell you on the role, I can ask you personality questions and make sure there is goal alignment. If I have someone to vouch for you. If you're a stranger? You better believe you gotta write some code.
I think that if you take a step back and ask yourself if you'd really like to work at a place where they hire people who they haven't seen code, you'd probably rather choose to just write some code for 30 minutes in an interview.
Further there's also a question of what kinds of questions, and how the question is asked, but that is a separate topic.
In any case, as a tangent: Most of the questions asked in these interviews have little to do with the day to day tasks of software engineers. So I'm not sure they give much insight into the performance of software engineers doing software engineering. But they do give preference to the skills obtained in CS algorithms courses, so there is an intrinsic bias towards hiring new grads.
There's lots of debate on what kind of coding questions to ask. My questions are more fizz-buzz and less CS textbook. You'd be amazed how many people apply for senior level software engineer roles who can't demonstrate basic programming skills.
I've also been turned down for telling someone XML wasn't something people needed to really "know" to work with. The stack bias and navel-gazing of recruiters in their vainglorious attempts to prove that what they're doing is useful has reached peak.
There's a huge surplus of people claiming skills they don't have. You'd be shocked at how many people who claim to be strong data scientists don't know SQL.
When I last hired for a technical position, I had half an hour for each candidate to decide whether to move forward with them. I wrote up seven questions that took fifteen minutes to answer. I also spent fifteen minutes talking about the job, the co-workers, and answering questions about the fit of the position.
There is no shortage of labor in the market, and I would say that has been the case for the past 10 years and it has been progressively accumulating a glut. I can ask a senior programmer to complete a multi hour at home task after a brief call, and they will expect nothing in return. When I DJed at strip clubs, I would be payed to try out. Both have similar situations of a position staying open for months on end, large pools of people applying, and the need for selecting a candidate based on skill. The difference is incentive from the other DJs to fill in a Tuesday shift is way higher than a team to sign off on a DevOps engineer. Other people just aren't directly impacted by your marginal value and the selection process is going be for other qualities that are. As for the company's perspective, these engineers still cumulatively provide tremendous value and everything is stilling humming along more or less fine.
Someone, somewhere at that company chose to hire someone... and they know what they want them to do. Why aren't they telling me?
Here I am sitting down expecting to divulge all sorts of things / do a dance, but they can't tell me what they want...
There's all sorts of reasons to not tell anyone / corporate circumstances, but it's a really bad foot to start off with / makes me worry.
This isn't necessarily true. As a counter example, I've seen team leads who claim they need to hire more engineers in order to keep up with workload. In reality, it's a process issue, but why put in the hard work of streamlining company operations, when they can just request more people underneath them. Not only is it less effort, but they also get to say "I grew the team 2x and now manage y people" which in turn increases their compensation.
It's a case of poorly aligned incentives: managers are supposed to do more with less, but their compensation structure rewards the opposite.
And when that new person asks what they will be doing, the answer actually is, honestly, sort of ambiguous.
It's not a great sign for how organized they are, but it's still a realistic way someone could both be hiring and not know exactly what the new person's day to day will be like.
For me "we've got like 20 things going on, here's a little about them, so that kinda stuff, but I've no idea day to day how it will play out" is actually plenty honest if that's the case.
If taking a call at 1am is your version of hell, make sure to interrogate what the on-call schedule looks like. If you're up till 3am most nights anyway and honestly don't mind taking the call at 1am, spend the limited reverse-interview time during your interview to ask about other aspects of role and company culture. (Pick your poison from the Joel Test - https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... )
One of the worst things about interviewing at the big G.
When I started (9 years ago) it was stated during onboarding that you would be expected to move every two years or so. That's probably softened a bit, but it's still a part of the culture.
So even if you don't love where you're initially slotted, nobody is going to frown excessively when you transfer elsewhere after getting past your noogler phase.
I've found it frustrating to interview at other places and get blank stares when I ask about how team mobility works within the company, what happens when the team is restructured, etc.
Yes, the first bit doing something you don't like might suck. But I like that Google conceives of software engineering positions as a broader discipline than "I'm a fullstack developer who uses XXX language and YYY framework"; that isn't going to be of any use to Google anyways. We generally build our own tools and have our own frameworks.
Does it put people off the hiring process? I'm sure. Luckily Google has lots of people to choose from.
But I seriously doubt anyone who wants to do ML is going to sit through a year on the java team on the off chance that they could move to an ML position in a year.
Among the bigger companies, Google is by far the friendliest when it comes to intra-company transfers. All you need is the manager of the destination team to accept you. If the team is in a different country, the immigration teams will do what needs to be done. You don't need permission from your current manager.
Maybe you don't care about this, but many would consider this a huge 'perk', that justifies Google's focus on hiring good generalist SWEs who are not too wedded to a specific team.
It's a very strong part of Google culture, and it manifests itself in every aspect of Google life, such as general openness wrt code and documentation across the whole company, internal job boards etc. which make it easy to take a call about what team you want to work on next.
Google and many other tech companies optimize for a low false positive rate vs a low false negative rate. They would rather miss out on good talent than hire someone who doesn't fit their mould of what an engineer should be. This can work for Google since most people want to work at Google and they have a steady stream of applicants.
You don't need permission from your current manager.
Maybe you don't care about this, but many would consider this a huge 'perk', that justifies Google's focus on hiring good generalist SWEs who are not too wedded to a specific team.
It's a very strong part of Google culture, and it manifests itself in every aspect of Google life, such as general openness wrt code and documentation across the whole company, internal job boards etc. which make it easy to take a call about what team you want to work on next.
- Everyone I interviewed on my would-be team felt like they were attending a funeral, never met a more depressed unenthusiastic bunch.
- One of the interviewers wondering why I wanted this job as it was terrible, he stated he was looking to leave and warned me about the company.
- Meeting room of interview room(conference room) reeked of sweat(when no one was there), it was disgusting, this from a company that was heavily funded(going public this year!) also trash on the floor and interviewers unprepared as well.
- Interviewer saying there was not much work here, the company mainly collects royalties from IP and the position would see alot of downtime/doing nothing(manager saying this!).
The lower on the totem pole you go, the better the information about what it is to actually work for a particular company. The people at that level are more honest , more plain spoken and generally simply nicer and will look at you as a partner rather than as a resource.
'Look you will be overworked and underpaid, but you will get to do really cool hands on things here.."
I appreciated the honesty.
The other bad one was a smaller firm that decided they were going to do a 'super hard' Google c. 2005 interview, in 2018. But they didn't know the answers to the questions either. Lots of 'how many piano tuners...' style questions they were looking for exact numbers with. Tried to have me debug code they had printed out. Turns out I should have known that their Python 2.7 functions wouldn't run on the 3.2 version they compile with. Yes, from a code print-out. Half way through a few just bail to go surf reddit, with me in full view of their monitors. The remaining people just start answering emails and aren't listening to me anymore, but still are asking questions. The snide remarks were the cherry on top.
When I was hired the job description was even written for me.
I'm in more of a marketing organization but if I look around me, there are positions for vastly different skill sets, backgrounds, and preferences. Most of the people in the larger team couldn't do my job well and I couldn't do theirs.
I think the biggest issue is when the time limit isn’t moveable. If you’re finishing up interviews next week and the time limit cannot be moved, then that is a problem. Inflexibility from the get-go is a bad way to start a working relationship.
There is no reason to be nice or considerate to companies, they will drop you in hot second if it is convenient for them.
Second, the definitions for fraud vary from jurisdiction to jurisdiction, but the course of action recommended here falls under the common definition of civil fraud:
>"Somebody misrepresents a material fact in order to obtain action or forbearance by another person;
>"The other person relies upon the misrepresentation; and
>"The other person suffers injury as a result of the act or forbearance taken in reliance upon the misrepresentation"
Third, a time limit is not duress unless there are other exigent circumstances. Duress is usually defined as:"threats, violence, constraints, or other action brought to bear on someone to do something against their will or better judgment." Getting someone to accept a slightly lower salary is not 'against their will or better judgement', it's just a negotiation.
Obviously there would be extra context in practice, whether the candidate has a job, has already resigned, etc... The typical HN commenter in SF already working at FAANG might not be an ideal scenario ^^
Anyway, there's no fraud or misrepresentation, as long as the candidate intended to join the company at the time of signing. If anything, the candidate moving to another company is evidence that they were really looking to move, thus there was no misrepresentation on his intention to leave.
Would you really begrudge someone who left for an opportunity that is better for them?
You are mixing up loyalty with persons with loyalty to companies. The former is important the latter is foolhardy.
One time a startup hired me and a buddy as contractors (expensive contractors) to help with their push to release. They had hired a bunch of junior (it seemed) marketing/sales/bizdevs types around the same time too. Two weeks later just about everyone was fired except the two expensive contractors (me and my buddy). I found out because I could hear some of the outgoing employees crying at their desk. One day they are eagerly working overtime to prep for a trade show, next day they are packing their stuff.
Soon thereafter, my project was canceled and I was reassigned to other work for a few weeks while I looked for somewhere else to work.
It's a Great Day at Hall Kinion was awesome on that gig too. I asked my handler to find me a new position, instead she setup an ambush meeting with me and the CTO to discuss why I wanted to leave. I couldn't believe it.
Sometimes a party that can show they relied on the offer and then suffered money damages after it was rescinded can get some relief in court, but it is rare. Typically these cases are folks who accept an offer, quit their job, and move across the country only to have the offer rescinded or the position is eliminated soon after they start. Most often employees harmed this way lose in court unless there is strong proof that the employer knew they were ending the position before making the offer.
> I have a PA friend who was offered a job in Alaska, relocating his home and family from WA. Job was offered, signed, and less than two weeks prior to start, when the house was on the market, and trucks loaded, he got an email.
> "The urgent care clinic has been sold to another company. As part of their review of the clinic, assets and employees, they are rescinding your offer indefinitely. Thank you for your interest in the position."
He got compensation without having to go to court when he made mention of the fact that it wasn't a surprise to the clinic that they were being sold, nor would it be unexpected that the new purchaser may (would) want a financial review, and final say on new hires.
I had a guy leave after a few months because the big company he really wanted to work at finally came through with an offer. I wished him well and was happy for him.
I have a PA friend who was offered a job in Alaska, relocating his home and family from WA. Job was offered, signed, and less than two weeks prior to start, when the house was on the market, and trucks loaded, he got an email.
"The urgent care clinic has been sold to another company. As part of their review of the clinic, assets and employees, they are rescinding your offer indefinitely. Thank you for your interest in the position."
He, thankfully, though not without significant effort, was able to get compensation for some of the non-trivial expenses and inconvenience.
I'd argue _that_ was fraud.
I hear companies wanting a lot: "we're looking for someone willing to commit for three to five years, and not move on". Well, what are you willing to do for _me_? Or am I going to risk a "Hey, take a seat. As you know, the economy isn't great. Accordingly, today will be your last day"?
Exploding offers are the least bad solution. Give them 48-72 hours, with a small extension if they are currently talking to someone else.
You can do any number of things to differentiate yourself from a FAANG to make your company more appealing. However, each candidate will have different values, so in order to gain an edge you first have to engage each candidate with the goal of discovering these values.
For example, this morning I was reading a recruiting email while considering a Sr SDE role on the AWS S3 team. They list 4 basic requirements for candidates, one of which reads:
· Able to debug, troubleshoot and resolve complex technical issues reported by customers
This screams of being responsible for legacy code and spending time on-call resolving other people's bugs. Can your company offer green-field development? Then congratulations, you've just gained an edge over a FAANG!
Other ways to differentiate are to consider the candidate's career trajectory. Maybe they want to become a manager, a technical lead, or pick up new technical skills. Can you place them on a team that will facilitate their professional development? If so then holy cow, this small company is looking better and better!
The point is that you can't go to war with a Goliath and expect to win using brute force. So if your opponent has 10 ships while you only have 1 then do yourself a favor and fight on land.
For context, I've had to lead and grow technical teams in the Seattle market, which means competing with Amazon, Facebook, Microsoft, and to a lesser degree Apple and Google. Having filled ~50 technical roles, I can say that succeeding in a competitive market requires you to be hands-on and highly engaged. And if your recruiting pipeline begins and ends with a submit form then you're going to make life really hard on yourself.
If your prospect isn't buying what you are selling, you need to make your offer better.
Assuming the time period is reasonable (a week or two), this works well. What I, as a hiring manager, want to avoid is you shopping my offer against 5 others for the next month. This gives people some safety net where they can get through their current interviews with other companies and then compare them at the same time and give me an answer with a known timeline.
My biggest mistake once was falling for that pressure, and then I left soon again. It's a big red flag, or offeres that are only valid a few days...
Exploding offers are the least of the problems as a candidate.
I would personally feel uncomfortable doing this as would a lot of the people I know.
I likely wouldn't unless the company was really being unreasonable and wouldn't budge (and that should probably give you second thoughts) and you have another hot lead that you'd really prefer if it came through.
Or you accept and don't hear back for two weeks.
Or any other number of reasons that some lumbering company loses you in the intake paperwork.
I ended up contacting the company I wanted to work for the most, and said I had an offer. They ended up fast tracking me and giving me an offer as well. So at least the first company validated me and helped me land the one I wanted..
Sometimes, employers will call my spouse up and complain that students have reneged and she shouldn't have allowed them to do so!
I don't see how an exploding offer is a good strategy. The kind of people you'll catch with that trick are not the unicorns. Until the exploding-offer, I was a big fan of that company.
It's a terrible dark pattern and wish everyone would just dismiss it outright. Kudos for doing so.
Thanks for showing off this side!
> Your interviewer is only open to solving the problem ONE way
If this is someone you'll be working closely with, it's a yellow flag, but the common complaint you read here about algorithmic interviews not being the best way to evaluate someone for a job, this really just tells you how good this person is at either that problem or interviewing.
> Consistent lack of interest or low morale from interviewers
Normally, I'd agree fully, and as an interviewer, I go in with a sales hat on over my technical hat. During covid, I have no idea how to read low morale.
> based in Palo Alto...a six-figure offer definitely didn’t seem like a bad start
This is table stakes for a software engineer in the Bay Area, now. Not sure why it was worth adding.
I'm guessing because it's something most of us can relate to and that's what made me click on it. But I feel like I've read this same content in different articles, that I've found on HN, multiple times.
It's also kind of like somebody posting true life pro tips because it's useful for most of us hence why it gathers so mony upvotes probably.
Maybe these transparent content marketing articles ignite my skepticism
There are some questions where if you get the person to take them seriously you may pop whatever bubble they're living in that helps them get through the day.
One place, I was not doing so great. I was participating in the interview process, mostly trying to make sure our candidates were better than our status quo, so new people would make my life better. This one kid asks, "what do you like about working here?" and I froze. I didn't have an answer. Luckily there were three of us, and I had time to come up with a half-assed answer that didn't consist of "Run!"
Shortly after that I decided to leave, and just making that decision let me make it to the next bonus payout, which was something on the order of 10% of salary after taxes (so ~8 weeks?), plus a few more options vesting. And then I was out the door, along with about 1/5th of the engineering department. It's like people forget there's a door until someone else goes through it. Afterward, the members of the exodus sat around over beers to celebrate the check clearing. Someone (possibly me) asked if sticking around for the bonus was worth it. Almost all of us said no.
Not saying you are immoral here -- just that it does seem to pose a dilemma. I have not had to interview someone for a company that I want to leave. It sounds like it would suck and require some level of internalized rationalization to go through with it.
Two, it's easier to leave a place when you know you've left a project in good hands, instead of knowing things will unravel if you do. Mostly, it's an ethical problem if you sabotage the hiring.
But I'll agree that there is a tension between professionalism and social responsibility. What do I owe to my employer, what do I owe to the local developer community? The next time I interviewed, a guy I had a lot of respect for referred me to a used-car-salesman of a recruiter for a place he was leaving. I did contract-to-hire, walked away from that one. Felt a bit like a meat shield to cover his retreat. I realized all the things I respected him for were past tense, and honor that but stay the hell away from him now.
Is the problem with the company or that the company is no longer a good fit for the interviewer?
Personally, I've been interviewing people to join the company I work for while also on the lookout for changing jobs and I don't feel it's immoral.
I would recommend my current employer in general, but I'm not sure it's still the right place for me.
http://blog.interviewing.io/wp-content/uploads/2016/07/just-...
Also, maybe add a redirect from http to https?
I got there and met with a guy who had 3 or 4 "AWS Certified" pins attached to his shirt. He wanted to know how I had learned AWS since I did not have any courses or certifications on my resume.
I dropped the position immediately after.
:-) Back when I interviewed at Google, this was their signature. If they made you an offer, it could be to work on any team, anywhere. Their choice.
"Consistent lack of interest or low morale from interviewers"
And this is why I never got a research job. Telcordia Research, 2004. The only group actually hiring was really doing product development. Everybody else left in the big, empty building were the people who hadn't already escaped.
This is good advice. I certainly have a different perspective of a number of companies, where my outlook of those companies has changed are after witnessing this. It was easy to pass on those companies.
That's 100% personal taste, as I'd rather work for a "calm company".
Haha, I've happily been in the "interviewer" side of this two times:
One time, as part of a DevOps interview I asked the candidate to run something in a POSIX OS every 15 seconds using a cronjob (that was the general idea). Crontab granularity is only in minutes, so you have to use your head or Google to get a Cronjob answer. The interviewee however told me about the 1 minute granularity of CronJob, and offered instead to create a small service on init.d. with a while/sleep 15. I loved his response :-)
The other was someone who, while solving a binary search problem without a ceiling integer value, used the fact that his language of choice C++ has an INT_MAX macro defined to set the limit of the search... TOUCHE.
As an interviewer I personally love when these sort of things happen because it shown the interviewee is really thinking about the problem.
Why would you ask questions which you know are impossible? That's setting up the candidate to fail.
0 * * * * foo()
0 * * * * sleep 30; foo()
I've got guys that just google it, others that do a script and sleep within the script, and the guy that suggested the while. All of them are "right" answers for me... I don't really care about how they do it, but the process perform while doing it.
Fact is, during the life of a DevOps, they will need to solve things that they don't know how to, so they'll need to be able to at least Google-fu themselves out of the problem.
init scripts are run sequentially, each init scripts MUST terminate quickly AND leave no child process, otherwise the init sequence is frozen.
If there is a while() loop in an init script, it will freeze the init sequence. If an init script starts another program without daemonizing, it will freeze the init sequence.
High chances are that you missed either or both of that in the solution. The init script will work fine while you test locally in the shell but it will blow up startup on the next reboot.
I don’t think I’ve interviewed with 60 places in a month but I’ve certainly done around 60 interviews in a month. (10+ days of onsites, lots of phone calls) But, I think it’s quite rare. I was desperate for a job and sucked at interviewing. (Ahem, and I still suck at it)
Yes, a good LinkedIn profile with the right resume items helps with that. Also living in (or relocating to) a tech hub.
One, wrt the companies I worked for, I didn't feel like they were vetting my technical skills enough; at best it was an hour of chatting and going through some of the code I wrote, but in my head there's just so much more to it. I felt like they were easily impressed. I also felt like I was cheating because I had reviewed so many interviews, so I knew what to look out for.
Second, I initially went in there just to orient myself, to prove myself in technical interviews, but for both recruiters and employers, it felt like going into the process already meant I really wanted to work there. I never felt like I learned enough about the job to make that decision yet (although there is usually a one month grace period where you can quit or get fired without cause).
Third, wages varied wildly. One job that was interesting was right across the street from me, flew through the interviews easily etc, but their offer was at best 2/3rds of what I earned at the time, it would have put me back years. I wonder if their wages were just not that great in general, or if they were betting on me preferring a one minute commute over a decent wage. I couldn't afford to live here on what they were offering so I declined. They did get back to me a few months later, I wonder if they changed their wage structure. I might reconsider if they can go over my current income.
I did find a new job in the end, one where I didn't actually do a technical interview, but where I felt like they actually needed me (instead of just an ass on a seat), like I had a Mission to accomplish. Still working on that, slowly. What also helped is that while I work 4 hours / week less now (I was looking for that), I still earn the same as I did at my previous job - less taxes for a lease car, and income tax laws changed.
Some companies who did feel strict during the interviews actually were really good companies.
The opposite is true, I interviewed a company that seemed open minded and fun.
The interview in appearance was quite enjoyable, but with huge red flags. The CTO was always talking (super fast) and just wouldn't let me speak. I could ask only one question (during 1h) and was rudely interrupted in the end because he had no more time.
The CTO also said something like "If you join this company you will work with very competent engineers, smarter than you". To which I humorously answered while defending my pride, but probably ended up looking like someone full of himself.
Clearly this is not someone I would enjoy working with on a daily basis.
It is important when thinking about social issues that the VAST majority of the population have very much the opposite experience - they might have to apply to 20 jobs to get one interview and if they get an offer they have to take it or they won't be able to make rent. The knock on effects on that on their work life are enormous.
[1] This doesn’t apply for those new to tech or, well, contractors!
The types of engineering that I do are not the most technically difficult. But it is a very small piece of the engineering pie, so there are not many out there with my combination of skill-set and education and experience. That is, I may not be representative of what the client probably needs in the long-term, as I was hired by the client to solve a particular and unique problem.
So I typically screen for someone under 45 (I am over 60) that has done and is interested in certain types of math, programming, test, and hardware design. This is how interviews need to be structured - and just devolving algorithms and citing random information and doing circuit node calculations from schematics will be less likely to identify the engineer that you need.
As for the problems cited by the writer - they are relevant, but are structural and should be self evident to anyone out of school for more than one or two years.
Questions you ask are what dig up the red flags. Who am I replacing and why did they leave? What's the largest obstacle the engineering team is trying to overcome? How do you (the manager) manage your team differently? Is there anything you as a manager would like to improve at?
90% of workplace satisfaction can be attributed to (or sabotaged by) one's direct manager. Make sure you'll appreciate their style.
hope that helps.
Hot takes about interviewing are a dime a dozen because it's an easy thing to have an opinion about, and as long as you punch up then your takes will generally be accepted.
What's always missing from these articles is any empathy for the people on the other side.
If they apologised and said they where picking this up as original person could not make it, that's different.
Seeing a set of minutes/notes from a couple of meetings would be a good filter
Mine left within a year, and so did the priorities he had me working on, and the giant shield he put between us and his crazy boss. He was losing a culture war and decided to get out before he was shown the door. And then it was like a slow motion version of Howl's Moving Castle when they take Calcifer outside.
I'm not sure how you ask that question, although I expect you start by first avoiding any place with exploding offers, and taking the time to ask lots of followup questions. You'd want to know about your potential boss's boss, and their peers.
Some basic red flags:
* Poor ability to self-reflect or demonstrate that they've learned things from their experiences
* Lack of or otherwise poor critical thinking
* Inability to communicate
* Inability to display core competency in the skills required for the job, especially when challenged (I don't do "adversarial" interviewing, but I do throw a lot of spanners into their answers to see if they can vary their approach)
* Inability to demonstrate handling challenges and negative experiences constructively
* Poor decorum - "putting your hands at 10 and 2 on the wheel." There's not always one single thing that becomes a red flag, but things like badmouthing 3rd parties, airing of grievances, extreme arrogance, and so on. The proverbial "Would I like to work with this person?"
So for example, we don't actually phrase it as "Would I like to work with this person?" we just ask for feedback on "General Behavior and Attitude"
If they pass the other components of the interview but fail that one, we usually send them on to a second interview and directly look to confirm or refute the poor behavior / attitude assessment.
We also ask recruiters specifically to reach out between interviews for "small talk" to discern behavioral findings.
In terms of training interviewers, I couch it in terms of decorum and "putting your hands at 10 and 2 on the wheel" and that it's a box-ticking exercise, not a psychological study - that is, 90% or more of the subpopulation of qualified candidates with sustained work history know how to "behave professionally", and this isn't a differentiator.
Anyway, to your comment: there are people like this everywhere, in all industries. The more money there is involved in a domain, the more you will find people that are only in that domain for the money. Doesn't mean those people wont have legit skills that can be utilized, but there are some downsides as you note.
Describes my experience with Conoco-Phillips 7 years ago.
> Undue pressure to accept an offer
Sometimes the recruiters may do this even the company may be cool about you taking your time. So don't take the recruiter's attitude being representative of the company.
Especially if it's a third party recruiter.
A couple of thoughts on two points raised here:
1) Pressure to accept an offer. I may have lost out on an offer from a promising company by asking for a decision too quickly, and I did this because I was under pressure to accept a different offer. I believe the company's policy is that 1) they'll never rush their own decision to make an offer and 2) they'll never rush a candidate to accept. They figure that if they want to hire you, that won't change a month from now.
This position has a lot of integrity, but it does come from a position of great stability. Small companies may have only enough funding for one position, and they're terrified that by waiting for a strong candidate who is unlikely to accept, they'll lose out on another excellent candidate. The company I applied to was well established and well funded enough that they could hire anyone they felt was an excellent candidate. They were, in short, always recruiting, never desperately. The scenario I can't really respect is the company that takes weeks or longer about getting to an offer and then wants an answer in 3 days. I suspect that it's always usually best to pass on a company that is so desperate it needs to do this.
2) Not enough clarity about your role, and underprepared interviewers.
I think this can result from the "always recruiting" mentality. When it's tough to hire, and you have the money to hire, it really becomes about finding people when you find them. Companies are less concerned about exactly how to use a new hire, they're more concerned about finding someone they believe can make a strong contribution. As a result, they don't really hire for a specific role. Now, this is understandable as a motivation, but it leads to interview that are bewildering to a candidate. I've had full day whiteboard interviews covering data structures, SQL, and math, but without having read the company's website in advance, I'd be damned if I knew what they did, at all. That just can't happen. It shouldn't be possible for a candidate to go through an entire day of draining exam style interviews and not have the faintest idea what the company does. Even my interview at Google, which was very whiteboard-examish, the interviewers still took the time to explain what they work on before saying "so, suppose the search space were no longer rectangular or convex, how would you modify your code to find all matrices with positive determinants".
They aren't thinking about a role, they're thinking that if you can solve difficult code/math problems at the whiteboard, present and explain your ideas clearly, and seem professional in your interactions with people, they'll find something worthwhile for you to do (or, perhaps, they have confidence you'll find something worthwhile to do). It does make a certain amount of sense, but it leaves the candidate in the dark, and I don't want to join a company where my only interactions have been algorithm and data science questions at a whiteboard.
Bump it up to 500!