Hacker News new | past | comments | ask | show | jobs | submit login
Red flags I saw while doing technical interviews (interviewing.io)
452 points by leeny 3 days ago | hide | past | favorite | 378 comments





Role clarity is a huge one in my book. I've turned down numerous offers because when I asked what the specifics of my day to day job were going to be, the answers weren't clear.

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.


Of the big tech companies, I've worked at Facebook, Google, & Apple. I've still not quite cracked what's different about Apple culturally that they seem to be more immune to this problem. The only main difference I can spot is I don't recall ever encountering a PM at Apple. To do planning engineers would propose improvements, new features, etc. These were bubbled up. Then executives would be responsible for building a theme around those developments & how that fit larger company-wide themes for iOS. On the other hand, I don't know if that was an Apple-wide thing or iOS-specific (at the time it was hard to distinguish since the entire company was largely organized around iOS/MacOS).

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.


I worked at Microsoft for a few years and later as a contractor at AT&T for about 2 years. I saw the 2 extremes as far as PMs go.

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.


I had the displeasure of using AT&T's website today and even before I read your comment, I was thinking that AT&T must have a dysfunctional "development by checklists-for-PMs" culture. The site seems like UX appropriate for an SPA, but whenever taking an action, you get redirected 4 or 5 times before landing on the page you intend...only to have some of the elements "lazy" loaded, where "lazy" means "never actually materializes."

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.


The way Apple manages to do this is that, to a larger degree than others, the company is run as a collection of different companies. This has pros AND cons but one of the pros in this context is that their hiring is less "work at Apple", and more "work for THIS team at Apple". Hands-down unbeatable for the specific question of role clarity, but it's naive to pretend there aren't downsides to the practice.

This is how Bell Labs was back prior to divestiture, up until the mid 1990s.

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.


This sounds an awful lot like research at a university. It definitely has it's strenths and weaknesses. Some labs collaborate more than others. Some feel like islands in the ocean, while others feel like a townhouse in the city. Some labs are poor and a few are incredibly wealthy. All of them seem to filled with hard working interesting people.

similar to SRI currently as well.

Multi-divisional form (MDF / M-form).

https://en.wikipedia.org/wiki/Multi-divisional_form

Usually contrasted with unitary form (U-form).


I’d say Apple is structured substantially less like a bunch of different companies compared to one which is explicitly split into separate SBUs.

Yep, I have noticed this about project managers too.

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 key characteristics of a good PM I'd identify are intelligence and memory.

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.


Would echo your sentiment that the role of project manager, product owner or whatever they're calling it these days needs to be rethought. In my org we literally have a squadron of these individuals which leads to bickering and an in-cohesive product experience.

My issue with the two “PM”s I interact with the most:

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 used to see things the way you do.

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.


Your experience meshes with mine perfectly.

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.


project manager are there to free devs mind from various distractions.

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.


Project managers are very useful when there are clients and budgets to deal with, as in outsourcing and contracting shops.

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 definition of PMI on what is a project: A project can be defined as a temporary endeavor undertaken to create a unique product or service.

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.


I think the issue is that we call it project/product manager, but what we actually want is secretary.

Micro-management has been institutionalized in much of corporate America while romanticizing "vision" without actually developing one.

So you have non-designers enforcing their personal "vision" without cross-team collaboration or user research.


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

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

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

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

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

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

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

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


> 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.

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...


> I've still not quite cracked what's different about Apple culturally that they seem to be more immune to this problem.

... 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]

[0]: https://news.ycombinator.com/item?id=21218413


I'm not sure you're talking about the same "this problem" as the thread you are replying to.

I took that as the "secret FAANG".

Apple definitely has PMs but they work differently than they do at most other companies.


Likely a direct legacy from the Steve Jobs days. When you have a CEO with such a strong product vision you don't actually need product owners/product managers any more other than to fill in the details. Those are still super important, but if you got those wrong it wouldn't pass review anyway.

Just to offer a different perspective: An employer having too clear of an idea of a role can also be a red flag.

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.


This is a huge factor in early hiring success: can you effectively hire people whose roles you don't fully understand? Can you develop trust with the person you've hired and delegate effectively?

Role clarity issues during an interview feels like going on a date with someone who doesn't know if they want to be in a relationship, or would rather adopt a parakeet.

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.


Oh, I am going through that. I started as a Python Sr dev a month ago, now I am handling server which is not my expertise. They are going down, deployment pipelines are not working, when I mentioned several times, my superior answer is "You are becoming a devop ;)"...

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)


Just consider it getting paid to improve your resume. Whether this project is unmaintainable won't matter when you've moved on for you 20% raise at the next company. The one you're currently working for will never give it to you.

- voice of experience -


Ha, thank you! Yeah, I am trying to remain positive, thinking that this is an oportunity to learn, etc. But at the same time i feel responsible if this fails :-/

I tend to feel responsible too, but just like, "none of us is as dumb as all of us"; teamwork ensures that your hard work can always be ruined by someone else's incompetence.

You get used to it...


While it's a great perk to be able to work on what one is most passionate about, while on the clock your focus should be to apply your skills, and learning time, to bring the most value to your employer.

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.


It can be great if you have things you want to do that most companies don’t come up by themselves.

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.


I enjoy this, the problem is often that key people don't actually want to change, or the core issue is somehow intractable.

Story of my entire 25 year career, right there.

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.


> I've turned down numerous offers because when I asked what the specifics of my day to day job were going to be, the answers weren't clear.

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..


That's because FAANG has a hiring department, that's responsible for hiring. They also each have ~2,000 engineering teams, some of which may or may not have headcount. And once someone is accepted, teams with open headcount look at that person, and make an offer.

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.


Sure. I mean, I get the reasoning/justification behind it. But I'm generally not interested in jumping through all of the toxic tech interview process hoops without first knowing what's at the other side; I've learned that lesson the hard way. And I think that probably filters a certain type of talent away from FAANG companies.

What's on the other side is generally above average pay, and access to ~2,000 teams, many of whom are doing very different things, that you can make a lateral transfer to relatively easily.

Yeah and that is what I mean when I say that the company is pushed forward not the work. You're buying in to the idea that you'll be paid well and that you'll probably find something you're interested in. My personal preference is to find something I'm interested in first, and join it. I'm more motivated by the team, work, problem, impact potential, etc..

I work at Google, and it's definitely true that when you're interviewing here, you should be thinking more about the company than a specific team. I mean, ultimately specific teams matter, but transferring is generally pretty easy here, not to mention common.

Can't speak for FANG, but that's certainly not how Apple works.

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.


That sounds about right. FAANG companies usually need generalists because teams are so big and scopes shift often enough that the ability to pinch hit becomes an important trait. Or if they need specialists, they usually need [company]-flavored specialists, which you can't be if you didn't come from internally.

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.


FAANG companies need specialists not generalists. Being large companies, they have groups of people to work on dedicated aspects and technologies. Employees can have a very narrow and specialized focus.

You're both correct! A company like Google hires both generic SWEs, who are hired without a specific project in mind, and super specialized roles like (say) wearable hardware integration engineer, who are hired to fill a very specific niche.

The product they're working on might be super specialized, but oftentimes the skills needed to do the work might not be.

> They just want to hire top talent and figure out what you're working on later

FB reached out to me twice with a specific project and position proposal (SWeng/lead). YMMV


Without getting into specifics, I've had two higher up referrals at FAANG companies, for people asking me to join their specific teams. Both companies are ones who tout the ability to move laterally very easily. Both times, I went through the generic tech hiring process (as in, it had little to do with what I was being asked to do as a member of these teams), and both times, the end result was that I was unable to join the team I was referred to join.

I get that Microsoft is a huge company but the inconsistency in quality is something I find quite comical.

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".


I've resorted to trying to figure out the shortcut names I can just type into the win+r prompt to get to a certain submenu.

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)
I recall being able to access a sub-page by adding something after 'ms-settings:' but I haven't yet figured out how to discover the names of the pages.

It’s a limitation of the phone-style applications where only one instance of a program can run at the same time. I think they addressed it in later revision of the framework, but that some people considered that was an acceptable solution on desktop shows how bad Windows have fallen from the 7 era.

It seems every update that the Sound control panel is harder to get to quickly, yet that panel still has functionality I need on a day-to-day basis. I'm willing to bet that the person who created that control panel no longer works with the company...

I am amazed when I see older style windows pop up alongside the windows 10 styling.

As am I, because the older style settings windows tend to actually be able to solve my problems.

What truly blows my mind is when the same settings are scattered among four different windows. See: Anything to do with sound.


Seconded - with the whole WFH explosion sound is one are where windows needs improvement.

In the old days billg / Balmer would have shouted at people until this was fixed


> Role clarity is a huge one in my book.

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

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

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

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

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


The empire building thing is the worst.

"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.


The only place I actually encountered this was at a defense contractor where if you did not have clearance, and they didn't happen to have uncleared work ready to staff, then if they wanted to hire you, they'd have to have you do nothing for 6 months while your clearance went through. All other companies I've worked at (including FAANGs) have always had 3-10X more unstaffed work than they could possibly do with their current staff and always had something for new people to onboard into. We'd be constantly giving leadership the bad news: "We'd love to do projects A-G, but only have enough people to do A, B and maybe C."

> Role clarity is a huge one in my book.

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.


> 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


Anec-data: Turned down an $800k Principal ML Scientist job at a FANG. Interviewed with a director who couldn't answer what I would be doing / working on. Facebook is notorious for this, lots of friends get absolutely eye-watering salaries to sit around and provide 1% lifts on click-through-rates. Most fortunately leave after the 1-yr vest.

> Anec-data: Turned down an $800k Principal ML Scientist job at a FANG. Interviewed with a director who couldn't answer what I would be doing / working on.

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.


It was a re-neg situation. I had accepted the offer, then was in talks with the director who recommended me. Unfortunately I can't say much more about that situation due to NDA.

IMHO hiring engineers to hyperoptimize advertisement platforms is a bit wasteful.


In the early part of this year, whilst on the hunt for a new job, I had the fortune(?) to interview with a FANG company (the company in question was towards the start of the acronym). They approached me, badgering for a CV (three times) and an interview, not me chasing them. And I didn't use a headhunter/outside recruiter.

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.


This is not credible, sorry.

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.


If you say so. I have nothing to prove to you and have no desire to do so. Even if I showed the email you'd claim it's fake or whatever. And I am not going to show personal email to some rando on the internet with a throwaway account simply because they question the veracity of my statement. TO be blunt, I really don't give a flying monkeys whether you believe me or not.

Late to comment, but thanks for sharing this anecdote.

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.


I would not consider myself a junior developer, or even mid-level at this point, but an offer letter with $110K salary (which I assume was total comp because there was nothing else mentioned in there) is less than what I was making 20 years ago.

Something seems off in this story. $110k base is less than the entry level salary for FANG https://www.levels.fyi/SE/Amazon/Google/Facebook

I am sure there is no evidence that I can provide, or am willing to provide, that will convince you otherwise because... "levels.fyi!"

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.


A recruiter drops an interview on my calendar; I go where I’m told. Most likely the role has nothing to do with me or the people/projects I know firsthand. If I knew about the project I would tell you, but I don’t.

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

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

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

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


What are good answers to your question that you have heard from hiring managers?

As someone with 20+ years in the experience, red flag #1 for me is being expected to go through a skill-testing technical whiteboard (or similar) coding exercise before even having a deeper discussion about the role and whether there's a fit, etc.

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.


After being on both sides of the interview situation for quite a while now, my feeling on this is more nuanced.

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.


This is really why I use the 'easy' type questions (some variation of fizbuzz or something simple). A senior guy will crank it out in 5-10 mins. I then ask a question or two on how to improve it and a mini walk through of what they did and why. I also make it clear I sometimes get people who just can not do it but have the resume chops for it. I then usually spend the rest of the time digging on previous techs they have used, problems solved, etc.

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.


+1 for fizzbuzz. It still amazes me how this simple little test can often weed out a largish portion of candidates early on.

I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something everyone can grasp but it is not something everyone knows about. Plus it is easily looked up and gamed. I try to pick something that has a few if conditions and a loop, which is what most people do. Bonus if it can be a 'refactor' style problem for the small walkthrough afterwards. But it is not necessary for that. If I were to make one up right now I would say something like 'given a string reverse the first half and move the second half to the front of the string and return the result'. There are enough little gotchas there to see if they have a feel for what can go wrong and loops and ifs. It also has an advantage that it is not easily looked up on the internet and pre-studied as fizzbuzz has been codegolfed on some discussions. The downside is it would probably burn a lot of time. So you need to budget your time with them accordingly. If I can talk someone into it I try the test out on them beforehand to see how long it would take. I want it to be quick. I just want someone who is competent and can explain what they did and has some relatable experience and can explain what they did there.

One of my goto fizzbuzz-like variations is windowed mean - how would you implement a class with a method accepting and returning a number, such that the number returned is the mean of the last 100 numbers the method was called with.

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?


That kind of math is fine. The mod operator is not one that everyone uses but add/sub/mul/div is something most people use all the time. It is why I avoid mod in that situation.

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.


I mean, "is x divisible by y?" is only one aspect of fizzbuzz, and something that can be solved in many ways - you don't have to use the mod trick. You could write a function that uses a loop and subtraction to do that bit, if it comes down to it. If I just want to see you can code I'll take it and move on, and if I'm at a point in the interview where I am looking for something else then that's a conversation starter.

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.


thats fair

This is true. I interviewed someone for a senior eng role the other day and when asked a couple basic CS questions that were not simply trivia, the candidate fell apart totally. Like asking basic DB questions to a DBA candidate, or asking basic web/css/html questions to a frontend developer. They immediately went to the back of the line.

Please share the questions. I always find it amusing that tech types seem to believe their idea of “basic X knowledge” translates across the board. I think it’s this attitude of “oh you don’t know what I think you should know” that proliferates the industry that is a major part of the problem. How do you handle folks that don’t have even the most basic form of formal “CS knowledge” but can still ship product? Do you just dismiss them completely over being able to have a water cooler talk about O(...) and some algorithm someone would never have to implement in that specific context? Seems like a premature optimization to me.

+1 Very well said. I've actually experience this first hand while interviewing for one of the FAANGs. I have a background with embedded software engineering, working with C/C++, and working with low level I/O and bare-metal + using RTOS, and also Unix/Linux, and the position I was being interviewed for was for an "Embedded Developer." The job description described the role working on their RTOS. During the phone interview, the interviewer asked a question that (later I found out) can only be solved optimally using splay trees or red-black trees.

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.


Yes, please share the questions.

Here's the funny thing. I've worked with recruiters where the candidates they supplied needed the tech screen upfront and recruiters where the sell call upfront was useful.

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.


> This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot.

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.


>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.

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.


I think a big problem is companies and in house recruiters who reach out to experienced/settled engineers and first thing they want is send you through some hr / tech quiz pipeline. No. I need to hear what this is about and if it's something I'll bother jumping through hoops for. Your recruiter's quick calls are not cutting it and that is not the same as "applying".

Honestly, I question most interviewers ability to evaluate someone as low or high skill. I honestly don't think the testing works most of the time.

If you really believe so, then I think you are failing to grasp how low "low skill" truly happens to be.

Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved.

Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.


My whiteboard coding interviews now mostly consist of asking someone to write a for loop with one state variable. That's my bar for low skill. If you can't write 6 lines of code in 45 minutes with one loop and one variable, then you and I are going to have problems working on logic problems on a whiteboard on the actual job.

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.


I'm only 90% sure I know the syntax of a for loop in my chosen language, C#. The reason for the missing 10% is that I never write this syntax.

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.


Yea I meant a for-each loop.

I'm not sure the last time I wrote a for loop that wasn't for-each.

I felt this way too until I was made to start giving interviews. However low a bar you're imagining, I assure you I've seen "strong on paper" candidates who failed to meet a lower one. I don't know if people are lying, or people cheated through school, or talked other people into doing their work at the jobs they claim to have had, but it's really astonishing how unable to write code they can be.

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.


I was going to write a similar comment when I saw yours. We've recently hired someone who was great on paper, was adept at talking about software/programming and was able to present some code he allegedly wrote and explain it. He seemed like a great fit based on the discussions but we hadn't actually given him a whiteboard interview.

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 am constantly surprised at how many Brillant Paula Bean [1] developers are out there successfully interviewing, getting hired and BS-ing their way through jobs. I've always wondered if this is as prevalent in other industries outside of software.

1: https://thedailywtf.com/articles/The_Brillant_Paula_Bean


I don't know how many people saying otherwise would constitute sufficient evidence in your mind, but add me to the list of people that disagree with this sentiment. I've had candidates who couldn't code a loop. Not "did something suboptimal", I mean literally couldn't write a single line of code.

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've frozen in interviews and been unable to think on simple problems just due to anxiety (which I've never experienced at work; if I can't think, I just say, "let me think about it" and I get back to the person in a bit). Other interviews I've completely demolished - solving problems that were supposed to take 30 minutes in 2 minutes, for example.

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.


I'm 100% sure I've come off in a couple interviews like one of those "phew we dodged a bullet there, guy can't code at all" stories. Meanwhile actually I can and many employers have been very happy with my ability to do so, and I've had a long and reasonably successful career.

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.


Exactly. Yet if you listen to HN you get the impression 80% of the industry can't even do their job. Yet, if that were the case how the hell are they hiding that from their current employer??????

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.


> 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

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.


I suspect some significant percentage of applicants may not have a disability, exactly, or always totally flub an interview in this way, but may do so often enough that it looks like the level of competence in the industry is much lower than it actually is, if one is taking one's personal experience with interviewees as an accurate measure of that. Add to this that assuredly some of the people confidently complaining about how 90% of their applicants can't write a for loop overlap with the ones generating complaints from applicants that some interviewers are themselves incompetent and asking broken questions (I guarantee you the people doing this think they're great interviewers and getting nothing but signal from their process, and they're probably also likely to exaggerate stories when relating them), then factor in a real tendency to take a 90% OK-to-good signal in interviews and practically forget it happened, taking the 10% bad as more accurate, and I think it's highly plausible the state of things isn't nearly as bad as some believe it is.

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.


I don't think it's 90%. I'm saying there is a very, very low bar, but I would say it's hit by 20%-30% of candidates that reached me, not that many. Obviously this depends on much you offer, whether HR prefilters, and the like. But this is not 90% of candidates, I think.

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).


I wholeheartedly agree. Note that my second example was exactly that type of interview - we leave the candidate to code alone, technically sometimes in the same room as us but sometimes in a separate room, but either way with only a few "check ins" every 15-45 minutes depending on how things go. They have internet access, a base file and console session open that can run the file, and an editor already set up (not necessarily their editor of choice, though we've had people install an editor at the start of this process).

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.


Everyone experiences stress on an interview, and thus may not be able to solve "do you know it" problems that he would have been perfectly solved after a better night's sleep. That is not the problem (we call them "happy idea" problems around here). I really dislike being asked this type of problems and I also dislike asking them for these reasons. Despite the fact the positions I've interviewed for you end implementing "pure data structures" much more than you end up implementing business rules (we build software for engineering: simulation, optimization, etc.). So imagine how low I set the bar between my colleagues.

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.


I think my daily driver language (Ruby) has become so ingrained in my mind that it's written out of muscle memory in Vim, and translating that direct connection from thought to Vim into a whiteboard might actually be challenging. You almost never write for loops in idiomatic Ruby anyway, you use an iterator chain.

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.


Even if your IDE would type your entire programs for you, you would still know the syntax of the language just because I am 100% sure you have actually read more code than you ever wrote. And do note that even in C there is not a single official loop syntax -- a while (get_next())-like thing is a perfectly valid loop in C. All of them valid answers -- I used the word "sequence" and not "C array" for a reason.

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?


> Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved.

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.


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

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

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


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

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.


In my case I failed at fizzbuzz because I was interviewing after spending a full day merging 2 versions of dbdumps into one, while getting rid of duplicate entries/foreign keys, etc. I could still do a pseudo code version of it, but I couldn't remember modulo function. At all.

Sometimes it's easy. We had a candidate who looked good on paper and sounded good in person. When it was time to start the screening test he asked to go to the bathroom. And never came back. We took that as a red flag.

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

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


> I will interview at the very least 50 candidates.

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.


If you're interviewing 50 candidates, your process is horrifically broken. As soon as you find an acceptable candidate, hire them. They don't have to be perfect; no hire will be, no matter how much time you spend. You're wasting company time and money.

In case you're interested, there's a bit of mathematics related to this. It's called "The secretary problem" [0].

[0] https://en.wikipedia.org/wiki/Secretary_problem


Thanks! I've seen this before but forgot what it was called.

I am reading this correctly a short list of 50 for a single role?

It’s completely insane if they’re interviewing 50 people per role. The filtering process is entirely broken if they’re doing that many. The most people I’ve ever interviewed for a job is 7.

Do you have some context around that number? E.g. are you in a large company that pre-filters the pool for you?

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!).


7 was at a large enterprise software company. I don’t remember exactly how many phone screenings they did, but it was less than 20. I still thought it was too many.

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).


> You don’t know what you want, what the job really is, the or application process isn’t properly structured.

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.


It's possible they're including phone screens/interviews there, not 50 total on-site interviews.

If it was 50 phone screenings, that’s still way too many for a single role. Everywhere I’ve worked, it’s been narrowed down to maybe 10 calls and 3-5 candidates. I can’t imagine who has the time to waste on 50 calls to candidates.

Yeh going through 50 cv's to get a long list is fair enough but actually phone screening 50

I see a lot of comments asking for clarifications on the numbers, the process, and what is being tested during the interview.

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.


> 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.

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.


I've been a software engineer for over 6 years and I still have to do 20+ interviews.

One thing that's funny is when the internal recruiter for company X (that I had to google) reaches out to me and sets up a call. Then their question is why did you choose this company specifically? And I'm like dude, you called me!

Classic. I had a similar thing happen a while ago. US based company - not named to protect the guilty - wanted me to move to the United States to do some pretty specific work for them. I'm not open to such offers but they went out of their way to make the invitation, offered to fly me out there and a whole pile of other buttering up bits and pieces. So I said if they wanted me that badly, could we do this remote?

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.


I always love getting a question about "Why are you interviewing for this position?" and replying "I got an email from your internal recruiter".

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".


Presumably you don't schedule an interview every single time a recruiter contacts you, so there the question is more of "what made you say yes to interview with us?"

From my experience that answer also means you won't be going forwards so it's just a waste of everyones time. I guess you're supposed to feign immense interest in this cold-call interview.

Yeah that just drives me nuts. If you're recruiting, you're trying to sell me on the position.

Imagine if we did this for other things.

"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?"


Hilarious. There's a car salesman joke in there.

There might be legal reasons (taxes, employment laws) that are too much of a hurdle for them to allow remote work from another country. I've heard estimates of 10s to 100s of thousands of dollars to set up the necessary structure, not to mention the months that the process will take.

One company a long time ago had an insane HR department with a question like "If there was a different company with the same salary, environment, culture, work as this one (but wasn't this one), would you want to work there?"

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


I get 2-3 recruiter emails per week. That's ~10/mo or ~100/year. I respond to 5-10 emails like this in a year. Out of these 10 only 1-2 will result in an actual call. So they would be completely justified in asking me why I chose their company out of 100 that wanted me.

I think this viewpoint is common from senior engineers but not entirely merited.

(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.


L7/L8 positions are comparable to the director of a department with 100+ people underneath in a large company or the owners/executives at a smaller company.

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.


There are different ladders with different hiring expectations (e.g. SWE and Eng manager). Regardless, a lot of leeway is given for code rustiness at these levels, but design skills are still important. Algorithmic skills are often still required (e.g. imagine you are hiring a senior dev into a Search Infrastructure group, do you want them to be rusty on algorithms?).

> (e.g. imagine you are hiring a senior dev into a Search Infrastructure group, do you want them to be rusty on algorithms?).

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 have to head out for a bit, so can't write much, but I don't think we actually disagree. The point I was making is that in this organizing of the interview process we need to put figuring out whether there's a potential match before proceeding to the confrontational 'testing your skillz' phase. Otherwise we're just wasting time.

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.


This could be a side-effect of how separations of concerns are handled vis-a-vis interviews at the company.

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.


If companies want to hire experienced senior talent, then streamlining isn't going to be a good idea. They need to recruit them, and that means not alienating them right away.

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.


> If companies want to hire experienced senior talent, then streamlining isn't going to be a good idea. They need to recruit them, and that means not alienating them right away.

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?


Why would you want to work for a company which has only those desperate-enough-to-jump-through-hoops applying to them?

People who apply to Google aren't desperate.

People already know Google exists and whether or not they want to work there. For most people (projecting here) the only recruiting Google has to do basically comes down to: We think you're good enough to have a chance.

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.


I get it. We all want to be shown respect and courtesy. And how we and our team treat candidates is a reflection on the company; regardless of how accurate it is.

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.


I'm a hiring manager and I start our technical interviews with coding problems. I have seen too many candidates who can't write code to ever be ok hiring someone who I haven't seen write code with their own hands.

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.


You have set up a strawman -- I didn't say go hire people who haven't seen code, I didn't even say don't do skill testing questions. The question is: at what point in the interview process do you start dumping skill testing questions at them? And I think as the first gate to pass, this is just awful.

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.


I did address your question - I ask them to write code first. It may waste your time, but it saves time for my team. You can't code? Ok, the interview is over. Thanks for your time.

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.


It's also super awkward to talk to someone and get a real good understanding of their experience, how they fit, what they've done, what they'd want to do.... and then find out they can't code. And this does happen. It's much nicer for all involved to do that early in the process and write it off as a formality because it's a humiliation to throw that at someone at the last minute. It's an insulting waste of time for any decent candidate, but there are always candidates who can do everything but code and you have to weed those guys out.

And from an applicant's perspective, I actually prefer getting the coding part out of the way up-front. It allows me to relax for the rest of the interview and just "be myself".

Found the person letting good candidates slip through the cracks. I literally just rescinded my application from a place when given a far too-open as far as choose-your-own-stack take-home assignment. I chose one very, very popular library that had unbeknownst to me, been slightly broken for some time. I fixed the library instead of doing the assignment and submitted an upstream pull. The recruiter's response was something along the lines of: "well, if you're having trouble completing the assignment, maybe you're not a right fit." I verbally handed the recruiter their ass, something more people need to start doing, and walked.

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.


On the flip side, I've been interviewing people with supposedly 15+ years of experience using simple whiteboard questions for a while and I've seen too many people fail miserably at writing basic for loops (a very slightly more involved problem than fizzbuzz, really) for me to simply trust that spending time selling you on the company is useful. Lying on a resume is easy, and even truthful resumes can be misleading. Screening candidates with a half hour of simple coding gets rid of a lot of people who seem to be making money without actually knowing how to write code, which is a problem when you're hiring people to write code and help others write code.

I've seen the same thing. I hire a lot of embedded engineers and when I need someone that has solid experience with drivers and bit-level work, I'll ask a simple question to start off. In the past I've never disclosed the question, but why the hell not now. I didn't write it anyway:

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.


What is a single inline math statement?

!!(n & (n >> 1)), I assume.

Bonus points for the boolean sanitation!

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”...


Heh, I'd accept it. In screening I used to ask them to implement an isOdd() function for an unsigned int, and after they did it (never had someone fail) see if they could come up with alternate ways. Mainly to see if they're aware of bitwise operators, though it's nice to see they can write loops too. It wasn't a fatal flaw if they weren't (it would be if they couldn't solve it in any way), but knowing is better than not knowing. Anyway one person who didn't know nevertheless amused me by doing a conversion to string and checking the last digit.

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 solution gives you an answer if there is “at least two”, not two exactly?

However I understand that may be part of the discussion afterwards.


Like I mentioned above, most of the time it never got that far. Candidates were messing with string handling and converting base-10 integers into binary (not understanding that the machine already had the integer represented in binary)

I'd fail fizzbuzz on your whiteboard. And I'd be proud of it. Working in this industry for 25 years and almost 10 at Google has not trained me to write fizzbuzz.

I have to wonder if you know what fizzbuzz is. It's not your typical Leetcode question where you need to know algorithms, etc. It's a lot easier than perhaps the easiest Leetcode problem.

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.


> It was designed as "This is one of the simplest possible programs one can write.

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
I fault fizzbuzz a bit, because there are candidates in that last category who have several years of experience successfully duct-taping together libraries to meet product requirements, yet panic because they've never had to find the remainder of division in their language of choice. They might be fine for the rec you have open.

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.


I'm sure there exist jobs where its OK not to know that a mod operator exists, but none of mine were of those kind. I'm pretty sure my experience matches the majority by a pretty large margin.

> 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.


> this is a whole order of magnitude more difficult than FizzBuzz

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
You are correct that accounting for floating point would make this more complicated than fizzbuzz.

> 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.


It's even easier to do it with the inclusion of non-integers, though - `prod = a / (1 / b)`

Granted, that may be counter to the spirit of the question, but it's a valid answer lol


When I'm interviewing people I'll ask a fizzbuzz level question. Not fizzbuzz itself though. I'll pick something that just has them doing some basic operations with strings and arrays like reversing the words in a string.

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.


You don't need to use the mod operator to do fizzbuzz.

Fair enough, I was being inflammatory in my response. I would not fail fizzbuzz.

But I'd probably want to, just to piss off this person (the throwaway account who came on here to argue...)


I'm not sure I even believe you. Maybe you would refuse to do it because you don't want to, but you've spent 25 years as a successful developer and you can't write out fizzbuzz on a whiteboard?

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.


You shouldn't believe me, I was being flamey, and yes, I would probably refuse to because I wouldn't want to without being properly told why it was worth my time, which was the point of my original comment.

I find it kind of shocking that you are a senior engineer at Google and are unable to write fizzbuzz.

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).


I work at Google, and don't know anyone who'd struggle with Fizzbuzz.

That's an extraordinarily simple coding problem, and the usual ones you have to pass to get into Google are much harder.


I never said I'd struggle with fizzbuzz. I said I'd struggle with fizzbuzz on _his_ whiteboard. Because it would give me anxiety to do it there in front of him, and it's not how I code or think. And this is a person who created a throwaway account on HN just to get into an argument, so I can imagine how the experience would be.

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.


You'd struggle to find anyone in a freshman CS class a few weeks in who'd fail Fizzbuzz, excepting those who weren't going to last more than a year or two before switching majors and never coding again.

Which part of fizzbuzz would be an issue for you?

Writing code on a whiteboard like it's a test or a competition, without being able to sit down in my editor of choice and calmly think it through and trial and error.

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 have to sit down and deeply think about a question like fizzbuzz then as an interviewer I'd be a bit concerned - this is a quick check to make sure you're basically competent, not architecture of a critical piece of infrastructure.

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.


> 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.


I thought google does leetcode/whiteboard questions . How did you get in without being able to write fizzbuzz.

Not sure if you are trolling.


Like, on purpose? If you know what fizzbuzz is, then you can probably whiteboard it. It’s literally:

``` case $input when $input % 3 == 0: “Fizz” when $input % 5 == 0: “Buzz” when ($input % 3 == 0 && $input % 5 == 0): “Fizzbuzz” end ```


You failed to return the numbers that are neither divisible by 3 nor by 5. Also I'm pretty sure your code will never return "Fizzbuzz", since 15 would already be matched by %3.

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.


Fair enough!

Most companies I've interviewed at allow me to chat with the hiring manager first to get a sense of the role. If they're looking for someone super senior like us, you just need to be upfront about what it would take for them to hire you.

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.


It's largely a symptom of having mostly new grads do the interviewing, and favors new grads getting the positions, so around it goes.

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'm with you on this. 20+ years. My usual MO is to walk away from interviews that have jump-scare whiteboarding or require a quiz prior to an actual interview.

I recently broke my own code at an interview and was rewarded with complete nonsense. Never again.


My new rule after my last job search is that I don't interview if I don't know enough about the interview process to be more than 50% certain I'll come off OK in it. Not that I'll get the job, but more than 50% certain I'll at least look alright.

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 FAANGs practically (sometimes, actually) give you a study guide, at least.

The study guide is hundreds (thousands?) of pages. How is that helpful?


Yep, I agree with you 100% and as I said before I think companies looking to hire are doing themselves a disservice by not paying attention to this more. A grueling day long interview to get into Google is/was worth it at least from a monetary compensation POV.

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 have a feeling that most positions like that are filled through networking and word-of-mouth if not from internal promotion. Not many companies who want somebody like that are confident that they can determine if they really are that skilled in an interview. And not many people who have jobs at that level already have much interest in the usual rigamarole of most technical interviews.

I suspect the reason they get away with it is because for most of us it's not that stressful, especially if we already have a reasonable job. For some it can even be fun, a diversion from the usual day to day. The companies that want you to spend 8 hours doing a side project for them, though, yeah that's going to be a no for a lot of non-desperate people...

I get the feeling a lot of this is cargo-cultism: I.e. people want to work at the kind of place which only hires geniuses who can dazzle with their real-time problem solving, but they don’t actually get the reasoning behind such an interview

The funniest part of this I've found is that in the rush to replicate FAANG white board interviews most companies end up with poorly thought out questions, with interviewers who are rushed to prep meaning that the question often contain technical errors and the interviewers can barely solve the problem themselves.

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.


People lie on their resumes.

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.


Nothing like the emotional appeal of invoking Godwin, but here we go. Wernher von Braun was a literal Nazi of the brutal kind, but when you are in a race to develop ICBMs, things like "culture fit" are suddenly irreverent.

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.


Offices that lead with (or even only use) algorithmic questions are either places you know the name of, or they aren't high quality places. That's my rubric.

"But! But! Our 24yo interviewer has gotta check if you know the _fundamentals_ ... You might have been coasting for 20 years."

Agreed, I'm totally confused and put off by this as well.


I've seen too many people who clearly have been coasting for 20 years (or people who are simply applying to a position that's not actually aligned with those 20 years of experience).

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.


A lot of people do in fact manage to coast for 20 years.

I think you are arrogant.

It's possible. I try not to be. Arrogant people piss me off.

Whiteboard coding in an interview is a performance anxiety test and hazing ritual as much as anything.

"Not Enough Clarity about your Role" - Like the author mentions, this can definitely signify that the role is not important. The other thing I've noticed over my career is that it could be that the role involves "grunge" work (awful oncall shifts, doing backend work when you want to do only frontend, etc). Companies hide behind cool titles/department names/etc, promising whatever you want to hear to get you in.

As someone who's never taken a traditional role until after devops got defined as its own role separate from dev and ops, my advice is to figure out what grunge work you hate, and what you don't (or at least, hate less) so you can specifically about that. Like household chores, different people hate different things. Some thrive in operational chaos, others can't handle having more than one plate in the air at a time. Some loath building frameworks and others can't stand building anything but.

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... )


Or you are interviewing "for the company" (e.g. Google or Facebook). While it fits their processes, it's always seemed a way to create and reinforce lock in.

"lock-in" of _____ to ____ ? Do you mean making it more difficult for the employee to eventually leave / how?

Branding has its power over certain people.

IMO it's not really 'not important' as much as 'not honest'.

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.


You're probably right that sometimes people are hiding something from you. But I think a lot of the time it's more like "I have 10 people doing a bunch of things that vary over time and on a day to day basis, and what each of them does specifically really depends on what they are good at and what comes up. I really want those 10 people to be able to do 10% more of that confusing mix of activities than they are currently doing. So I guess I'll hire someone new."

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.


Yeah I don't think of it as 'deceptive', but more so just not through through or even clearly sharing what the situation is.

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.


This definitely describes our R&D group.

>Someone, somewhere at that company chose to hire someone... and they know what they want them to do. Why aren't they telling me?

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.


The "Not Enough Clarity about your Role" issue has killed Google with so many potentially outstanding employees. For years and years you wouldn't interview with your team, or even be told what team you would be joining. It is slightly better now, but you still don't interview with your specific team until very, very late in the process, if you even do.

One of the worst things about interviewing at the big G.


Part of that is because of the expectation at Google that you will just move around. You don't really hire specifically into a given team, and that could be disconcerting, for sure. But you are also given enough respect by the company to assume that as a competent SWE you should be able to move around fairly easily to almost any team in the company.

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.


Doesn't that put off a lot of very high-quality candidates though? If someone joins because they want to work in an interesting machine learning team, they probably don't want to be potentially moved on to a legacy Java CRUD app. Or is transferring determined more by what the employee wants?

1 point by kinkrtyavimoodh 0 minutes ago | edit | delete [–]

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.


The latter. You transfer to where you want to go. There's an internal listing of open positions, but there's also word of mouth. Assuming the team has headcount and you get on with the manager, it's usually not hard, and doesn't take a lot of effort.

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.


Employees usually get to ask where to go next, and the expectation is generally that you spend at least a year in a position.

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.


Unless your job is going away, transfers are determined by what employees want.

There are downsides to team specific interviewing. You can have situations where the team is desperate to hire someone and so they subconsciously lower their bar. It also leads to a less standardized interview process and introduces more bias in the process. The downside of course is you may not get the best person for the specific role/team.

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.


To be expound on "very, very late", interviewing with your specific team is done at the end, after passing the on-site, and there's a soft offer from the hiring committee. The last step is to get a team match where the candidate talks w/ teams' manager, and both the candidate and manager have to agree to the match.

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.


Some of my hall of shame interviewers:

- 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!).


Why hall of shame? 2 and 4 are top mates.

I once had a manager try to hire me back from another position:

'Look you will be overworked and underpaid, but you will get to do really cool hands on things here.."

I appreciated the honesty.


Had one where they did a bunch of interviews with me in the same conference room. The job was in Foster City , so a pretty high CoL area. Whiteboarding, bit of code, etc. My manager-to-be then left me in the room for a phone call with HR about salary. The guy on the other end said that the salary was $50k, no negotiating. I turned then down, of course, but then was left alone in the conference room. I wandered about until security came and found me when I got stuck in an elevator with no RFID pass to let me out.

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.


These are all very good reasons why you want to talk to your future team mates, rather than to HR and some manager. The team mates are the ones that you will be working with every day, the manager you will likely see once or twice a year and HR you will only see when there is a problem (or when they perceive you are a problem).

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.


Hah! I have witnessed both #1 and #2 at a very electrifying company that gets a lot of mileage on HN. Big shout-out and thank-you to my interviewers who saved me from a potentially big mistake!

I can identify with the red flag where they try to pressure you to accept the offer in a short period. This is also called an exploding offer. I had a place do that to me and I ended up turning the opportunity down.

I have done the same when I was about to graduate and started looking. One company started the process long before the others (which all basically followed the same schedule), and gave me an offer before I even had applied to anyone else. At the time I was very afraid of missing out, but the way they gave me only a few days to think about moving to a different city almost a year ahead left a sour taste in my mouth and made me turn them down.

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..


My spouse works as a career counselor at a university and students often end up with exactly this problem. Many of them come to the solution of accepting the less favored offer and continuing to interview, and then reneging on the company that made the exploding offer.

Sometimes, employers will call my spouse up and complain that students have reneged and she shouldn't have allowed them to do so!


Hah! I experienced the exact same thing just a month ago. It did build up goodwill between myself and the company that fast tracked me an offer. Thus, some good came out of it.

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.


On the other hand, there often needs to be a time limit, or else they will be too late to make an offer to the runner-up (when the leader turns it down). I am not sure what a 'reasonable period' is.

A reasonable period is: You tell them up front your ideal timeline, that you have a couple of other irons in the fire (if you do), and you keep them informed of the progress of those other fires. And they do the same for you. Maybe you can't get a timing that works for both sides together, but that is OK. The pressuring is what isn't.

Right. What I found works well is "We'd like to extend an offer, but we'd appreciate a 48 hour turn around, so let us know when you'll be in a place to make that decision"

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.


I've been the recruiter in this position. I think it is unethical to string your runners-up along in this situation. You're essentially taking up their (and your) valuable time with little chance at success.

Exploding offers are the least bad solution. Give them 48-72 hours, with a small extension if they are currently talking to someone else.


If you don't like being a runner-up then you should negotiate with the candidate so that your company ends up in a more competitive position.

It's extremely hard for smaller companies to compete with the likes of Google and Facebook, who (I've heard) offer 25% more than everyone else. Which is why they end up with all the talent. Lather, rinse, repeat.

If this is a company's reason for not finding talent then the hiring team is simply not competent at hiring.

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.


I assumed that jnwatson was talking about runner-up job candidates, who are in a holding pattern until the first-choice candidate accepts or declines the offer.

Thank you.

As long as everyone is up front about everything, there is nothing unethical about it.

If your prospect isn't buying what you are selling, you need to make your offer better.


Long enough for you to wrap up your other interviews.

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.


You can always accept the time critical offer and continue interviewing and then jump if a better one comes through.

There is no reason to be nice or considerate to companies, they will drop you in hot second if it is convenient for them.


Accepting an offer without an intent to follow through is fraud. If you think your counter-party is dishonest or ill-intentioned, then you should refuse to enter into any agreement with them.

He is going to follow through. Circumstances change.

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"?


I have never been offered a contract when hired anywhere in the US -- well except for the Army. An offer letter is not a contract, often it says so in the offer letter near where it says you are an at-will employee that they can fire for any reason at any time.

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.


Unless the company is legally binding themselves to actually pay you when the time comes (as in, if for any reason they rescind the offer, you’re still paid for, let’s say, a year of salary, and this without you having to sue them), I don’t see any reason why the employee should feel any more obliged, legally or otherwise.

There is an intent to follow through when accepting the offer. Also, I'm sure you provide guarantees ensuring the candidate will actually be signed and not be quickly fired if you send out the offer letter, since sending the offer without the intent to follow through would be fraud?

If you want to play the legal game, the contract is void because it was signed under duress. Forcing the employee to sign in 24h qualifies as consent under duress, not free consent.

First, I don't care whether it's illegal; lying to people is wrong.

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.


Economic duress is recognized as duress. That the candidate is rejected from the job if too slow, having no job and no income to eat is quite a strong duress.

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.


Agreeing to provide a service on a specific date, then offering the same service to others, and withdrawing from the first agreement upon receipt of a better offer is wrong. You might not agree with that, but it's how I see things. What would you think if the companies and individuals you interacted with were constantly backing out of signed deals?

It is not a lie to accept a later offered better deal. The better offer might never come through.

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.


What would you think if a company regularly retracted offers upon finding better candidates? Opposite side of the same coin.

Companies do. It happens all the time with usually no recourse for the candidate.

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.


Employment offers in the US rarely establish contract. Employers often rescind offers that have been accepted by persons for a variety of reasons. Similar for employees.

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.


Absolutely. From one of my other posts:

> 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.


That only applies when the company needs to fill a specific position. Specific positions that need a particular person are a minority of SWE roles. In fact it is bad management to let your team get in a situation where there are individual hyper-specialized roles with no knowledge shared.

I think it also depends on the size of the company/department. A company with 4 people might be looking to bring on a 5th to fill some specific role. In that case, the offer to the second choice depends on the response to the first. On the other hand, a department with 300 people might be looking to increase head count by 10-20%, in which case the offers to each person are quite independent.

Although the reality is that a lot of hires will still be hired by a manager targeting a specific need.

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.


Even if the roles aren’t specialized, there may not be enough headcount for multiple offers to be out at once.

There is no reason to not be honest about these types of things (unless of course you're doing something shady). If you want to fill the position quickly, you should say so. Now, of course, as a candidate if I heard that I would jack up my compensation numbers, but again, if you want to fill the seat quickly that's how it works.

I know a lot of people who have “accepted” exploding offers but then just keep interviewing and will try to renegotiate or just reneg if they get a better one.

Indeed, the employee can give 1 day notice during the first month, by law in the UK.

Exploding offers are the least of the problems as a candidate.


"Let your 'yes' be 'yes' and your 'no' be 'no'"

I would personally feel uncomfortable doing this as would a lot of the people I know.


I know you sometimes gotta do what you gotta do. But word of reneging will get around and it could come back to bite you some day.

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.


I agree I wouldn’t do this. I wouldn’t actually feel bad doing this if my offer were exploding but I would worry about burning bridges. Most of the people I know who were doing this were new grads

Well, outside of Silicon Valley, if you accept an exploding offer, you will very frequently show up to work and sit around for weeks doing little while the project you were hired for goes through the project funding pachinko machine a few times.

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.


It can be a problem for companies too — candidates accepting an exploding offer and then leaving after a month when another offer comes through can be a rational approach. The first place just gets left off the resume.

I refused to accept an offer quickly twice, only to find that the place was about to be bought and I would have gotten a payout if I'd have been an employee. As a new employee it wouldn't have been huge, but still it would have been nice

Sometimes playing good poker means folding bad hands that end up winning due to random chance. If you make a habit of accepting offers due to pressure tactics, you will end up regretting it more often than not.

Sometimes they do that on Shark Tank (Mark Cuban especially), making an offer and saying "but you have to decide right now". Giving them just seconds, even when there are still other potential offers on the table.

It's a terrible dark pattern and wish everyone would just dismiss it outright. Kudos for doing so.


This.

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...


Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: