Hacker News Reader

Comment by pklausler | Hacker News Reader

The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer.

Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No loops, no fancy algorithms, no tricks... and asking it has not been a waste of time. I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality; I get multi-line predicates full of redundancy that still yield false positives and negatives; it's depressing as hell.

View on HN

It's all fun and games until one of your appointmets is specified in rfc2550 format, and the meeting room is on a big ship crossing the international date line on the same day daylight savings time changes for the ship's country while a new timezone is voted into effect. Meanwhile the other meeting room is a videoconfrerence between the international space station and a ship travelling at close to the speed of light, but the real twist is the two meetings don't actually have anyone in common!

Also keep in mind Heisenberg while traveling along state lines.

Also the meetings are in different rooms with entirely different attendee lists, so whether they conflict or not is irrelevant.

Unless there is some other mutable state that they both interact with that may cause a race condition. :)

I used to disbelieve hiring managers regularly encountered candidates who actually couldn't code, or whatever other basic technical thing was reported on their resumes. Such a possibility - even the audacity of it on a conceptual level - simply seemed beyond the pale for me. I had interviewed before and not done well, and that I could absolutely understand. But I had no way of relating to the idea of someone entering an interview without the fundamental mental schema requisite for doing the job.

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.

Let me ask: what company do you work for and how much effort does it put into finding, attracting and most important! retaining! people who are any good?

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'

Attracting more good people won't reduce the number of bad applicants (it will increase it).

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.

I can think of half a dozen ways to attract applicants in a way that'd significantly increase the quality of the applicants while at the same time significantly decreasing the number of the applicants.

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

> I can think of half a dozen ways to attract applicants in a way that'd significantly increase the quality of the applicants while at the same time significantly decreasing the number of the applicants.

Like what?

He would have but they were too large to fit in the margin...

Original comment poster here.

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.

I experienced the exact same feelings as you. Until I started interviewing candidates in quantity, I had no clue how many candidates cannot complete FizzBuzz. The reported failure rates of this simple test are completely legitimate. In my own interviewing, it comes out at about 50/50. The 50% who do pass often make some significant conceptual mistake, for which I'm generally pretty forgiving since interviews can be a stressful experience. This question comes at the end of a hiring pipeline that does 2 phone screens before the on-site happens.

Do you actually use the real well-known FizzBuzz problem, or some other exercise that you think is comparably trivial?

I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?

Sounds like an effective filter to me. Where I work, this would be the first part of one of the interviews, with the second part being something more like "Given a list of calendar appointments, what is the maximum number which can be attended without conflicts?"

don't you need a little bit more info about that list of calendar appointments? like at least an assumed time length?

(assuming the list happens on the same day)?

Yeah I was thinking each appointment had a start time and end time.

> not fully thinking it through

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.

I don't think it's a bad question to ask... just not the filter that the op thinks it is. all these people who are sitting in the comfort of not being in an interview and they are still getting it wrong. this filter should be easy enough to get the question right if you know any programming at all. something like the fizzbuzz question.

I highly doubt I would ask if the inputs are sorted. I wouldn't expect them to be (why would they be, after all?), and I'd probably just give a solution that works regardless.

I think you just received some good interview advice, unintentionally.

Not for interviewing for a company with reasonable interview practices.

I agree. Also, since we're talking about two entries here, there really isn't much work to do...

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

If you want to test for the ability to gather requirements and clarifications from vague requests, then test for it directly, don't bake it in as a hidden test you expect people to account for when the overt problem is just implementing a comparatively crystal clear toy question even if you say things like "number" instead of "positive integer". Assuming they can implement anything that seems to work at all (which is your main goal, right? or why ask it?) you could turn your prior vagueness into an opportunity to see if they can formulate test cases and refactor their approach to account for different inputs, if needed, or if you see them accounting for them as they go you can ask e.g. "why are you taking the absolute value?" and see if they're thinking about the input order or if they're just doing it because that's what they saw somewhere.

Yeah, I think the important thing is that the candidate should not have to "read the interviewer's mind" when it comes to what style of question is being asked.

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.

Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?

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.

Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet. That's why I think rejecting a programmer for losing their core competencies like problem solving, i.e. freezing, under a medium amount of pressure is valid.

I've been a developer for years and worked for multiple companies: the most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10.

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

Same here, and have worked on some extremely high-profile, complex things. Never _ever_ have I been as stressed as when asked to perform interview whiteboard questions. It simply doesn't compare.

Sometimes, you just have to appreciate the Torvalds-level of arrogance expressed in some of replies on HN.

You're reading too much into it. That wasn't Torvaldsian at all, by my reading.

The most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10.

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.

It really depends on the job. stress in general is one thing but stress on a pedestal is another. some types of people(programmers fall into this category often) are not good at embarrassment so they shut down and can't think. it's not bad because they can be brilliant without the social pressure but with that they are not ideal. if the job doesn't have that requirement it's silly to drop them for it.

"time matters and you have to think on your feet"

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

I once spent 2 days troubleshooting a machine vision system at bolt factory. Physically in the factory. On my feet. Standing behind an active vibratory hopper filled with bolts, while stake-holders were losing money hand-over-fist, and angry machinists who looked like a motorcycle gang stood next to me. And it was a Windows NT machine.

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

Yes, and I've set up a demo of an interactive TV system in a cupboard at a large London hotel (standing room only!)...

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

I once had to diagnose and fix a bug in a financial system that went belly up under extremely heavy load -- causing the company lose tens millions of $'s per hour (literally). Turned out to be a timing problem caused by satellite comms latency. The solution required us to modify how a couple different algorithmic worked. That situation was highly time sensitive and over-the-top stressful (for me anyway).

I'm sure you would acknowledge that's a very exceptional situation, right? That's the point of this whole subthread: that this kind of stress is exceptional in a work situation.

I would agree that it was exceptional. But I would also argue that how your people perform during exceptional situations is what makes or breaks teams and companies.

No one doubts that performing under pressure is important.

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.

This is far too much of a simplification of (grand)Parent.

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.

> 30 year old programmer with a 2 year old child at home ... nix him on the "merits" of ageism

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.

Most programming jobs do not actually demand one make this form of Sophie's Choice. Perhaps the Valley is so diseased, but it's not the only game in town.

> Perhaps the Valley is so diseased, but it's not the only game in town.

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

And now imagine you have 4 little kids like me and how that affects the equation! You want me to move out to Seattle, Amazon? Do you have any idea how much you'd have to pay me to have anything like the lifestyle we have in the Chicago suburbs?!

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

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

What I've noticed often with coworkers, and even myself at times, is that management often won't do anything to discourage your workaholic tendencies - but it was never actually an expectation in the first place - just a belief in the employee's head that it's what's required of them.

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.

The kinds of pressure are different - unless if at your organization you do your time-critical coding in front of a panel with varying mixes of what looks like disappointment, boredom, impatience and eagerness to "give you a hint" on how they would solve it while thoroughly confusing you. If not, you are measuring the wrong metric to gauge potential candidate success.

Such kind of situations are very common where you are relatively new, handling software for a safety critical system and entire production line is shut down due to some exception occurring in large complex hard-real time multithreaded s/w module developed by some past ghost employee who has forgot to comment the code with no documentation available and the plant manager is banging your head for downtime loss!

I don't put out fires under the watchful eye of a would be colleague or employer.

Some developers are expected to work on the systems that processes a bajillion dollars of whatever per day and when it screws up they are often on the line for it.

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

Right or wrong, in some systems when something goes wrong, somebody dies. At some point, there's somebody on the line for that, whose responsibility it is to say "This code is good enough".

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

> Right or wrong, in some systems when something goes wrong, somebody dies.

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 stressful situations tend to be things like "We just broke the production database, we need to figure out how to recover the data ASAP"... not "We need a new algorithm in FIVE MINUTES!"

The interview question I was referring to is the appointment overlapping one. It's a middle school math question and it's a lot easier than failing over a database without data loss.

I've been doing this for 20 years and I'm not even sure where I'd start on your middle school math question. I hate working with calendars and dates and I don't think I know anyone who enjoys it and can write totally bug free code that takes care of all edge cases.

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.

Don't over complicate it. Given two number ranges, of UTC timestamps, determine if they overlap. I think you know where to start with that.

I'd probably go for 4 if() checks, some 'less than'/'greater than'/'&&' checks should do it.

>We just broke the production database, we need to figure out how to recover the data ASAP

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.

>Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet

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.

Do you work on services that are expected to be working 24/7? It's not exactly uncommon for a production service to have problems and need to be fixed ASAP.

Do most programming jobs expect that? I think not.

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.

It's not exactly uncommon for a production service to have problems and need to be fixed ASAP.

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.

Why not go all the way, then?

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.

Relevant comedy skit: https://youtube.com/watch?v=iRtBvo9grLw

Being a professional programmer is not an entirely stress-free job.

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.

> Being a professional programmer is not an entirely stress-free job.

understatement of the year.

This is why it's important to start the interview with culture/work history questions to probe how they're feeling, watching their body language, before moving on to simple questions of increasing complexity.

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

This is the way to go.

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.

I wonder how all those people unable to answer interview question passed school.

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've had it happen - just in my past job search the past few weeks, I had a total blankout in my last Google interview session in person on a dynamic programming question, and I'm pretty sure that ended up being the reason why I got rejected as I felt pretty good about all 4 of my prior sessions.

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.

I know it happens, but I don't think it happens to majority of people. Bad days are caled that way because they happen once in a while, not constantly. You had good three interviews and one bad at Google. You passed well at apple. That really sounds like bad day.

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.

I disagree - different people could have dufferent triggers for a fight or flight response. For one of my best friends, anxiety is her trigger.

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 agree, but here the topic is simple question being considered unfair, because someone might be too stressed. I would argue that asking questions is not unfair level of stressing people.

It's not simply a matter of "asking questions". It's about getting asked (often gratuitously difficult)† in an intrinsically awkward and confrontational situation -- quite often by someone who not only might not have adequate social skills for the task; there's a good change they may not really know why they're asking that question of you in the first place.

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

This thread is about calendar question - figure out whether two appointments overlap. That was not open problem for years and you should not need to memorize solution to solve it.

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

> but I don't think it happens to majority of people

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?

Observation after seeing countless schoolmates answer questions for grade. There were only few people that would be blacked out regularly no matter what age.

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.

When people are actively watching me to judge me, my brain just goes blank. It's happened to me almost every time in technical interviews where I was asked to solve a problem in front of the interviewers, and it's happened to me at school too in oral examinations. Written exams were not a problem.

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.

Suffering from the same problem, though it happens to me even in written exams - doing something for the sole purpose of being judged makes me incredibly uncomfortable, and I'm happy to be out of school/university and just have a job. It's all just infinitely easier and less stressful, even at the worst of times and with the worst of people.

Momentary blackouts happen - rarely.

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.

>> "Thinking aloud" ... is a specific metacognitive skill

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.

I think psychology has a lot of models of cognition without a clear winner, so there's probably no conclusive answer at the moment.

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.

the idea to "think aloud" is downright silly.

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.

Let's just say that it's at best a corner case in the the toolbox of approaches our brain has for tackling problems. Yes, it's something we make use of once in a while. But more like a "caught you in the hall, here's my idea" approach. Never in a "solve this now in 5 minutes or yer OUT!" sense.

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.

This point cannot be underemphasized.

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

I agree. Most companies screw themselves with the technical interview by giving it. I give something simple like FizzBuzz and that's it. My big questions is: "What was one of your favorite projects and what did you do?" That will tell you everything I need to know.

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 think you have it the other way round.

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

It's also much easier for introverts. They can talk about something that is not themselves and something they know very well. They can now expose many interesting and subtle details of their craft.

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

Yes, this. Most introverts I've known will talk endlessly about stuff they like. Ask an introverted Star Wars geek about Star Wars. It's the meaningless smalltalk they have trouble with.

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)

Bad idea.

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.

But you could tell something was fishy by listening to him. You said you got the impression he taught the whole story rather than lived it. That's exactly what you are looking for; that's why it's so valuable. A real developer can tell when someone is bullshitting him in about 3 sentences.

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.

See "Embarrassing code I wrote under stress at a job interview" which was discussed on Hacker News here:

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

It's actually a tricky problem to think clearly about unless you start enumerating the cases, or get pen and paper out to draw some boxes. I don't think it's completely trivial to verbalise. But I also don't think a competent programmer should fail to work it out.

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.

It may be easier to verbalize than we think. I just realized that for me the trick might be to not be too abstract and formal when first thinking it out, but look at it more like an everyday problem.

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.

Funny; for me, the abstract version is exactly what I need. And the answer pops out almost immediately:

  B <= C or D <= A

(Assuming A <= B and C <= D, for which I may ask the interviewer about.)

I have similarly asked "write a function, minimum(), that takes a list of integers and returns the smallest integer in the given list" for quite some time. It's disturbingly effective.

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

Funny, I remember being blown away when somebody asked me this question on my first internship interview. Only later I read about FizzBuzz and became enlightened ;)

A decently clever candidate could sneak out of that first one without a loop. Something like

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

would do it in JavaScript. In general, if a candidate realizes they can use reduce for that purpose, in my experience interviewing candidates they probably wouldn't have much trouble doing it with a loop, and it would usually be a signal they're going to have a pretty good interview.

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.

I find that's a telling way to determine the experience of the interviewer. I'm saddened by the number of times an interviewer has asked me, "What is a reduce? How does it work?" Of course, that information isn't very helpful in the flow of an interview, it's mostly just upsetting.

As of yet, nobody has used reduce(). If they did, and especially if they followed it with a coherent explanation of what reduce does & how it worked (and convinced me they've not memorized reduce for a singular purpose, but understand it well enough to apply it generally), I'd definitely accept it.

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.

The whole for loop thing - absolutely!

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.

If those people really "sailed" through your phone interview and technical discussion there is something very wrong with your phone interview format and technical discussion methods.

That's a good point, and I don't really understand what we were doing wrong.

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.

This is a trigonometry question, not a C or programming question.

Depending on what you're hiring for, it's really not all that depressing.

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

Making sense of his codebase is harder then writing from scratch. Maintenance programmIng requires a lot of puzzle solving. What it does not require is modern technology. E.g. maintenance programmer should answer this question easily and have problem it you ask about react.

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.

Determining if two intervals overlap is not a trivia question but a trivial question for a programmer and hiring people who can't do better than O(n²) probably is good only for really boring maintenance projects where the workload lags far behind Moore's law.

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

What do you think n here is when you say O(n^2)?

The number of seconds in these intervals, see the top level post.

TIL building products that make money (as opposed to pre-revenue VC-funded CRUD apps) with a team that enjoys their job and can be home by 4 every day is not "real development."

Not all teams that do what you suggest write garbage code as the GP implied. I have worked a places with large garbage and excellent code bases.

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.

Thats actually a really interesting way of interviewing, and probably matches the way most people have to work.

> given the starting and ending times of two calendar appointments, determine whether or not they conflict.

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.

Consider appointments from 1-3 and 2-4:

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

Do they conflict?

It's difficult to tell if GP miswrote, or you misunderstood, but it doesn't sound like they've made the mistake you're alluding to (I would expect them to be explicitly wrong).

Hmm.. Perhaps I did misunderstand something. But if the test for a conflict is:

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

Yes, I do not think "and" here was meant as a logical constraint.

The test is the opposite of (X ends before Y starts) and (Y ends before X starts). You only need two comparisons.

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)

As long as (xb >= ye or yb >= xe) there's no conflict. You can flip those: (xb < ye and yb < xe) to get the conflict condition.

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

So you only need two comparisons, and an and operation.

Yeah, you have it right. I had a nagging feeling that two comparisons ought to be enough, and something was just reversed in bumbledraven's formula. My first thought was that the 'and' should have been an 'or', but that was wrong. It was the comparisons that were reversed, as you demonstrate.

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.

Just make sure your data is correct, and a single comparison works: https://gist.github.com/anonymous/c02d74eb75a51dce8dcbc027a3...

Your code has two comparisons; one to figure out which one starts first, and another to figure out whether the first one ends before the second one starts. This isn't getting your data correct; knowing which one comes first isn't part of the problem description :)

It appears what they're alluding to is this part: > the appointments conflict just when b > c and a > d.

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

You have a mistake in the last not of your formula. The opposite of d<=a is d>a, not a>d.

This mistake could be made more "eyesoreous" and possibly avoided by naming the begin/end times b1, b2, e1, e2 instead of opaque letters. I would fire the OP for that alone :p

do you mean "b > c and d > a"?

If you were writing code, I would argue against using De Morgan's laws just because you can.

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

Usually after a mathematical simplification like this, you can find a direct explanation for it. In this case you can reason:

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

I would say, if the transformation makes the code and the reasoning behind it simpler then do it. Otherwise, know that any decent optimizing compiler can do this trick by itself so what you write only influences readability.

If one appointment is wholly contained in the other, then b > c and a < d.

The most logical and clear answer for me (assuming I didn't already screw up by making assumptions about the data format, problem definition, etc.) is:

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;
    }

That can be shortened to:

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

Or shortened even further in https://news.ycombinator.com/item?id=14641485

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

Personally I find the first version a bit hard to follow, and the second one makes my head spin.

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
  }

I think it reads fine as a single expression too, given an appropriate comment explaining the idea (which you'd want anyway):

  // 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;
  }

And here is the matching function to go with either of those:

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

The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right.

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.

But if you can't do the calendar question and realize within (lets be generous) 3 minutes that double nested loops are the wrong approach... I think it'd be fair to question your abilities.

Having had the chance to do some interviewing over the last few years I think the most important thing on my side is to know what I'm trying to test for with any particular line of questioning. I don't always see that level of self-awareness in fellow interviewers. (The worst is the sort who say "if they don't do X when I'm asking for Y, I'm going to score them down." Do they really care about Y then?) What exactly is gained by letting the candidate go off into the deep end for several minutes before they realize on their own, if they ever realize at all, that their initial approach was bad when it should be a simple question? If the purpose of a calendar question or fizzbuzz question (or my own initial coding question, "implement is_even") is to answer "can you code?" why does it matter if the solution isn't that great? If you have an answer to the question you can follow up with things like "can you code a better solution?" to distinguish passes, but interviewers should keep everything time boxed, there's other stuff to cover with such short time slots as 30-60 minutes. I like to test some sort of presence for knowledge about regexes and recognizing an application, so I borrowed Yegge's phone number regex question from his phone screen tips, and I'm happy enough if the person realizes that "there's some sort of pattern thing to do this" because that's a google away, happier if they can write a script that uses regexes correctly, happiest if they know or get close to the grep incantation, but if they start trying to write their own parser I'm going to stop them because that's going to take a lot longer than 10 minutes, especially if I say "oh yeah there's another number format we need to extract". But that person still might be a good hire, just not knowing about regexes at all. By keeping things time boxed I can make sure all the other areas I care about are covered and can judge if certain strengths can compensate for certain weaknesses.

Yeah, instead it's like: "Here's an interesting question that I like because I feel I already understand it well. Let's see what they do with it, and then I'll go with whatever gut feeling I end up with. This is easy, I'm a good interviewer."

Here's a tip: most live programming interview questions should be answerable within a few minutes. Any approach that you think will take a half hour is the wrong approach.

"Any approach that you think will take a half hour is the wrong approach."

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

If the candidate starts by drawing 2 lines, then marking start and end on the lines, you know you would be off to having a good chat

My thoughts exactly. Defining the problem space and all possible cases is the key that so many people miss. Once you do that, the solution is just Boolean logic.

To have a good chat I would hope they drew a coordinate system, mapped both appointments in Euclidian space, and then did an intersect between vector A (first appointment) and vector B (second appointment) to see if there are any data points in common.

What does this mean?

For a good discussion, instead of looking at the problem strictly programmatically, you could look at it as something you could map in vector space.

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.

This problem is solved with a couple of simple if statements. Finding a "solution" that is more complex than necessary or introduces knowledge that really isn't needed is the sign of a programmer who... over-engineers and is likely to be a detriment.

I assume that the question is meant to give insight into how they solve a problem that on the face of it looks straight forward?

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.

If one meeting ends at t1 and the other meeting starts at t1, do they conflict?

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?

Asking questions like that can, all by itself, be a correct answer to the question.

I'm not a programmer but wouldn't

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

work? Assuming time is encoded in epoch format.

And assuming that "1" and "2" refer to the appoints in order of start time, but they may not be given in that order.

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

That's half of it, but doesn't account for the case when starttime[1] is later than endtime[2] and they don't intersect.

Good point. I didn't think about them not being written down in the list in chronological order by start time.

It works if you assume that appointment 1 starts before appointment 2 starts (or if you explicitly sort them by start time).

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│
    └──┴────┴──┘

This is close but you need to ensure the start time is before the other ends, and test for the second one starting before the first also. There's four cases:

[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

> if appointment1.end > appointment2.start OR appointment2.end > appointment1.start // conflict

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 cases don't consider [1 start][2 start][2 end][1 end] or the opposite, but your pseudocode still covers those cases.

True, I didn't include those cases as they are not unique in terms of why there is / isn't a conflict. But you're right, worth including for completion.

> Your cases don't consider [1 start][2 start][2 end][1 end] or the opposite [...]

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.

Does anyone really test for specifics like this? I thought the goal was to ensure the candidate understood that dates and times are abstract numbers, anyone that applies a mathematical operator should pass it. Yes this would still filter out a lot of people.

Or just sort by start time, then do the simple check.

Yeah, this is way easy if the two events are sorted by start_time first.

I was thinking along the same lines as you, but it turns out you only need two comparisons and one logical operator.

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

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

The only predicates are: a < A, b < B

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

To find whether a and b intervals overlap (ends are not included):

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

Why is it downvoted? The formula is correct and it is simple -- if you don't understand it, just ask.

I'd say so. The "assuming time encoded"-bit is important though - I rather think starting with the data is valuable:

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

This is a great example of why the OPs question could be a good or terrible interview question -- it's not clear if they want the obvious technical solution (comparing datetimes) or a wider discussion about "what is a date time and how is the data represented", "what are the real world / business implications", "here is existing technology using intervals that will solve it" etc as you mentioned.

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.

My company asks a question during engineering interviews that is overly simple, but a bit vaguely defined on purpose. The main objective is to see if they can ask clarification questions to determine precise requirements, which is something that every engineer does daily on the job.

> I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality

Mother of god

I think many companies hire with the number one goal of reducing false positives. By definition this approach is going to unfairly reject a number of candidates. I would argue that it also dehumanizes a number of candidates, forcing them in aggregate to play a numbers game until they are in the top 20%-40% of the pool (if they ever get there) where companies then begin vying for them.

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

> By definition this approach is going to unfairly reject a number of candidates.

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.

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

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

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

A weeder question I've used:

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.

Used that on college graduates. I was surprised how many couldn't answer or reason through it. Even the ones from top CS schools.

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.

When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.

Well does it take about a second or about an hour to make one turn of the screw? If a carpenter doesn't know the answer to that in his bones, he won't be fastening many things together.

It takes significantly less than a second to turn a screw once. A couple orders of magnitude less actually, to give it some relation to the computer question.

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.

> At some point things are "fast enough" that it just doesn't matter.

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

The carpenter may simply know that turning the screw is imperceptibly instant in his experience, and that if the bookshelf isn't getting built quickly, the bottleneck is virtually never because he's waiting on screws to be turned. He's going to have to make a trip to the store anyway so he isn't concerned with whether turning the screw requires a tenth or a thousandth of a second.

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.

If he is good, he can reason about it on the spot. If he can't, I very much doubt that he can design anything excellent. That requires critical thinking to understand what it is being used for, what is good, and importantly what solutions are unsuitable for the problem he is trying to solve.

Sure, although I was addressing the parent comment, and more specifically, "knows it in his bones."

Whether this is a good interview question I don't know, but:

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

I agree that it is "useless trivia."

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 not infrequently surprised how people don't spot that something is orders of magnitude slower than it should be or pick the wrong architecture because they can't or won't do simple mental math to work out very roughly how long it should take to move some data around in memory, ssd or over the network or perform some simple computation on it.

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

I don't think there's much predictive power there. The people who are answering thousands clearly just haven't though about it before and are on the spot. Humans are just terrible with big numbers, and thousands sounds like a lot already.

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?

Unless you are writing assembler, speed of your code is very distant of instructions. You don't count instructions when estimating speed. Not in higher level languages, not when working with database and definitely not in something like javascript that runs in browser.

I see your point, but hardly anyone counts "operations" anymore. Besides, what even is an "operation" on a modern CPU? You could say, an operation is an entire CPU instruction, but the truth is that the instructions you see in assembly files are not really that atomic. So then do you count each microcode instruction as an "operation"? But even then the question is impossible to answer, because depending on the type of workload your execution time will vary significantly. For example, straight up doing math with some registers will always be faster than reading/writing memory, and reading memory in a cache-friendly way will be faster than jumping all over the place, etc.

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

What is the clock speed of your iPhone or android phone?

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

My phone, and your phone too (possibly) is something like 1.2 GHz per core, with 4 cores; most phones have a similar spec (and those numbers are going up, too); basically figure 1-2 GHz per core, with 2-4 cores generally.

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

No, it's more like asking a roofer how about the area he can cover with shingles per hour. Information of vital importance.

Let's be real, if a roofer was asked anything comparable to a programming question it would be to provide an accurate approximation of the total number of roofing contracts completed globally within the last half-minute on the back of a coffee-stained napkin.

But that's not what's being asked by OP. Their question is rather simple, and software engineer should be able to answer it on autopilot, without even engaging her brain. As a hiring manager I would end the interview right there and then after the failure to answer something like this.

As an interviewee, I would roll my eyes at the ignorance of the interviewer.

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 low Mhz range is in the millions, which they said they would accept as an answer with that explanation.

Clock rate != operations. It's like you didn't bother to read what I wrote.

Closely enough related to number of basic operations though I'd say. I'll agree with you if it really just is a multiple choice question without context, but the initial poster did not present it that way, but said that explanation/discussion matters. And then your objections are a good starting point for that.

The worst thing you realistically can do to stall your CPU is miss cache every time you read data from RAM. If you do this for every instruction (which would be quite a feat in itself), you divide your instruction throughput by about 200. But even then, and even on the shittiest modern CPU you'll be retiring millions of instructions per second.

The MSP430, released in 2010, can be clocked down to 32kHz. That's pretty much the state of the art in modern, low-power devices.

And if you know that, I'm pretty sure you'd pass that interview.

And you are one of the types of person the question is meant to weed out - people so threatened by a simple question they get defensive and hostile.

And thanks for calling me dumb!

Thanks for projecting 'threatened' onto me!

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

You don't, but if you found that a candidate carpenter couldn't tell you whether they could fasten 10 or 10,000 or 10,000,000 screws in a one-hour period, you'd start to doubt their ability in general.

It's absolutely relevant. On more than one occations I've had performance issues land on my table with the developer that wrote the code saying "it's not that bad, it's going through 100.000 elements". They simply don't have a relation to how much a modern computer can do in a given timeframe.

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

No. Here are possible carpenter equivalents, all of which I'd absolutely consider a minimum low bar...

> 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

Number of nails as analogy for CPU operations? That's not hiring a programmer, that's hiring a computer.

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.

When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.

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

> When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.

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.

That's not the correct analogy, because the carpenter uses the screw driver as a tool, not as a platform. The screwdriver is analogous to code, not the CPU.

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

Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them.

Apparently some people take whatever warm body shows up.

> Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them.

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

And because of that the kinds of answer we would expect from such a carpenter in that situation is, "Hmm ... how big is the room and what size of board are you using? 2 inch, 3 inch, 5 inch, or so mix? That's pretty popular these days. How much extra do you want - I usually recommend 15% so you have some in case you need to repair."

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.

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

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

The question may be to asses tech-savvy-ness of the candidate (i.e. if he/she knows the SI prefixes, what the range of the modern CPU frequencies is and how do those values reflect on computing performance). There is one kind of programmers that learned their trade just to make a buck and don't care much about their working tools, and there is another kind that finds interest in computers in general. Interviewers may prefer the second kind.

I feel like that's a bad question to ask. An algorithm question at least lets you attempt it and you can see if they know things. But this question isn't something that people normally talk about or think about. I think older engineers would think this is a normal question to ask since they/you have seen the evolution of computers over time, and have actually seen the number of operations changing to get into the billions.

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.

They might not care, but in that case this question essentially tests if a person understands what 'GHz' means and can think logically, which is not that much to ask.

Why would web programmer think about processors and GHz is beyond me. There are jobs where it might matter, but for most of them it is completely irrelevant.

When youre writing a complex SPA app and your performance is dragging on that cheap Android, it's nice to be able to reason about things like clock speed, memory usage, etc.

I know we can treat a lot of the technology we use as a black box, but not knowing even the basics of that technology indicates a lack of curiosity. I'd be shocked to find a competent programmer who couldn't answer the question.

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

See also: "Latency Numbers Every Programmer Should Know"

They might have been curious about different things then you. Or more interested in knowledge that helps build stuff ( still constantly learning, but choices are different).

What's next? We shouldn't expect programmers to be aware of how characters, integers and floating point numbers work on a computer?

If they work in high level language that hides all that behind "number", who cares. How floating point numbers are represented is interesting trivia, but hardly useful in most situations. In general, I would expect people to remember things that are used often and be able to learn the rest fast (e.g. understand concepts and have enough knowledge to make further learning easy).

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

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

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.

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

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

So you would be completely comfortable interviewing someone that claimed to have done 10 years of systems programming, including optimization, and yet when asked that question, just shrugged their shoulders and said, "I dunno"? Even if you asked them how fast a modern processor was and they still said, "I dunno"?

In your scenario, the question makes sense.

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

Realistically it's a) since everyone needs to go up to the cloud and back these days.

This question is trickier than it sounds. Sure 109 clock cycles per second, but estimating for actual human-perceived ops for an algorithmic problem one should use 106. (Source: USA Computing Olympiad problems.)

Would you mind explaining in a bit more detail what you mean here? I'm not quite sure where you're getting those numbers from.

They mean 10^9 and 10^6, and that each "operation" in a complex algorithm is often something like a hash-table lookup, which may be constant time, but takes closer to 1000 clock cycles than 1.

Ahh, I got it. For whatever reason I didn't associate 109->10^9 and 106->10^6.

No worries, it took me a little while to figure out, too.

We totally would interview someone that responded as you did. Thing is, I'd say roughly 50% of the people that applied for the position would respond with something like "I dunno" or "A" and be unable to have any sort of rational discussion about it.

Technically, all three answers are correct. (A) is correct because a modern CPU CAN perform Thousands of operations per second.

Not if it is turned off.

Well...this questions seems to be OK for phone interview for entry level programmers who should know MIPS, CISC/ RISC architecture basics. I would ask such questions to fresh graduate who is supposed to be working on firmware level stuff like writing custom co-operative multitasking schedulers, OS routines, device drivers etc. Probably this type of question is not suitable for a web developers or Data analyst/ scientist

One question Ive been asked I really like is: write a program that print the odd numbers between 0 to 100.

It's telling that I can't even read a problem as ostensibly simple as this without wondering if there's some deceptive special case I haven't considered.

Given two StartDate values (SDa, SDb) and two EndDate values (EDa, EDb) of a fully qualified date type:

No Overlap -- EDa < SDb OR EDb < SDa

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

I have this written on a PostIt in my binder.

The funny part is I reckon you would struggle to answer the question yourself when put on the spot, if you had no prior experience of it. Just my opinion of course and I am speculating.

What's your basis for that speculation?

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.

Reply on news.ycombinator.com