Then I started interviewing people for engineering and security engineering roles. That's when I realized that unless you put a lot of effort into curating your candidate pipeline, you interview engineers who literally (without exaggeration!) cannot complete anagram toy programming questions in their "favorite languages." That was a sobering moment for me.

I'm in agreement that a lot of tech hiring is suboptimal, selects for noisy heuristics and is even (sometimes) sadistic. But I've also met engineers - typically people who have not done interviewing or hiring much - who think that reports of fizzbuzz failures have been greatly exaggerated. They have not been exaggerated.

I haven't interviewed anyone in over a year, but back when I was doing it weekly I used to mentally sigh with relief when the candidate I was talking to could actually approach technical questions, even if they ultimately didn't give winning answers. It is a sad reality indeed; the bar is low enough that you have an edge by merely engaging with the problem and reasoning about it with technical competence in an interview.

How much say do the people working on a team have, in who gets hired? I mean people who'll actually be working with the person day to day, not some manager.

If the answer is 'we tell recruiting agencies we're hiring for vague role X, Y and Z', then why are you surprised?

Is the work any interesting? No? Generic corporate codebase perhaps? And you're getting generic people applying? How strange :)

ps. This is not directed at you in particular. I just find it strange when people don't do an inch beyond 'we pay money', and then expect a mile beyond 'i do just enough to get paid'

Retaining staff doesn't mean that you aren't hiring at .2 headcount per annum.

Assuming that there's a basic process of CV review (by team members who would work with) followed by non technical phone interview. You will still have people who fail fizzbuzz. I'm not talking about small errors reading the problem - but the inability to even put a for loop in pseudo code onto the page.

The fact that the test is required is somewhat silly - but it's hardly limited to dull corporate roles.

See, you are assuming a basic process of a job board and anyone applying for the position.

I am saying you are so entrenched in mediocrity that you can't fathom there are much better ways.

I will say this though - they all require a fundamental shift from 'fill seats with people for minimum amount of pay, to do uninteresting work, with least amount of complaining' to actually giving a shit about people you work with, yourself, and your life :)

Like what?

I have conducted literally hundreds of technical interviews. To me, too, it was a jaw-dropping realization that some candidates can arrive who literally have no idea how to program a computer. I don't know how they get through school (with high GPAs, even), held their last job, or impressed their phone screener. I don't even want to speculate. The sad fact is that trivial, two-minute, easy-peasy exercises can and will expose some candidates as being unable to work through them, even with the most friendly and patient coaching.

So I always ask at least one trivial question that can be solved in a minute or two with a couple of basic relations and a Boolean connective.

This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by either (1) careful training or (2) surviving many repeated failures, and finally getting at least partially acclimated to these kinds of confrontations.

Yeah sure, perhaps some of the people who "bombed" that calendar test really were the walking fraudsters the interviewer (who knows they'll get to stay in their well-paying job regardless of the outcome of said interview) makes them out to be. But most are probably simply nervous, and due to a variety of psychological factors (imposter syndrome, among others) are simply momentarily blanking out, and having suffering from a very common form of mild anxiety attack which makes the problem seem much more complex to them (at that moment) than it otherwise would, under more natural circumstances.

I've literally started nervous people with "naively print the string 'hello'"... After warming up, the best one eventually completed my max-difficulty questions.

I would add that it takes significant experience and preparation to interview people effectively. This is a difficult-to-learn soft-skill that not everyone has.

Too often folks just get dragged into an interviewer situations with no planning or coordination.

Is there evidence for this claim? I'm inclined to believe it but that's experiential. It's also something I've never had to work to acquire, but that could be a cultural thing (my family and friends talk a lot about thinking) or a personal history thing (I have a minor learning disability, and it has forced me to develop strong, conscious meta-cognition).

It's not a given, tho, that being able to talk about thinking is distinct from being able to think and being able to talk.

But talking through a problem forces you to use verbal reasoning. A lot of programming can be done well with non-verbal reasoning skills.

Personally, quickly sketching some timelines on a piece of paper would be the fastest way to get the correct checks. Talking it through would force me to convert my mental visualizations into words, and that'd make me stumble.

people who "talk to themselves" are labelled idiots. mental dialogue is supposed to be mental.

call it social conditioning if you will. spelling out your thoughts for someone else to hear them just so they can take note of them for evaluation is the polar opposite of normal human interaction.

The problem with the modern interview process is that not only elevates the later approach way out of proportion to its actual significance -- but basically makes in the centerpiece of your interactions with the company and potential team members, on that fateful day.

Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.

Agree mostly -- just that I guess I've fallen into more abusive environments than I should have allowed myself to over the years, where the stress levels have hit will into the 7-10 range.

But in healthy environments -- even when I really did screw something up (sometimes quite significantly) -- it's never above the 4-5 range.

Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.

And pretending that they can read the tea leaves, and make that kind of assessment as to "whether this guy can handle a medium amount of pressure", to boot.

you don't know the circumstances that 30 year old programmer with a 2 year old child at home is facing. You could also be like certain firms and immediately nix him on the "merits" of ageism.

A female programmer might have travelled 2000 miles to just receive an abstraction question out of left-field over an irrelevant concept to the job. She flew out on this uncertainty, and she's in a rather discriminatory field.

26 year old dev has probably built CRUD apps all his short career. and, you're asking him to implement (isBinarySearchTree Boolean) on a whiteboard on the spot.

A choice, conscious or not, to dedicate time to raising a child at the opportunity cost of myriad other ways to spend time is not related to ageism at all.

Hear! Hear!

One of the things that bothers me a lot about HN is the near assumption that if you're a software engineer and not in SV (or have never been in an SE job in SV) - you don't count as much.

I'm biased, I will admit: I've never held a software engineering job in the Valley. That opportunity has never occurred, nor have I tried to pursue it. I live and work in Phoenix, Arizona; at my age and position in life, even if the opportunity did present itself, I'd have to think long and hard about it. It would likely be a situation of me leaving my family to go work there, as relocation would likely not be a realistic option unless the pay was over the top (I am not going to move back to an apartment; my next house better be at least as large as my current one, and include a larger yard and/or shop space before anything else).

Here, in my current position, I am not only the oldest developer on the entire team (and I am only a few years younger than the owner of the company), but I also am one of the few who doesn't have any children. My wife and I made the conscious choice not to have kids a long time ago, and we are constantly glad for it. In fact, she thanks me on a monthly basis for not "knocking her up".

Honestly, we'd probably make terrible parents, and we're pretty selfish as a couple. We know this, so why bring children into the mix, right?

That said - here in Phoenix (where it's actually difficult to find competent software engineers for any position), I've never seen or experienced there being an issue if you have kids; every employer I've worked for has been extremely flexible.

In fact, both at my current employer, and my previous one, they encouraged you to leave when your day was up. If the end of your day was at 5pm, they didn't want you stay a minute more if there wasn't a really good reason for it. Like things would have to be well and good on fire for that to happen; anything less was "go home, get some rest - it'll be here to fix tomorrow".

The attitude out west is "You want to earn enough to raise a family? You should have thought about that before you had kids".

It also seems to me that the people who have the most trouble with work/life balance in development jobs, at least out here, is that they are too afraid of saying "no".

absolutely true (at least in my case). I'd rather do that than end up on the other end, though. Without stronger protections for employees, I'll hold out for a stronger financial position on my own before I start negotiating hard about "work/life balance".

When I've been through such phases, once I realized that I could set reasonable expectations, it was never actually a big deal. Eventually I even started taking my vacation days, nervous that my job wouldn't be waiting for me when I got back, but that was really all in my head.

I've been in many stressful situations at work - none of them involved finding algorithmic solutions.

It's the idea that this kind of pressure can in any meaningful way be simulated (and the candidate's response adequately gauged) using the shticks and routines that people try to do in the current standard interview process that people take issue with.

Not quite all about algorithms, but that was part of it :-)

Also found that the probability of someone finding the porn in the demo by randomly pressing remote buttons pretty much approaches 1 as number of button presses approaches infinity...

Not once in my career had I had to fix a problem in an hour, let alone 10 minutes.

I have had senior people get mad at me when I couldn't give an answer during a meeting - that's the closest to an interview type scenario where you need the answer now. But even then, I did not stress that I'd lose my job, which is similar to the stress the candidate is facing.

Yeah, but if so it's usually of the form of "oh shit, forgot to chmod this little bash wrapper".

To the extent that it's of the form of "Solve this cute little dynamic programming problem I heard about from some company where everyone is like, gosh, oh so smart! In like, the next 5 minutes, k?" -- well, basically never.

It's like interviewing a doctor who will be someone's primary care physician. Give him/her a set of symptoms, and fail him if he doesn't diagnose it inside of 10 minutes. And then justify it with the expectations in surgery or ER.

I'm sure good at fighting database fires though.

This probably is at the heart of the answer to the question "how could this programmer with such a long resume have botched this interview so badly?" It would be insane to believe they've never added value to any organization and have just been coasting along all this time. Maybe your interview sucks and isn't good at finding value.

I know you did not mean it this way, but in some ways that's even worse. If that type of thing were routine enough to merit asking every interviewee that question, I would seriously reconsider working there.

Armies train people by having them run obstacle courses with guns being fired all around them. Do a "realistic" interview, then, to really test how someone does "under pressure". Have them sitting alone in the room, and a screaming angry manager runs in yelling obscenities at them about how the production system is down, it's costing the company millions of dollars, and if they want to have a job they'd better get it fixed ASAP!

And have that same manager stand over their shoulder the whole time, yelling yet more obscenities. If the candidate doesn't get it fixed in, say, five minutes, then obviously they lack even the most basic qualifications to work as a programmer and you can reject them. Heck, save money and don't even do it on-site -- get their phone number and do it 3AM on a weekend, just like a real on-call situation!

Or... maybe the whole "under pressure" thing is just an excuse people use to cover for the fact that they like making people squirm, enjoy the feeling of power they have from knowing someone else's future is in their hands and that person knows it, and want to savor by making the trained monkey stand up and dance on command... or else.

Unfortunately, people who like the "under pressure" idea of interviewing seldom realize that sooner or later they're going to be the monkey and someone else will be the organ grinder.

Sure -- it's just the tenor (and for some people, sheer intensity) of the psychological stress experienced during interviews is, for many people, basically orthogonal to the stress of real-life work situations -- or even genuinely dangerous (even physically threatening) situations in life, otherwise.

With the latter, it's like "Oh shit - the client's gonna get real pissed if I don't figure something out real quick".† Or even: "That guy looks like he's about to lunge at me - I better think of something!" For which your brain and your glands have benefitted from millions of years of evolution in support of mechanisms for pumping just the right kind and amount of juice into your system to "figure something out".

But with interviews it's more like: "This person's evaluating me, using some hidden criteria. Given that the problem is slightly tricky, I literally don't know if they're expecting to power on at all costs, or, secretly, that I simply admit that I don't know where to start just yet. Not only that, something tells me he's not stating the problem quite correctly -- they do that, no all the time, but way too often in these kinds of interviews. And on top of that he's just being plain overbearing... and now he's starting to fiddle with his phone. On top of starting 15 minutes late. Like he never really wanted to talk to me in the first place. If I ask too many questions -- or even just one instance of the wrong kind of question -- I'm screwed, and gonna have to hit my inbox for leads again. Oh great, now he's starting to offer 'hints', completely derailing my flow of thought and whatever self confidence I thought I had. Fuck it -- I just should bail and go work on my personal projects. No one will be paying me $150k but at least I'll be learning something."

† Where "the client is gonna get real pissed" is roughly equivalent to "if I can't get these rocks to flake in just the right way, we aren't gonna have any more arrowheads and were' all gonna starve!", to a first order approximation.

understatement of the year.

I am not saying it is right, I am just saying at some shitty places it is.

That's a high-pressure situation, so if you're hiring for that, it might make sense to interview under pressure.

I have worked on systems that could cause operator death or disfigurement or damage... they are tested quite thoroughly in general and have reasonable failsafes and redundancy. It's not like they are coded on a whiteboard.

being on site at a customer facility while there is a ton of noise does stress you out a bit but most of the coding and testing is done in the office.

> That's a high-pressure situation, so if you're hiring for that, it might make sense to interview under pressure.

I think the jobs that have that kind of pressure are rare and interviewing like that should be the exception not the norm.

The problem with giving technical interviews is you are testing for someone who is an extrovert that can bullshit under pressure. That's not what you want. You want someone who is smart and can solve problems with a compiler.

I have not interviewed many people yet, but already during one lunch (!) interview (where I don't ask any questions), a guy was so proudly talking about his achievements at his previous job in quite generic terms, that I've got an impression he was teached the whole story, rather than actually lived it.

Later he was not hired. According to (trusted) others in the interview loop he did not know how to do any basic shit.

Having said that, let me be clear. This isn't a good tool if all you have to do interviews is a manager. They probably won't be able to tell the difference, especially if they are just generic managers with little to no technical experience. They aren't the type you want giving technical interviews.

Asking about favorite projects is easier for extroverts that can bullshit under pressure than technical interviews.

Do you think introverts don't like to talk and to brag?

Ask an extrovert bullshitter who couldn't care less about Star Wars about Star Wars and you can easily tell the difference. (as long as you yourself aren't an extrovert bullshitter who couldn't care less about Star Wars)

Edit: that should be 'overemphasized', of course.

I don't think they are fraudsters, they are simply not too good programmers who can't solve simple problems by themselves. Many dudes believe themselves to have technical talent just for memorising done basis. That does bit imply problem solving ability.

Momentary blackouts happen - rarely.

I am about to start work as a senior engineer for Apple with 4 1/2 years of experience, after passing two back-to-back onsite interviews with them, and I hardly have studied specifically for technical interviews. I possess an MS in mathematics.

Don't presume anything about an individual just because the person happened to not answer a particular question - the person could be actually much smarter than you. It could have just been a bad day, or a number of factors.

But then there are people for who practicaly any question beyond "lets talk in general about what you like and how passionate for technology you are" is unfair and causes black out entry single time. Thay is entirely different.

It is super important to try to ease a candidate into being comfortable to get the important information you need as an interviewer, as interviews are inherently stressful for candidates, and you almost never want to be testing a candidate's stress coping abilities.

"I dunno - they put me through this stuff, or some variant, on my way in. So now I guess it's my turn to dish it out on the people trying to climb in after me" seems to be about the order of reasoning in place behind these "methods".

† As in, was an open problem in the literature and/or folklore for years before some (now) highly respected came up with the first reasonably adequate (but like as not, overcomplicated and/out outright flawed, at the outset) solution. We know the "usual suspects" that get asked -- I don't need to list them here. But ff you genuinely think that any candidate you can (reasonably) expect to find in response to your muddled job postings will genuinely be able to solve these problems for you at the whiteboard for you -- from the void, as it were -- as opposed to regurgitate carefully practiced solutions they found from cobbling together lists of "problems Google and FB like to ask" -- you're seriously kidding yourself.

There is nothing to suggest that parent poster has bad social skills or that his job posting was muddled.

Do you know "majority of people" or have interviewed them?

Have you yourself faced an interview question at an abstraction level far below your area in this field?

Yes, I have faced questions I could not answer. I did my best and that was it. That is however not blackout - that is me not knowing the answer. Blackout is when you temporary can't recall.

But that's the thing -- it literally takes just one person out of 5 or 6 to say "I don't know about this guy" to get the rest of the team to pass. No matter if he didn't seem all that well prepared or interested in you, you guys just didn't click, or you were exhausted because no one thought to let you get coffee or use the restroom.

This never happens in normal work, even when working under pressure with a deadline that has to be met and not enough time to make it.

It's just a completely different setting and purpose. In one case I'm solving a problem for the sake of being judged and that judgement may impact my whole life for the coming years. In the other case I'm solving a problem because there is a practical need for it and I'm just doing my job.

It has nothing to do with being a good programmer or not, it has nothing to do with my actual ability to solve a problem either.

Funny thing -- these folks have, y'know, actual data on this stuff:

http://blog.interviewing.io/you-cant-fix-diversity-in-tech-w...

Choice quote:

As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.

(assuming the list happens on the same day)?

What I like about pklausler's example is that it allows for people to find edge cases without too much technical knowledge. If I have a candidate who doesn't ask about the inputs (e.g. "are the appointment sorted?"), I'd be wary. Engineers are often given vague specifications they need to clarify or account for.

Unfortunately, this can also occur because the interviewer isn't clear on their own goals in the first place. They asked the question before really knowing what data points they want to come away with.

One could even argue that relying on the order of the items in this case is going to result in a worse design overall (it's one additional thing the caller can get wrong).

https://news.ycombinator.com/item?id=9478906

I like the problem, and I'll probably use it in future :) It'll be a low bar for those times where you're getting the impression that a bigger task will be beyond the candidate, and you want to cut your losses early.

FWIW, I've seen similar complete failures to reason when applied to the even simpler problem of testing to see if a point is inside a rectangle. Some people seem to have a very underdeveloped one dimensional measure function in their brains.

Instead of this:

"Given two appointments, one that starts at time A and ends at time B and another that starts at time C and ends at time D, how can I tell if they conflict?"

More like this:

"I need to run another errand while I'm in town for the interview. I can either do it after the interview, or if I do it first, I'd better be done before the interview."

That gives me something concrete to think about so I can make sure I am on the right track and won't miss my interview! And from there it's a pretty easy path to working out the detailed formula. If I jump into the abstract description right away I'm a lot more likely to confuse myself.

  B <= C or D <= A

I've always asked something that involved a loop, to ensure that candidates understood how to write a for loop.

(I have a variant of the above, a "more complicated" question, that involves maintaining two pointers/iterators; that removes another huge chuck of candidates…)

    numbers.reduce((a,b) => Math.min(a,b))

Then again, you might run into a joker who has just memorized how to use reduce for finding the maximum or minimum element in a list of numbers.

If they can also write, or at least quickly approximate, the for-loop solution too, then I'd say I've gotten an excellent signal: not only can the candidate write a for loop, but he or she might also have some experience with a functional paradigm from somewhere.

We used to ask people to right a function in C that converts an array of doubles from degrees to radians. It was amazing how many people had no idea and who had sailed through CV/resume screening, telephone interview, and 'technical discussion' part of the interview with ease.

I guess the candidates could 'talk the talk' when we were asking them questions on their CV, or general high-level questions on, say, threading or design patterns; but when it came to the crunch they couldn't write code.

Maybe the candidates were just good at generating CRUD applications and binding data to forms, and have rarely needed to process data. Not denigrating that aspect of software developement at all - it's just not what we need in our department.

If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly.

Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically.

If you want people to do real development, those are hard to come by. If what you really need is someone to maintain some bloated codebase and make it worse, but not too fast, then most people will do just fine.

Another thing is: what do you really want from a candidate? What led you to start asking them trivia questions in the first place?

The really good ones will be put off by trivia because it brings them zero value. If you ask questions that actually pertain to the field you're hiring for, it'll go over much better.

For example I applied to work at a major bank, and got asked a bunch of security questions, which exposed me not understanding how main in the middle attacks worked. The interviewee had requested that I go home, do a bit of research and email them the answer.

This brought them value because they found out that's an area I have little knowledge in, and it provided me with value because it pointed me in the right place to go research.

Trivia puzzles don't add value to anyone. Frankly if you're doing trivia and are upset by the response you're getting, a part of that is your fault :)

You don't want to work with people who can't solve trivia like this. Something like man in the middle can be learned, basic problem solving takes time to develop.

The places that have garbage and years of technical expect far less from their devs because they can get far less. These are also the places that prevent tickets for refactoring and never let devs pay down technical debt, then they get mad when development is slow. They value the next piece of "functionality", even if it as simple as new entry in a menu more than they value their future. When there is so much technical debt that adding that menu entry takes a skilled developer 60 hours this becomes the norm instead of a problem to solve as a business.

I would rather not hire a developer familiar with such situations and failing to fix them. Whether the failure was their ability to recognize or communicate the problem doesn't matter the problem existed and they were near it and it wasn't fixed. If I start having those problems I want people who aggressively deal with technical problems in my technical positions.

I can of course be persuaded to hire such a person if they explain what they did and they seem highly competent. Perhaps, they did do all the right things, did go above and beyond and the culture was still so toxic as to prevent progress, I have been there before. But the interviewer would need to convince me and I think that is the point of an interview.

I'm not necessarily saying that such things don't exist, but not my cup of tea.

Say the first appointment goes from a to b and the second goes from c to d. What does it look like if the appointments _don't_ conflict? This happens just when one appointment ends no later than the other begins; in other words, when b ≤ c or d ≤ a. So, the appointments conflict just when not(b ≤ c or d ≤ a). We can then distribute the negation using [De Morgan's laws](https://en.wikipedia.org/wiki/Negation#Distributivity) to arrive at this: the appointments conflict just when b > c and a > d.

You're saving a few characters to make the code less obvious. Please correct me if there's some other benefit.

If two appointments conflict, that means that there is a time when they are both active. Thus each of their end times are after both of their start times. Of course, each appointment ends after it started, so that just leaves that each appointment ends after the other started. So if the appointments are a to b and c to d, then they conflict iff b > c and d > a.

(I've corrected bumbledraven's mistake of a > d vs. d > a.)

a = 1, b = 3, c = 2, d = 4.

Do they conflict?

b > c and a > d

with conflicting appointments from 1-3 and 2-4:

a = 1, b = 3, c = 2, d = 4

won't that evaluate to:

3 > 2 and 1 > 4

true and false

false (no conflict)

I could be wrong, but I think you have to do all four comparisons as in aldarn's comment:

https://news.ycombinator.com/item?id=14641043

(no fair peeking!)

With two events, X going from xb to xe, and Y going from yb to ye, you have these possible sequences:

    xb xe yb ye (no conflict)
    xb yb xe ye (conflict)
    xb yb ye xe (conflict)
    yb ye xb xe (no conflict)
    yb xb ye xe (conflict)
    yb xb xe ye (conflict)

We can evaluate this expression over those cases:

    xb xe yb ye : yb < xe => false => no conflict
    xb yb xe ye : xb < ye and yb < xe => true, conflict
    xb yb ye xe : xb < ye and yb < xe => true, conflict
    yb ye xb xe : xb < ye => false => no conflict
    yb xb ye xe : xb < ye and yb < xe => true, conflict
    yb xb xe ye : xb < ye and yb < xe => true, conflict

Just to compare with the previous comments, if we put your notation back into the a-b c-d format, then it would be:

conflict = c < b and a < d

It's interesting to note how the choice of names makes such a difference. With the arbitrary names a, b, c, d for the four times, it's harder to think about whether the expression is right. Which was 'c' again?

Your names xb, xe, yb, ye are still terse, but once you know that x means one appointment and y means the other, and be and e mean beginning and end, it makes it much easier to think about it.

which I first understood to be a conversational statement rather than a statement of logic (which I assume GP is referring to), in which case it should be (b > c or a > d).

1. Figure out which appointment starts first

2. Check if first_appointment.end > second_appointment.start

So:

    boolean AreAppointmentsConflicting(int start1, int start2, int end1, int end2) {
      // first and second refer to the start time of the appointments.
      // The first appointment is the one with the earlier start time.
      int first_appointment_end, second_appointment_start;
      if (start1 > start2) {
          first_appointment_end = end2;
          second_appointment_start = start1;
      } else if (start1 < start2) {
          first_appointment_end = end1;
          second_appointment_start = start2;
      } else { // same start time
        return true;
      }
      return first_appointment_end > second_appointment_start;
    }

   return (start1 > start2 && end2 > start1) || (start1 < start2 && end1 > start2) || start1 == start2;

The third answer would get massive upvotes for brevity on LeetCode. The first answer would be preferable for readability in an actual code base.

But I can understand the objection to the third version too. I don't think the problem is that the expression is too simple - simplicity is generally a good thing! - but that it's easier to reason about non-conflicting times instead of conflicting times:

If my other meeting ends by the time this one starts, we're good.

Or if this meeting ends by the time the other one starts, we're good.

Otherwise we have a conflict.

So now if you like the step-by-step approach, we can write a function that seems pretty straightforward and easy to understand:

  boolean AreTimesCompatible( TimeRange thisRange, TimeRange thatRange ) {
      if( thatRange.end <= thisRange.start ) {
          return true;  // that one ends by the time this one starts
      }
      if( thisRange.end <= thatRange.start ) {
          return true;  // this one ends by the time that one starts
      }
      return false;  // they overlap
  }

  // Time ranges are compatible if that one ends by the time this one
  // starts, or if this one ends by the time that one starts.
  // Otherwise they overlap.
  boolean AreTimesCompatible( TimeRange thisRange, TimeRange thatRange ) {
      return
          thatRange.end <= thisRange.start  ||
          thisRange.end <= thatRange.start;
  }

  boolean AreTimesConflicting( TimeRange thisRange, TimeRange thatRange ) {
      return ! AreTimesCompatible( thisRange, thatRange );
  }

Half the time I pick a good solution and half the time I've rushed in and picked the wrong one.

If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The interview unfortunately ends after 30 mins.

I should also add that I'm not much better at this after 13 years of professional development than I was when I left uni, when it comes to manipulating linked lists and arrays. My systems design is a lot better though.

Unless the interviewers haven't given much thought themselves. "Hey Joe, we have to interview a guy in 20 min. and I can't remember where are those damn interview questions. Gather up a few for me, will ya?"

The dimensions of appointments are [startTime, endTime, location]. If you have points in one appointment that intersect with other appointments, then you have a collision.

It isn't though. First assume that all datetime stamps are in UTC, otherwise we have opened a can of worms that still trip experienced developers. Now draw a "timeline" and start enumerating the different cases. Then you can make a reasonable solution. But I would only expect this from experienced developers or people with a higher degree.

To which meeting does t1 belong? One, both, neither? Can we set up an event at t1 which is not in conflict of either? How about two events at t1?

if (endtime[1] > starttime[2]){status=conflict}

work? Assuming time is encoded in epoch format.

[appointment 1 start] [1 end] <-- some time --> [appointment 2 start] [2 end] (case 1 - no overlap, appointment 1 first)

[appointment 1 start] [appointment 2 start] <-- some time --> [1 end] [2 end] (case 2 - overlap, appointment 1 first)

[appointment 2 start] [appointment 1 start] <-- some time --> [2 end] [1 end] (case 3 - overlap, appointment 2 first)

[appointment 2 start] [2 end] <-- some time --> [appointment 1 start] [1 end] (case 4 - no overlap, appointment 2 first)

So you need to do:

if (appointment1.end > appointment2.start AND appointment1.start < appointment2.end) OR (appointment2.end > appointment1.start AND appointment2.start < appointment1.end) // conflict

  a = Appointment 1 start
  A = Appointment 1 end
  b = Appointment 2 start
  B = Appointment 2 end

The complete set of orderings are thus:

  aAbB - no overlap
  bBaA - no overlap
  abAB - partial overlap
  baBA - partial overlap
  abBA - complete overlap of one appointment inside the other
  baAB - complete overlap of one appointment inside the other

barrkel has a thorough explanation here:

https://news.ycombinator.com/item?id=14641485

Or, as I realized later, it seems helpful to me if I look at it as a practical problem instead of an abstract one:

https://news.ycombinator.com/item?id=14642059

This actually isn't correct. Consider the events (0, 3) and (4, 6). The end of the second (6) comes after the beginning of the first (0), but they don't conflict. You want `and`, not `or`.

EDIT: oops, just saw you edited it. Good catch :)

Your notation there, where instead of a pair of start/end pairs you have a list of tagged times, reminds me of a good approach if one is doing a generalized version of the problem: given a list of N appointments, find conflicts.

Make a list of tagged times, where a tagged time is a triplet (time, 1, name) if appointment named "name" starts at time "time", and is (time, -1, name) if appointment named "name" ends at "time".

Sort the tagged time list with time ascending as the primary sort key, and the start/stop tag ascending as the secondary key.

Now to find conflicts you simply scan through the tagged times list, keeping a running total of the start/end tag values. If the running total is greater than 0 when you begin to process a given entry, that entry has a conflict with an earlier appointment, and the running total is how many earlier appointments it conflicts with.

As described above, this lets you print a list of what appointments have conflicts with earlier appointments, but it doesn't give an easy way to say which earlier appointments conflict. If you want to do that, it is straightforward. Just add a set data structure, and during the scan of tagged times add "name" to the set when you encounter an appointment's start, and remove "name" when you encounter an appointment's end. When you find a conflict, the set contains the names of all of the earlier appointments the present appointment conflicts with.

The above assumed that two appointments do not conflict if the ending time of the first is the same as the starting time of the second. If that should be counted as a conflict, just change the sort so that the secondary key is sorted descending instead of ascending.

Can I assume the times are in a sane date format/datatype? If not, start with e1 = toSaneDateFormat(endtime1), s2 = toSaneDateFormat(startime2) (Fill in if interviewer is interested).

Then, as you say, a check for overlap is easy - but maybe one wants to be more fancy, like: if (timeDelta(e1, t2) < timeToWalkFromAtoB, or < 5 minutes -- they should be considered an overlap? If they are on different continents, maybe < 24 hours should be an overlap?

At any rate, I'm guessing (hoping) this leads to discussions about representing dates, and what the business logic is (eg: physical meetings - you can't teleport from one location to another).

[ed: And as others have touched on, if you deal with timestamps/raw number types - be careful that you don't end up with appointments in "wrong" order - I'd say a sort() aware of date-objects might be your friend here.

ed2: In fact, if you can assume a sane date-type, and timeDelta, you could probably assume an "interval" type, and simply ask for overlap?(appointment1, appointment2) ... ]

In my experience interviewers are usually looking for the technical solution despite the business oriented solution usually being much more applicable (and thus relevant) in the day to day role.

Key thing to remember here as an interview candidate is to clarify with the interviewer the scope of the question and the nature of the answer they're looking for. If for instance the interviewer starts with the simple technical solution and then probes the business aspects this might be a nicely rounded question.

e.g. in J:

       'a b c' =: 50 60 3 4;3 50 49 99;2 10 10 12  NB. 3 different sets of appointments
       3 :'ok`nope{~0>*./-~//./:~_2]\ y' every a;b;c
    ┌──┬────┬──┐
    │ok│nope│ok│
    └──┴────┴──┘

  overlap = a.start < b.end and b.start < a.end

Mother of god

It is as you put: depressing as hell. And this is among white collared, educated, demographics. Imagine how it must feel to be an uneducated demographic in most other parts of the world...

This is only a problem if the interview/hiring/capitalism process is meant to be fair.

> Imagine how it must feel to be an uneducated demographic in most other parts of the world

The less privileged here certainly had jobs in HS and college where you just filled out an application, the manager made sure you weren't a convict or on drugs, and you got the job. The "uneducated demographic in most other parts of the world" is probably not solving algorithm quiz questions on a whiteboard.

It's also a problem when those same companies want to bitch and whine about a "talent shortage" or a lack of diverse candidates.

so much this. Why do companies get to receive all sorts of incentives to hire when candidates they reject walk into other great tech firms, make bank, and generate boatloads of value?

Maybe some should just pay more, too. There are plenty of firms just being too cheap to hire great talent, including some large, well-known ones.

How many operations can a modern CPU perform per second: A) Thousands, B) Millions, C) Billions

We'll accept C, and B with explanation. I'd say roughly 75% of the people I've asked (who have gotten through a phone interview) cannot answer it with any ability.

People whine about the difficulty of interviews, but honestly, almost everyone we've ever hired have said the interview was pretty straight forward, and nervousness is the biggest issue. Sucky people whine about reversing a linked list or finding a cycle or whatever.

But this kind of thing may only be mentioned in one sentence in an intro computer systems course, and most young people wouldn't care about how many operations a CPU can do.

A similar question: approximately how many IPv4 addresses are there?

See also: "Latency Numbers Every Programmer Should Know"

The rest is fluff and hidden cultural test: "Do you have the same history as I do?"

TBH, I'm slightly disturbed by these "young people" who have completely no idea how machines actually work.

But the question is silly because there are better ways to ask people if they know in case you require that they know and you probably shouldn't be asking anything at all if you don't care if they know.

I agree with you here, but I would like to think if I were interviewing someone and they told me such, I would then ask something like "How would you go about finding this information out?", and continue down that line (I wouldn't just accept "I'd google it", I'd want something more in depth, even though that would technically be correct).

Personally, the question reads like "have you ever pieced-together a computer?" and one could argue that the question could weed out better candidates for certain positions. A growing number of younger engineers have only used machines that come glued-together, and never had to compare performance vs. price as they chose a CPU.`

> When the hell would you ever need to know that?

I find this such a strange perspective. You're writing code for a computer. Sometimes you need to estimate how quickly it should run, or else estimate how quickly it could run with optimal code. Surely it's obvious that knowing how fast your computer does stuff, at least within 3 orders of magnitude, is a necessary ingredient to make that estimate.

And yet in your mind that fundamental fact is "useless trivia." Very odd.

Anyway, my answer to the question would be, "a lot". You need to know the specifics of workload and cpu to be more precise.

The reason is that things today are "fast enough." These days most slowdowns aren't the result of the CPU not executing instructions fast enough. Other factors dominate, such as memory access patterns, network delays, and interfacing with other complex software such as databases.

Unless you are doing compute-heavy code, the speed of the CPU isn't much of a factor in estimating how fast the program will run.

I'm having trouble believing that people who think a CPU can do thousands of instructions per second will do well at this (or reasoning about the memory hierarchy).

You may as well ask any other sort of technical trivia question and figure the people that happen to carry around more random facts about tech are more likely to understand the bigger things that do matter. It isn't necessarily wrong it's a pretty obtuse way to make a judgment. Why not just ask them about the memory hierarchy or network delays or whatever directly?

I personally have no idea and it's the one computer I use most frequently.

That said, when I started using computers, my first machine ran at 897 Khz on an 8-bit CPU, and had 16k of RAM. I was 11 years old, and this was a pretty standard machine for the time, unless you had real money (and even there, on the top end - not counting minicomputers or mainframes - you'd be lucky to break 8 MHz and a meg of RAM).

But I know I am of a different era. And honestly, I've stopped caring about CPU speeds too, because lately they don't change much (top end is about 4-5 GHz per core; servers can have around 32 cores - though that is increasing too).

What should be cared about is memory usage per process, and how the software you are using (or which multiple people are using) delegates that out. For instance, with PHP (not sure with PHP 7) you have one process per user, and depending on how much memory those processes take, will ultimately lead to an upper limit on the number of users that can be served at one time. In that case, knowing your memory usage and constraints of the server could be very important (there are a ton of other factors to consider as well, I know).

Which really just demonstrates the point, I think. At some point things are "fast enough" that it just doesn't matter. We've reached that point with computers. Unless you are working in a niche field that needs serious compute, the sources of performance problems are almost never going to arise from issues like trying to execute too many add instructions in a given period. The delays will come from things that are significantly harder to see - network, database, or program architecture + runtime.

...and 640K will be enough for everyone!

He's more focused on the design and craftsmanship of the bookshelf, because he's built many excellent bookshelves to industry standard effectiveness in the past and measuring the number of screws he can turn in a second hasn't been relevant to the work.

> How many nails does it take to build a house? a) hundreds b) thousands c) millions d) billions

> How many rooms are in a house? a) tens b) hundreds c) thousands

> How thick is a house wall? a) inches b) feet c) miles

What I mean is that -- thanks to all the programmers of yesteryear -- most programmers operate at a much higher level of abstraction when building anything that big.

Apparently some people take whatever warm body shows up.

It would only be valid not to hire them if they have already taken measurements and noted them down. If they can't do the calculation to convert their measurements to square footage and then to linear feet of board (with margins to allow for different board widths) - that'd be something different.

Even there I would argue one could still say "I don't know", simply because you haven't specified how you want the flooring oriented per room/area (and if it goes on the bias, it gets tricky quick), or if there is any kind of special patterns or inlays you want, etc.

Until you have the full specification at hand, you can't really give more than a ballpark answer, which in the case of flooring calcs could be wildly off (agile doesn't really work for real-world engineering like it can for software).

Likewise, for the original question, I'd expect some sort of discussion or nuanced answer. Something like, "Well, most modern CPUs are rated at the GHz, so on the basic level, we can say on the order of billions of operations - but we're getting a lot more cores, and given SIMD and such, you could actually go an order of magnitude or two over that, in theory. But if you are doing something that takes lots of clock cycles, it could drop down into 100s of millions, I suppose."

What you don't want to hear is a deranged ranting, like some people are doing in this very thread, or "I dunno" and a blank stare.

And again, none of that knowledge is relevant or required to be very competent at web development.

The equivalent question to a web developer would be how many lines of code would it take to make a bare bones site with a calculator in it? 1,000? 10,000?, 100,000? Options A and possibly B (with explanation would be acceptable).

Your question (although you don't seem to feel this way) is the equivalent of asking a carpenter: How many Watts of power will you consume while finishing this room? A carpenter who knows that may show lots of curiosity about their tools, but there are also plenty of skilled carpenters who don't know the answer to that.

Your interview question is more asking "How similar is this person to how I approach things?" than "How skilled is this person at doing their job?"

(1) because "it is faster" and "my dad always did this" and "you don't pay for my saw, so shut up"

They do make such blades for angle grinders; they tend to be "universal" blades to cut wood, metal, and ceramic/brick. There are also "chain" blades, which are meant for high-speed carving of wood (they look like a chainsaw chain wrapped around a circular blade).

Likely, if you really wanted to do it and had nothing else handy, a cutoff blade would probably cut wood just fine (take care to watch for too much friction, though). Alternatively, a circle of file folder paper chucked in would work as well.

Usually I can guide them to understand where the bottleneck is, but every so often I have to rewite it so performance is acceptable.

I would absolutely ask a carpenter how quickly he can complete a project, and I would hope he has a realistic first order approximation of how fast he can complete (process) screw driving tasks.

That said, I disagree with the question being discussed here, because I'd rather just ask him about his speed and performance; I wouldn't ask him how fast he can screw things in :) (that's a minute detail compared to the actual work).

This is the sort of question that reveals the ignorance of the person asking it. The correct answer is "yes". What is 'modern'? There are very modern embedded CPUs that operate in the low MHz range. How much power is being provided? A 'modern' CPU can be underclocked to ridiculous levels for power savings. What's an operation? Are we talking MOV AX, 1 or are we talking hashing a string?

It's the kind of question a dumb person asks thinking they're being quite clever.

And thanks for calling me dumb!

You're the type of interviewer I would weed out, so by all means keep asking the question.

I also realized how different schools emphasized computer architecture differently for CS graduates. I remember having to design a simplified PDP-11 in Computer Architecture. We had to take assembly language and such. But that was one specific college and I shouldn't assume all of them do that.

Eventually I moved away from such questions and took a more collaborative approach such as "let's solve a problem together". So I'd stand beside them at a whiteboard and we think through problems. I think that puts candidates at ease and it reveals more of the skill and personality traits that were relevant for us.

No Overlap -- EDa < SDb OR EDb < SDa

Overlap -- SDb <= EDa AND SDa <= EDb

I have this written on a PostIt in my binder.

The solution is a simple predicate. Assuming both events are internally consistent (i.e. end time after beginning time) they won't overlap so long as the beginning of the first comes after the end of the second OR the beginning of the second comes after the end of the first.

Seems like a good weed-out problem.

Disclaimer: no prior experience with the problem.