Live data from Hacker News

Ask HN: When did 7 interviews become “normal”?

news.ycombinator.com

711–720 of 833 posts

Re: Ask HN: When did 7 interviews become “normal”?

#711
post #501

Earlier quoted context omitted.

> I feel bad for people who freeze up and can’t even write a three line program on paper. I do the same kind of interview, and after figure this issue happens, also LEFT the room. Then eventually add: You can do it any language (even different to any we was hiring), then add: You can do whatever you want to succeed (hinting to the fact the machine used has the docs, internet, YouTube influencers, whatever at their fi…

maybe they just don't understand the questions. e.g: I challenge you to give an answer to my question? it's such a simple question, how could anyone not give the right answer. but it's as badly communicated as your comment, subject to interpretation and perplexing. now imaging being in a position of inferiority, in total fear to be asked about things you've never hear about before. like it happens not so rarely when…

> maybe they just don't understand the questions.

Questions:

- Reverse a string like "hello" without using the "reverse" function of your lang, ie: manually

- Do it in the lang you prefer most

- I will return later when you are ready

- This machine is as your full disposal, so use anything you need.

Seriously, if this is challenging, now imagine when facing actual requirements...

Re: Ask HN: When did 7 interviews become “normal”?

#712

Earlier quoted context omitted.

And how much of that complexity is truly needed? Or is that another one of the lies proferred by its financiers?

In the case of the airplane, it’s essential.

We're not building airplanes though. We're building line-of-business apps -- it's like 80% CRUD

Re: Ask HN: When did 7 interviews become “normal”?

#713
post #12

I entered the software industry as a developer about 4 years ago, and I have been running interviews for the past 2 years or so. Interview hell is all I have ever known. Could you elaborate on how things worked differently in the past? I legitimately have no idea what a developer interview "loop" would look like without 5 to 7 interviews, but I desperately hope it can exist.

From 1983 to 2008 my interviews were basically, talk to some one who's doing the hiring. No testing. Get hired. Most of those companies were relatively small. All but 2 were under 50 people. Only 1 of the 12 or so even asked any technical questions to see if I knew anything. Also, none of them were specialized. No one asked are you a Front End Programmer? Back End Programmer? UI Programmer? Graphics Programmer? etc..…

I also noticed this same pattern. Until roughly 2008 - 2010 or so, interviews were a much more informal style. You'd meet the team, get asked some basic technical questions, they'd take you to lunch, etc. If you had some sort of recommendation (inside referral) it was even more informal.

2010-ish is when I first encountered the "code on a whiteboard", and later "code in a shared doc" style of interview. One was basically 5 hours non-stop. Pure hell.

Re: Ask HN: When did 7 interviews become “normal”?

#714

Earlier quoted context omitted.

How does me being okay with a smaller role in the overall hiring process equate to me wanting to lord over people? I’m a hiring manager, it’s literally my job to pick people to hire. I’d rather have the opinions of my colleagues in addition to my own. My response was in good faith, and yours is not.

Let me add my experience. I've never had the FKANG experience but for a number of startups that I've contracted for I've had a chance to observe if not participate in the hiring process. They were US startups and they've all tried to emulate what I think of as the FAANK process: so you have an initial call, a technical screen a couple of other rounds of technical screens, that maybe include system design, and fit/beh…

this is the in-depth reply that illustrates my flippant comment. there can be an inherent competitiveness in white-boarding interviews. the interviewer can implicitly want to show their superiority over the candidate. i think that's the core reason behind a lot of overly difficult problems being offered that have no analogous presence in the day to day work. how many times have you written a graph traversal algorithm on the job? or implemented a geofence in 45 minutes, from scratch, without a search engine?

i whole heartedly agree on the pair programming approach being practical and yielding good results. i think you can skip exposing the candidate to the internal codebase, and replicate an internal problem in a more generic and high level way.

Re: Ask HN: When did 7 interviews become “normal”?

#715

It hasn't, and isn't. IMHO, if a company cannot execute a hire in three interviews (or generally less), there are serious structural issues that one should steer clear of. That said - the applicant screening process is where the most significant work-multiplication value lies; to this end, I cannot stress the significance of writing and communications skills with regard to the quality of a CV / resume. If the executi…

This correlates well to my personal experience. The companies with the longest interview processes have been the worst to actually work for: 8+ hour interview processes, 5 or 6 individual interviews, HR "behavioral" interviewing, on and on. The longer the process, the more dysfunctional the organization, the worse the actual job.

Re: Ask HN: When did 7 interviews become “normal”?

#716

Hiring manager here. IMO the current tech hiring norms are gross and not sustainable. It feels like a weird hazing ritual and with the current market, is the single biggest reason you can't hire. Why on earth would someone burn a weekend on a take-home test for your startup when they have 15 other irons in the fire? At my current employer we got rid of all that ridiculousness. No take home test. No live coding. We've…

We don't do take home, leetcode, live coding either. We walk through past projects and ask very pointed questions. We ask about difficult problems we've faced in the past and how you might solve it. I role play a junior programmer describing a situation I have and then ask junior programmer level questions of how to solve the problem. You get to talk to two very senior software developers, and two very senior enginee…

> Once you get past the first screening call, I find you on social media, blogs, forums and read your posts, and see what questions you're asking on stackoverflow.

And what if my social media presence is minimal or not public?

Re: Ask HN: When did 7 interviews become “normal”?

#717

Earlier quoted context omitted.

> I actually got stuck at an interview because I forgot the nlogn solution for two sums. Absurd! Are you talking about determining a pair of numbers in an array that sum to a given value? That's O(n) and just uses a hashset/hashmap.

No. Sort the array. Then use two indexes, one on each side of the array. Increment indexes to meet in the middle. This is one of those tricks you just have to memorize and it's very hard to come up with the solution in 30 min.

> This is one of those tricks you just have to memorize and it's very hard to come up with the solution in 30 min.

Maybe that particular solution is hard to come up with, but you can solve the problem without any "tricks", just basic principles. I'll try to explain which principles I'd use using python.

You can start with the trivial O(N^2) solution:

  def has_2sum(lst, target):
    # returns whether there are 2 (not necessarily distinct) elements in `lst` which sum to target
    for a in lst:
      for b in lst:
        if a + b == target: return True
    return False
First principle is runtime analysis. The runtime is O(N^2) because the inner loop is O(N) and runs N times. So we can try to speed up the inner loop. Second principle is to rewrite what the inner loop body as a function of the loop variable b.

  def has_2sum(lst, target):
    for a in lst:
      for b in lst:
        if b == target - a: return True
    return False
Third principle is pattern recognition for common functions: the code is equivalent to

  def has_2sum(lst, target):
    for a in lst:
      return (target - a) in lst
Fourth principle is to know which data structures support membership query. If you thought of hashtables, you get the O(N) solution.

  def has_2sum(lst, target):
    set_lst = set(lst)
    for a in lst:
      return (target - a) in set_lst
If you thought of sorted list, you get an O(N log N) solution.

  import bisect
  def has_2sum(lst, target):
    sort(lst)
    def contains(x):
      # equivalent to `x in lst`
      i = bisect.bisect_left(lst, x)
      return (0 
If you thought of `sortedcontainers.SortedList` (a third-party python package), you get an O(N^4/3) solution (analysis: https://grantjenks.com/docs/sortedcontainers/performance-sca...)

Re: Ask HN: When did 7 interviews become “normal”?

#718

Earlier quoted context omitted.

I made a concrete statement about what I think the minimum technical bar for EMs is up to at least L7. I also remarked that "clearly this isn't your main focus" at that seniority, which you seemed to skip. The second paragraph, the one you seem to have an issue with, a combination of 2 things: - a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game tech…

> - a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list But all of these are the exception, not the norm. You said you've been in a FAANG style org, so you've been able to view the org-chart. For every Jeff Dean or John Carmack, there's three-dozen directors and VPs who manage large o…

> Maybe we have different definitions here, but I've never, or perhaps once, had a manager who I felt could do my job in a pinch,

The chief of Air Force still flies the fighter jets just as well as the junior pilots. The head of surgery in a hospital still operate just as the junior surgeon. Why does tech have to be different?

Re: Ask HN: When did 7 interviews become “normal”?

#719

Tech is very cargo cultish, which comes from having a young average age, and a strong survivorship bias in the media. Remember the Google brainteasers? Fizzbuzz? "Culture fit"? Tech companies have the lowest infrastructure costs of any industry, and so they have no place to hang their risk aversive paranoia except on personnel (the safer you are, the more trivial the things you fear). There's nothing logical about it…

All we need is a “3+ interviews considered harmful” post to hit HN a few months in a row and we can finally solve this problem. That, or we’ll have some representative from the big 5 saying “Hey guys, Jayden from (x soulless Silicon Valley company) here. Not speaking on behalf of my employer but actually at X Corp(tm) we’ve found that anything less than 37 interviews (+tip) isn’t enough to let the real stars shine th…

Quite the opposite actually. At one of the big techs that I was part, they ran some analysis and found that anything more than 4 interviews didn't add any value in assessing the chances of an individual succeeding at the company. I never read the details of the tests they ran but I'm glad they came to that conclusion.

Re: Ask HN: When did 7 interviews become “normal”?

#720
post #44

Having been an interviewer at a FAANG for many years, I can explain some of the logic behind it. I'm not saying this logic is valid , but it's how we got here, imho. First: we no longer trust the hiring manager alone, because probably they aren't a strong developer. We instead trust strong developers that are well trained at evaluating good devs. At the same time, we don't want to thrust a dev onto a hiring manager,…

I'm convinced that the best interview is to give someone an app (react or node app for example) and do exactly what occurs all the time in the real world. Give vague indication that a feature appears to sometimes not work correctly. In the app code there should be one or two very obvious bugs and easy optimizations to make, and then put more subtle and challenging to fix issues there as well. And ideally make it some…

I've done a variation of this exercise with some folks I helped to interview.

We showed them our website and asked how they'd investigate/troubleshoot a complaint that the site was "slow."

Then we kind of role-played the troubleshooting process. Ideally I wanted them to determine if the site was slow for everybody, vs. just the person that reported the issue. If it was only slow for a single person, was it their account, or many just their internet connection? How would they determine that? If we determined the issue was happening for everybody, how would you determine which part of the stack was slow? Etc.

Post reply on HN