21 ms·

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 awes

• ionwake 9y ago
  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.
  • kornish 9y ago
    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.
• ben_jones 9y ago
  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...
  • pc86 9y ago
    > 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.
    • vonmoltke 9y ago
      > 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.
      • kudokatz 9y ago
        > 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.
• pinot 9y ago
  I'm not a programmer but wouldn't if (endtime[1] > starttime[2]){status=conflict} work? Assuming time is encoded in epoch format.
  • dragonwriter 9y ago
    And assuming that "1" and "2" refer to the appoints in order of start time, but they may not be given in that order.
  • rezashirazian 9y ago
    also if (endtime[2] > starttime[1]){status=conflict}
  • dcwca 9y ago
    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.
    • pinot 9y ago
      Good point. I didn't think about them not being written down in the list in chronological order by start time.
    • hoosieree 9y ago
      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│ └──┴────┴──┘
  • deleted 9y ago
    [deleted]
  • aldarn 9y ago
    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
• bumbledraven 9y ago
  > 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 https://en.wikipedia.org/wiki/Negation#Distributivity) to arrive at this: the appointments conflict just when b > c and a > d.
  • Stratoscope 9y ago
    Consider appointments from 1-3 and 2-4: a = 1, b = 3, c = 2, d = 4. Do they conflict?
    • tkxxx7 9y ago
      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).
      • Stratoscope 9y ago
        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 https://news.ycombinator.com/item?id=14641043 (no fair peeking!)
        • tkxxx7 9y ago
          Yes, I do not think "and" here was meant as a logical constraint.
        • 9y ago
• venture_lol 9y ago
  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
  • mpetrovich 9y ago
    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.
  • marcuslager 9y ago
    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.
    • poikniok 9y ago
      What does this mean?
      • marcuslager 9y ago
        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.
        • 4ydx 9y ago
          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.
    • deleted 9y ago
      [deleted]
• barrkel 9y ago
  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.
  • Stratoscope 9y ago
    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.
    • loup-vaillant 9y ago
      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.)
• alexashka 9y ago
  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 :)
  • watwut 9y ago
    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.
  • qb45 9y ago
    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.
• weaksauce 9y ago
  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?
  • nwjtkjn 9y ago
    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?"
    • bryanrasmussen 9y ago
      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)?
      • nwjtkjn 9y ago
        Yeah I was thinking each appointment had a start time and end time.
  • et-al 9y ago
    > 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.
    • weaksauce 9y ago
      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.
• deathanatos 9y ago
  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…)
  • qb45 9y ago
    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 ;)
  • rpeden 9y ago
    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.
    • WorldMaker 9y ago
      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.
    • deathanatos 9y ago
      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.
• gilbetron 9y ago
  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.
  • rdtsc 9y ago
    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.
  • symlinkk 9y ago
    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.
    • adrianratnapala 9y ago
      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.
      • fghvbnvbnfe 9y ago
        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.
• FT_intern 9y ago
  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 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.
  • Stratoscope 9y ago
    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 ); }
• missblit 9y ago
  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!
  • std_throwaway 9y ago
    Also keep in mind Heisenberg while traveling along state lines.
  • pc86 9y ago
    Also the meetings are in different rooms with entirely different attendee lists, so whether they conflict or not is irrelevant.
    • kbsletten 9y ago
      Unless there is some other mutable state that they both interact with that may cause a race condition. :)
• std_throwaway 9y ago
  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?
  • taneq 9y ago
    Asking questions like that can, all by itself, be a correct answer to the question.
• hvidgaard 9y ago
  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.
• pc86 9y ago
  > I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality Mother of god
• macca321 9y ago
  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.
  • rubidium 9y ago
    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.
  • Jach 9y ago
    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.
• quadcore 9y ago
  One question Ive been asked I really like is: write a program that print the odd numbers between 0 to 100.
  • hhmc 9y ago
    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.
• dsacco 9y ago
  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.
  • alexashka 9y ago
    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'
    • Ntrails 9y ago
• anshou- 9y ago
  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.