Hacker News Reader

Comment by js2 | Hacker News Reader

I would pass the shit out of this question because it's right in my wheelhouse, but I don't consider myself a particularly exceptional programmer. I have a CS degree, but I'm positive I'd fail a FAANG interview w/o advance prep. I'm really comfortable at modifying existing code[1], gluing together existing solutions, and know enough C to get through this question.

But the OP says this:

> When you’re maintaining a large codebase, there are always going to be codepaths you don’t fully understand

Ugh... I hate modifying code I don't understand. That doesn't mean I need to understand the entire code base, but if I'm modifying a portion of the code base, I'm loath to touch it till I understand what it's doing.

Also, of all the work I do, I consider this the least expressive of my ability. It's such a mechanical thing to do and doesn't require a whole lot of thinking?

So I guess I can see how this skill—for a job at your company—is necessary but in no way sufficient.

[1] e.g. https://github.com/git/git/search?q=jaysoffian&type=commits, https://github.com/google/breakpad/commit/6446cfcff088b8682b...

View on HN

> but I'm positive I'd fail a FAANG interview w/o advance prep

I work for a FAANG company in a senior position and I know I will fail FAANG interviews w/o advanced prep.

I work for a FAANG company in a senior position and I did fail FAANG interviews w/o advanced prep.

The second try I practiced.

I YOLO’d the Google interview two times. First time I failed. Second time I somehow passed. It can be done. Might have gotten a higher level with studying but I don’t think I would have ever studied.

After interviewing people for a while, I've learned how to suss out what people gain from practicing vs actual engineering instinct

I've passed people who "didn't meet the bar" because I could tell they just didn't practice, but exhibited 4 stars on every "Ultra Instinct" signal. Programming speed isn't important, correctness & habits are what are important. + or - 10 minutes to finish a problem doesn't really matter in the daily job

I've had two memorable interviews where timed coding was part of the interview, and I wowed the management team but did not get a call back due to taking about 10% too long on the coding. This is a good thing, in hindsight, considering the eventual fates of those businesses that hired like that.

It's counter-intuitive not to test for coding at an interview for a developer. But you just can't learn what you need to know, as a hiring manager, from a pass/fail timed test. This greatly informs my hiring process now.

can you say more about how you detect instinct?

Sure :)

- People will catch edge cases before they occur

- People will realize that they have an edge case, and write a failing test/trigger the failure before they fix it, and explain it to me

- They come up with an approach pretty much instantly, and their design is correct after thinking about it a bit more

- Their coding style is very functional & composable (idk why I find this correlates with success, but it does)

- They test all dimensions of variability in their inputs

- They focus on what matters

- Forward progress doesn't stop

Things that don't correlate with instinct

- Speed of implementation (within reason). Different people can type at different speeds, and people think at different speeds

- Having to google APIs

I'm a former FB eng and a Xoogler and have been an interviewer at both places. The recruiter sets the level for your interviews. There's an option for the interviewer to recommend you for a higher level, but there's no incentive for the interviewer to do so and is almost never used. Getting higher rating from the interviews will only make the hiring committee's decision to hire you easier, and almost never affects your levelling.

In my circles at GitHub and Microsoft, the interviewers absolutely had influence on leveling.

Off-topic: If YOLO and you want to join Google, wouldn't that be motivation to study?

Unless you view it as not worth the effort.

I've done two onsites with Google in the past essentially YOLOing it (I only study my interview failures because I view otherwise as an inefficient use of my time) - first time did terrible, second time almost passed if I didn't completely bomb my very last session. The second time ended up not really mattering because two different teams in two different orgs for my current non-Google FAANG wanted to hire me after onsites done on back to back days (side note: that was almost 15 hours of interviewing in two consecutive days - that's a lot of time, I only was able to do it because I was funemployed at the time).

I actually appreciate it very much if a candidate didn't study & focus more on giving the best answers to their capability when I interview them - the questions I give them are usually questions that no amount of studying would have prepared them for, so already taking the mindset of trying to respond thoughtfully & earnestly to problems & situations that change on a whim puts them a step ahead.

I studied for the interview I wanted (by being a thoughtful software engineer in my day job) and not for the interview they offered (which would require me to either be a professional leetcoder or some algo/performance expert). If they didn’t want a good software engineer then they’d have to pass on me. I made it clear in every session that I was thinking through the problem, asked good questions, and when there were aspects I could write concrete code for I did. If you score by solution competence and performance I think I aced 2 of the coding sessions and did pretty mediocre in the other 2. My interviewers must have been willing to go a bit off of the default mode of operation as I managed to get an offer.

I don’t know if interview performance has anything to do with negotiating power, but I was able to get damn near the highest possible total compensation my level allows for without a competing offer.

you already studied in college

Is YOLO’d when careless and impulsive behavior results in tragic and unforeseen circumstances?

I YOLO’d FAANG interviews twice (The interviews were in cities I wanted to visit, so why not)passed both times and even accepted the offer the second time. In the end I wasn't a very good fit for the company.

What happened if you don't mind me asking? (I might be in a similar situation lol. I just started a FANG on a team of all Indian ppl and I'm the only white dude and I can barely understand the speech much less the code)

I worked with games development most of my life and then went to web development in this change, for some reason I ended up in position a bit more senior than what I was prepared for in this domain. I thought the job would be fine, specially being my second successful interview with the company, I thought their processes meant that I was good enough for the job they offered me.

Is game development as tough regarding WLB as people say? It's always been one of my dreams to work in Game Dev but not sure if I should keep it as a hobby or give it a shot. Are there sane Game Dev co's with decent WLB?

I mostly worked on smaller studios and for the last 6 years of that career I was working in my own company, I only had WLB problems in my first 2 years, but I never worked in AAA

I YOLO'd my Google interview. I didn't even expect to make it to the on site. But I did, then I bombed.

Do any of the interview questions you had, or studied for, have anything to do with your day to day job?

I got a job as a front end developer. We had a ton of streaming data and needed to index it in the front end.

The "right" solution would be to fix it in the back end so that we didn't fetch all that data when it wasn't needed, but that wasn't possible because of the horrific project/product management.

So I had to build binary search trees to index the data so we could work with it fast enough to have a reasonable user experience.

So yeah -- you will need some of this stuff. You're constantly going to be searching for things, reversing things, looking for patterns.

it won't be so clear and abstract, as a leetcode puzzle but the reason why I had to write that binary tree was because whoever came before had clearly never considered using one and was doing everything completely wrong. It was a disaster and made the codebase insane.

If they filtered in the hiring process for people who know the basics then things would have been a lot more performant, and they wouldn't have burned so much time working around the performance issues caused by his terrible solution.

I absolutely agree that hiring folks who are aware of the basics is important -- essentially, you want engineers who are aware of the space of possibilities.

In my view, what makes folks dislike typical coding interviews is that in the real world, what you need is a solid understanding of what algorithms exist and when to use them/what to look for, rather than the knowledge of how to build one on-the-fly.

To solve the issue you described, you don't need to know offhand how to implement a binary search tree on a whiteboard. You do need to know how to identify indexing as a bottleneck, and how to broadly think about a solution. You could then search for indexing strategies and, having studied them at some point in the past, you'd be able to pretty quickly refresh your memory and find the one that's a good fit for the problem at hand.

For this reason, I've always thought these exercises would be much better off as essentially "open book" rather than real-time whiteboarding problems -- because that reflects how engineers actually work. That's also what I've pushed for in my own workplaces, and we've had good success finding talented folks, and heard positive feedback about this aspect of the process.

I would add to this that while knowledge of computer science algorithms and data structures is _absolutely_ useful, being able to implement a binary search tree RIGHT NOW, in under an hour, is not necessary for... pretty much any job anywhere.

Interesting, thanks for that.

What kind of practice did you do? Leetcode exercises or something else?

I've worked at 75% of FANGs. My method was basically just bone up on algorithms and data structures by going onto the Wikipedia list and trying to implement them on pen and paper. Practice thinking out loud, practice space management(no backspacing on pen and paper). Be honest if you've heard a question before. Know how to analyze runtime of your algorithms.

I chose to interview in python, even though I know other languages better, because it is fairly dense relative to, say java or c++ and easier to write by hand.

> Be honest if you've heard a question before

Why so?

I can't reply to the sibling commenters but providing a contrarian opinion. I'm an interviewer and there's no way for me to tell who is just really good vs who has seen the exact question before. Telling the interviewer just gives them information that goes against you so I wouldn't recommend doing this.

I always prefer to say "I've seen a similar problem before, let's see if I can remember how to solve that" or "let's see if the same kind of approach works here".

This is a balanced approach. It's honest: you probably haven't heard the exact question word for word, even if you can't recognize the differences. And it's actually what they're selecting for in the first place. They're not expecting you to invent the concept of a binary tree, or whatever, but to know it exists and how to implement it and to recognize where it might be the right concept to apply.

I've never had any interviewer say "OK forget it, let me give you another question where you'll never have seen something similar".

I was thankfully asked (in the interview, not just assuming I’d been asked the Q before).

Question was: write code to determine if the stack grows up or down. I’d been writing computer games for several years and smashed it (after telling the interviewer that it would be necessarily technically rely on undefined behavior) and the interviewer somewhat dismissively said “you should have told me someone else asked you this question” “What are you talking about? This is just an easy question.”

A good answer would be "no, but when I was working on <game title> which is a game that has to run on many different consoles including <console>, we had an interesting but where <weird stuff happened> and the stack cookie I inserted to test if it's a buffer overflow remained pristine. After a lot of debugging, at the stage where I started suspecting it's a compiler bug and inspecting raw opcodes, I was looking at my debugger and noticed the stack pointer was lower than the stack cookie address and understood this CPU has a stack that grows the other way than I'm used to".

Instant hire if I was interviewing you.

> “you should have told me someone else asked you this question”

At what point do we end up saying "my current employer 'asked' me this question, because it's part of my day to day job..."? At some point you have some experience in certain areas that you just 'know', and it's not some sneaky "oh I crammed leetcode for 3 weeks!" tactic.

Yes, it seems to me that if interviewers are going to be annoyed about this then they should stop using leetcode and/or using generic interview questions.

Red flag. People forget interviews are a two way street.

You ask a Leetcode question, and then assume the candidate is lying without even asking "have you seen this question before?".

It is an easy question for someone that understands pointers. I suspect those sorts of folks are becoming few and far between.

I guess you’re screwed at that point as now they also think you’re a liar. No way out.

I got hired from that loop. Same guy challenged my failure to write ifdef include guards on my header file on the whiteboard. My answer of “oh, you’re right; I’ve configured emacs to automatically insert those, so I don’t have to think about it” seemed to more than satisfy him and we ended up being close as colleagues for several years.

Does honesty go against you in interviews these days? I'm getting old.

It does in this case yes, how would you see it as an advantage? You have to pass X number of algo/data structure, your being honest will only make them find a different question. If you get the different question wrong guess what you are out. It is what it is.

If the hiring process is set to punish honesty, then maybe by being honest you avoid working at places with such a process and consequently with the people who passed it?

Note that I'm not saying that FAANGs are like that (I have no opinion on that).

It's not punished but it's not massively rewarded either

how would you see it as an advantage?

How would I see presenting myself as a trustworthy employee who won't pull the wool over your eyes? Pretty favourably tbh.

I am not denying honesty won't hurt, and probably would help you. But again, the interviewer is going to have to get a replacement question...you have a reduced chance of solving it correctly.

I have a question that I've been asking for years that is somewhat domain-specific, but should be answerable by anyone who knows what a set/map are. About 20% of people get past "stage 1" within 5 minutes, usually people with finance/trading experience, and some will say "oh, I implemented something just like this a few years ago." Some people take 30 minutes and do ok, and some never finish. When someone tells me they have had this problem before, I tell them it should be really easy for them then, and we can move on to more interesting things!

For those that DO get past stage one, it is a boss with multiple health bars. We talk about what improvements could be made, then what improvements on THOSE improvements. We keep digging until we are out of ideas. The best candidates are the ones that stump me, or introduce new ideas. I present this problem as a pair problem solving challenge, so there is no one right answer, and has a lot of back and forth.

The whole leetcode approach to interviewing is basically

1. interviewers asking questions that they wouldn't be able to solve 2. interviewees pretending to solve on the spot things they've memorized 3. interviewers pretending to believe them

There is no way for you to tell if someone is really good (as is) vs who has grinded leetcode since the process (which assumes prior preps) a priori discards the first group.

You assume that all successful applicants "grind leetcode". What makes you so certain?

Leetcode grinding is suggested as necessary by everyone, including recruiters (in-house or 3rd party), hiring managers, prospective colleagues. You can see comments from devs at FANGs even in this thread.

I understand that this is a common belief, but I don't agree that it is strictly true; it is contrary to my own experience, both as an applicant and as an interviewer.

Note that we are talking about a particular interview process which uses CP (Competitive Programming). This is common at FAG (Lets exclude Netflix since as I've heard they don't do it) and at companies that copycat the process. Of course, there are many other places that don't do it.

We are? What is "competitive programming", and where did it come into this thread? All I see upstream from your comment is a discussion of Google interviews and large tech company interviews generally. I don't recall anything particularly "competitive" when I interviewed at Google (or Facebook, or Microsoft, or...); they just had me solve problems, as usual.

That's the point, CP != CS (Computer Science). It is a separate discipline/subject with its own trivia knowledge & tricks. CP uses Computer Science the same way as e.g. Physics or Biology use Math. And CP problems are used in those interviews. https://en.wikipedia.org/wiki/Competitive_programming#Benefi...

I ask again: what makes you so certain? This does not correspond to my experience with tech interviews.

Again, a common knowledge, including the above mentioned Wikipedia article. Good for you if that was not your experience :)

I guess, it is okay telling your interviewer depending on your comfort level, as most never change the question regardless. That said (and as another commentator points out [0]), if an interviewer asks you call out questions you know of from before, then you most certainly should (unless you can sell the bluff...).

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

When you’re an interviewer and you’ve asked the same question enough (tens of time is plenty, really) you’ve seen it all and it’s really obvious when someone has seen the question before.

People who haven’t seen the question before always stumble somewhere. There’s something they didn’t notice at first and need to account for, their solution is not structured optimally for the follow ups, they iterate over some possible solutions while thinking out loud to eliminate them etc.

It’s honestly not that hard to tell when someone is pretending they haven’t seen it before.

As an interviewer I find it easy to catch candidates who are regurgitating a memorized answer, but catching people who know the answer in-and-out is really hard. I've had the exact same experiences on the interviewing side of the table as well.

I think interviewers tend to overestimate their ability to catch people who have seen the question before and miss on tons of candidates who are good at answering seen questions.

It's actually not all that hard to stumble on the question at predictable spots. My process for solving a question I've seen before and one that is new to me actually doesn't differ all that much: as several clarifying questions at the start to confirm I understand the problem, then write a quick-n'-dirty solution as fast as possible. In this first pass I usually don't pay too much attention to things like bounds, which you wouldn't memorize anyways even if you knew the solution. Then I run a pass to polish the solution up, present it, then think of edge cases and how I'd test the solution. The only real difference is that I very rarely pretend not to have seen a question (I have done it twice, both in situations where it was clear the interviewer was out of questions and running down a list of things from memory, and I just wanted to humor them). You'd think that I'd be more sure of myself when I actually know the answer, but when I don't actually know what I'm doing I will usually come to the answer as I ask those clarifying questions and start stating the facts that usually score "this person at least has the gist of the problem" points, like "oh this is a graph and we're doing something with distance, let's see if Dijkstra is the right thing to apply".

Interviewer here.

When a programmer goes through a question fast and jumps right into the solution, there is two possibilities. One is candidate already knows the question. Two is candidate is exceptional programmer. If the other part of the interview doesn't match up to this, then we will assume the first case.

I definitely place candidates who are being honest upfront above others. They will be reliable and trustworthy, which is important quality for programmers.

First principle that every interview guide teaches you is to take time to understand the questions. A candidate who has spent months preparing for a FAANG interview will highly unlikely rush into answering a question, even if they have seen the question before.

One reason for folks to jump right into the solution is the interview anxiety - which is both due to lack of practice and trying to compare oneself to folks preparing for months ahead of interviews.

As someone who has done a lot of interviewing from the interviewer side at my current FAANG, it's usually obvious when someone has seen the question before - in the debriefs, the candidates who were honest have it noted out loud to the debrief panel & it makes them look good due to integrity, and those who were dishonest also get it noted as a significant negative.

Perhaps I evaluate differently than a lot of interviewers, but I'm primarily interested in figuring out if a candidate has the traits/skills that I'm looking for in a potential coworker - for us, the traits matter more than the skills even.

I don't think I've ever been asked a question at a FAANG interview that isn't in one of the (legion of) "FAANG interview prep" books/sites that ex-FAANG engineers and interviewees constantly publish and update.

Your criteria here is likely unfairly dinging pretty much everyone who has done significant interview prep.

But significant interview prep hurts the primary job of the interviewer, which is to evaluate whether candidates would work well within the team/org - I don't mind if candidates do preparation or not, but the point isn't to try to find people who game the process, the point is to find out if a candidate is likely to be successful in the role. The problem is oftentimes it turns out that a lot of candidates who focus too heavily on preparation fail to demonstrate the qualities needed to be successful.

I don't give a particularly hard interview, candidates and interviewers who pair with me are all pretty happy with the session & almost always leave relaxed, which is usually targeted towards a certain set of leadership traits (and occasionally I'll do coding screens as well although I've been put on those less in general). My interview feedback also has generally been corroborated by other interviewers in debriefs as well, so it's not like it's in crazy land.

FAANG recruiters literally send the candidates emails that say things like "you should study Cracking the Code Interview beforehand". No, they aren't supposed to, and no, the incentives aren't set up correctly to prevent it (I've received these emails from Google, FB, and Amazon recruiters in the past).

We can't really go around penalizing behaviours that the recruiting side of the house is actively encouraging shrug

I can definitely tell you that our recruiters do not tell candidates to do that.

It's better to fake having not seen it than failing an unseen before question. No amount of honesty points will save you from failing a question. Sure if you are good enough that you pass unseen questions regularly go with honesty. If you are not, better to fake it. If FAANGs have problems with candidates knowing the questions maybe they should think of different interviews?

My coding question I give (in the occasion I am called upon to ask one to candidates) typically is not particularly unique, but practical - if someone wants to study for it, it doesn't really give them a notable edge given all the possible branching questions. The most notable tell if people did see the question prior though is if they jump right into talking about the problem without asking qualifying questions, implying that they are quite familiar with the problem & don't need me to qualify it & don't think to verify scenarios with me.

For my non-coding problems, I just create it from scratch depending on the position/needs & spend a bit of time navigating the scenario myself and store the question in my notes.

As to failing a question, failing a single question isn't necessarily a deal breaker in itself - it's showing a pattern of not meeting the bar that is. I may rate someone a 2 out of 4 if they didn't go into sufficient depth in a particular question I asked, but I probably won't stay in the way of hiring them if they did ok otherwise and that failure was just an aberration. Loss of integrity is perception that is likely to sour people on any upside of hiring though, and overcoming that bar is incredibly difficult - if someone is clearly rehearsed on a particular question and is dishonest about it, they're probably not getting a 3 or 4.

I've failed enough interviews to know that failing a question is almost always a failing interview. There are enough candidates that will get the question right and one of them will be hired, not me. Honesty aside.To be clear I am talking about FAANGs or famous startups that get hundreds of candidates per position.

I'm a senior engineer at a FAANG who is close to reaching staff by promotion - I've conducted enough interviews over the past 5 years at my current company to at least understand how my org operates.

How the process for us works is if you are a strong enough candidate, we have no qualms giving multiple offers simultaneously and working out the reqs afterwards, even borrowing against a future one if we have to. How we evaluate is probably also a lot different & more thoughtful than a lot of candidates realize - we're discussing leadership traits, strengths & weaknesses, and skills in our debriefs and what we all observed about the candidate in our sessions. No candidate does perfect in any given session - even candidates who I have given 4s for have slipped up or had negatives observed.

I think you are an outlier then. What leadership traits do you discover when forcing candidates to do BFS on a binary tree or similar questions? Why would you take someone who said he knows question A and then moved on to bomb question B when you have 30 candidates who solves question A? Ok no one does perfect but bombing a question seriously hinders your prospects. If you see a question you know or semi know you gotta be very silly to say it. People don't drill Leetcode to say oh sorry I saw this one already. Nope. In fact even remembering hundreds of questions and being able to solve them under stress is hard enough. Many FAANG candidates are just brilliant and don't really need much preparation to get accepted. But others are normal smart but spent months preparing by going through algorithm questions. It's quite certain they come up with 1-2 question they have seen before and this enables them to pass. If it wasn't the case no one would subscribe to Leetcode....

My org is generally anti-leetcode so I can’t speak for your experiences - the only data structure/algorithm questions you may encounter in an interview with my org is likely practical questions (i.e. problems we have had to solve on the job).

I’m usually not even asking a coding question in my session - I set up a practical/common problem beforehand and we explore the scenario together. I can assure you that many candidates don’t pass my session necessarily, even if they have proven in other sessions to be brilliant coders - I’m not looking for technical brilliance in most of the interviews I give, and neither are the hiring managers I work with. To me, focusing on the coding is most important on the technical screen, not the full panel - once you reach the full panel, your goal is to demonstrate technical leadership, which includes expertise in knowledge, coding competency, focus on UX, and some other areas for more senior roles (conflict management, responsibility, navigating different stakeholders for product/project decisions, etc.).

If all your focus is in is just the coding questions, you’ve likely already set yourself up for failure.

I don’t work at a FAANG but I hope to one day. But I do interview for Data Engineering roles from time to time for my and other teams. I think by saying you’ve seen this problem before it shows honesty. It shows character. Those are points that, at least for me, are positives and I like to hear it. I’ll still go ahead with the question just to make sure but if something typically takes 30 mins and you finish in 10 then I’ll move on to a different question to fill the gap.

If you waste your only evaluation period on a question obviously regurgitating an answer, interviewers notice and can't evaluate you fairly.

If they just want to watch you program, they might still ask you to go ahead, at least you've put the ball in their court.

If they think you weren't forthcoming, that might be an automatic rejection

> can't evaluate you fairly.

What's the meaning of fair? Several people admit you need to prepare, and then it seems you should not prepare too much? It looks like a date.

If this is the first time, at the same company, it (probably) does not matter, that much.

When I was an interviewer for a (second) technical phone interview at Google, one candidate performed pretty bad at one question. Later that week, or maybe the following week, that very interview was in the pre-HC meeting and one of the other pHC members pointed out that I had repeated a question from the first phone interview. At which point I pointed out that I had not been provided a list of previously asked questions, the candidate had not highlighted it, and the candidate's response was still sub-par.

Not mentioning the repeat counts against character and responsibility. Not performing better at a repeat question a week later counts against competence.

That was an easy "let's not bring this candidate on-site" decision.

I did problems from Elements of Programming Interviews, on paper, while talking out loud about what I was doing.

I would have used a white board if I had one, or a google doc (non-ide text editor) if I were practicing for a remote interview loop.

I tried to do one problem a day, capped at 45 minutes, plus a bit of time to confirm my answer if I got it, or understand the answer of I did not.

My goal was to practice things the interviewer is looking for, in a setting that is as close as possible to an interview (no ide, time pressure, etc.)

* Alternative approaches to solve the problem.

* Test cases, including walking through some.

* Runtime/space complexity analysis.

I didn’t have a good study plan for design interviews, but I’m better at YOLOing those :)

Which is patently ridiculous, IMO.

> That doesn't mean I need to understand the entire code base, but if I'm modifying a portion of the code base, I'm loath to touch it till I understand what it's doing.

This is also me. I get flack for spending too long on what seem like "small" fixes but I can't be sure (especially in spaghetti code) until I've dug through it. On a couple occasions, different companies unfortunately, I caught flack for spending too long trying to understand critical finance code. As in, how we were billing every single customer. But it always yielded results, and a week later I'm in a meeting explaining how abc original implementation would have broken xyz, but the scowls never really go away. It's frustrating.

This is why diversity of thought is important in teams. Some people will be the “ship, ship, ship type who make sure that the team is meeting its goals. Some will be detail oriented, may frustrate the first type but will ensure the team is producing quality results. Some people like to be on the bleeding edge and bring you techniques to the team. Others like to clean up tech debt or bring incremental improvements to old solutions. All of these are valuable even if they at times frustrate each other.

These are generalisations. There are likely far more “types” and different people will act as different types in different situations.

Having a mix isn’t sufficient though. The team also needs to find ways to prioritise and manage conflict to get the best approach in place for any given situation.

> diversity of thought

Thank you. I've never had a phrase to adequately describe how I like to balance teams and "diversity of thought" fits well.

I'm in the same camp, I don't even understand why programming is done under constant artificial time pressure, why are programmers constantly hounded and stressed for no particular reason? Nobody is really waiting for this task, it's an old well-known bug, or just a new additional feature but OMG HOW LONG, ARE WE DONE YET!??

Edit: same thing in this interview question, the whole point is super quick performance and working under time pressure, and making changes to code bases that you don't have time to understand, why?

You have a very good point there. Deadlines in the real world are often fairly artificial. So, why do we put people under extreme time pressure to perform in interviews?

It's optimising for the success of the person who does the planning.

It depends on the company. Especially in smaller companies, the success of the manager is very much tied to the success of the whole company, but yeah, in bigger enterprises it's often like you said.

I have found that sometimes (!) imposing an artificial timeline can bring the whole team together if done correctly. I've been in situations where projects weren't finished for a long time, everyone just cruised along, because there was no timeline and time to market was "when it is done". And there were always more important things to ship. This is bad for company and everyone involved... Just ship it, then iterate.

> I'm positive I'd fail a FAANG interview w/o advance prep

This is okay and to be frustrated at it, but it's important to recognize why it's happening.

FAANGs go through an incredible number of candidates with only a few slots (comparatively) and the point is to simply make the bar higher and higher. Just like a pragmatic engineering - you have a 'good enough' candidate set.

For me, the problem is when smaller startups copy the format - expecting candidates to jump through all the same hoops. If a FAANG has 1:100 position to interview candidates ratio, a startup will be lucky to have 1:5 (it's incredibly expensive/time-consuming for a startup to interview).

Running the same test likely means you're rejecting a lot of potentially good candidates who didn't want to go through a 'FAANG' interview.

This doesn't make sense.

If any of the candidates they are refusing are capable of doing the daily work at a FANG but can't pass the interview, they're artificially constraining their supply of candidates and increasing the cost they need to pay for developers for absolutely no reasons.

The type of work in a FANG is mostly not that dissimilar to other companies (the exception being teams working with machine learning, performance optimization, dealing with tricky scale). I understand hiring specialists for specialist jobs (and I still wouldn't test them on leetcode; ask domain specific questions).

It's just ego driven over spending on developers.

> It's just ego driven over spending on developers.

It's worth considering that engineering interviews are largely conducted by other engineers, and engineering hiring bars are largely set by senior engineering staff. They have a pretty vested interest in maintaining their own status and (relative) scarcity. Constantly raising the technical interview bar keeps engineers a supply-constrained resource...

They artificially restricting the supply of viable candidates, but this gatekeeping happens whenever engineers want (sometimes subconciously) to limit the competition and protect their high wages.

> they're artificially constraining their supply of candidates and increasing the cost they need to pay for developers for absolutely no reasons.

On the contrary, rejecting a high number of candidates pushes market rates down.

Explain please. There seems to be an assumption hidden here which might not hold true upon further investigation.

> they're artificially constraining their supply of candidates and increasing the cost they need to pay for developers for absolutely no reasons.

The incorrect hidden assumption is that by decreasing your own supply the value goes up.

It's well known that turning down candidates or refusing to interview them sends the message that their skill are less valuable. It's HR management 101.

The same goes for "anti-poaching" agreement. If FAANGs don't hire from each other they reduce the number of high-paying employers willing to hire the average FAANG employee, effectively reducing average salaries.

There was a big scandal about this.

FAANGs go through an incredible number of candidates with only a few slots (comparatively) and the point is to simply make the bar higher and higher.

This doesn't fit the "we can't find candidates, so we need more H1B's" narrative.

Supposedly, there are many open slots, unfilled, so purposefully failing people which can do the job, which meet the minimum requirements, should not be the outcome.

Instead of raising te bar, as you say, due to candidates o'plenty.

> This doesn't fit the "we can't find candidates, so we need more H1B's" narrative.

I disagree. In fact, this validates it.

On the basis of a world-wide talent pool vs a domestic. If you know there are stronger candidates elsewhere then you absolutely want to test away the domestic candidates.

Thinking about it from a hiring manager's perspective. You don't lower your standards just because a specific pool of candidates can't meet your criteria when you can widen the pool - as far as you are able.

If the H1B candidates were tested on a 'easier/weaker' test the I would 100% agree with you, but I'm assuming things equal here. And, ignoring any thing related to domestic vs foreigner workforce, "people taking our jobs" debate.

The bar is higher than needed to fill the positions (several people in the thread say they work in senior positions at a FAANG and wouldn't pass the interview). So good enough candidates are being rejected, so they shouldn't need special visas for people from abroad that are intended for real labour shortages, it would seem.

(but I'm not from the US so don't actually care)

They wouldn’t pass the interview *without studying. And studying is expected for these interviews. That doesn’t mean the bar is to high. It just means the bar is an indirect metric not testing exact job experience/knowledge.

I think "necessary but not sufficient" is an accurate way of capturing our goals for the interview question. Some really great candidates felt just like you do about the question, and we learned over time how to present it to senior candidates in a way that did not (at least in my experience) trigger that reaction.

That said, there were also plenty of candidates who came to the question guns ablazing with the same attitude, and then failed miserably. I'm not saying that's you -- but rather that it worked out in practice to be a fairly good filter for whether people actually had (enough of) that skillset.

> but rather that it worked out in practice to be a fairly good filter for whether people actually had (enough of) that skillset.

How did you rate your negatives to judge the filter was correct? You know the "Positive" status, you know your true and false positives from the interview question (People you hired that performed well or didn't. Or said another way, the predicted value was positive while true value was positive or negative).

But did you know your true and false negatives (the people you didn't hire that would have been good or bad. Or said another way, the predicted value was negative but true value was positive or negative)? Did you know the candidates you rejected who would have been good at fulfilling the roll at your company (False Negatives)?

To be clear, I don't know the false negatives either and the interview question may be the best litmus test for the behavior desired, minimizing false negatives and maximizing true positives. But I just don't know for sure if the question did work out in practice to be a good filter of people with that skillset without a true negative dataset. The Precision is good, but the recall/sensitivity may not be. Then again, you probably know how the candidates you hired performed before you used the new question and after - which may be an indicator on false negatives.

Also, that does seem like a really fun interview question to answer for me. Kudos.

EDITED: Changed the question at the same time the response came from OP. Original post asked if they hired those who failed the test to know more about the negatives. They did.

We did hire people that failed the test.

In my team I need someone like you to deliver features, not someone that can leetcode. I don't remember the last time I had to check an algorithm in Wikipedia. Probably 2-3 years ago.

Most of the time it will be debugging some arcane crap or adding to an existing codebase, anyway.

Algorithms are funny this way. Most of the time you don't need them, but when you do (and if you don't, you can't tell it when), it is a world of difference.

Still, just knowing they exist and how to formulate the search is usually enough.

100% this. I have "The Art of Computer Programming" on my book shelf, and I think I had to pull it out 2-3 times over the course of _years_.

I am sure one was a reference in the golang source code. And I once wanted to check multi-way merge sorts (tournament sort).

I don't know if I would have passed the exact question, but something like this is also in my wheelhouse. The other thing that I value very highly is consistency in any given code base. However things are already done, is how I'll keep doing them, unless there is a good reason to change. And to your point, that reason cannot be I don't understand the code. IMO, too often people want to make big changes w/o understanding (b/c understanding can be hard), and end up missing the reasons why the code was hard to begin with.

Reply on news.ycombinator.com