10 ms·

One time a company I interviewed with asked me obscure algorithm questions about playing card shuffling. As a former professional magician I knew the optimal an

• nerdponx 4y ago
  Hopefully you told them why you declined, otherwise they will just keep asking those questions of other people.
  • klyrs 4y ago
    If companies told candidates why their applications were denied, sure, I'd be inclined to share my side. They don't, so fuck 'em. Play stupid games, win stupid prizes.
    • nerdponx 4y ago
      It's not for the sake of the company, it's for the sake of the other candidates.
    • persona_reuse 4y ago
      Previous company, I was a principal IC and I used to interview people. I was warned by HR never to discuss how the interview went or why the candidate bombed. Their notion was: 1) We're there to find candidates, not improve people. 2) Time spent on someone you've eliminated is a loss. Cut your losses. 3) Think like you're talking to the police. Are you 100% sure you're not going to say anything that could be even remotely construed as illegally discriminatory? 4) Most states are 1-party-consent for recording, and even if it's an inadmissible recording, them having an interaction recorded can come back to bite you if they use it to jog their memory to perfection. I think it's gross, but it's a litigious race to the bottom so I kind-of see their point. Really happy not to be an interviewer anymore.
      • klyrs 4y ago
        I mean, I've been on the other side too, I know why companies don't share that information. But, given that they won't, why should I waste my time and energy?
      • zerr 4y ago
        Cut your losses by burning the company reputation? Such behavior is nothing but an invitation for a "warm" Glassdoor review. On the contrary, when I was an interviewer, we had a policy of giving a detailed technical reasoning for the decision within 3 days.
• buzzdenver 4y ago
  Can you elaborate on what made the question obscure? I'm asking because I used the question "print out the first 52 numbers in random order"in interviews before, and the answers seemed to give a good hint about understanding of basic CS concepts.
  • anothernewdude 4y ago
    np.random.choice(52, 52, False) + 1
    • CoastalCoder 4y ago
      I'd start with, "What do you mean by 'random'?"
      • eastbound 4y ago
        Obligatory response, Dilbert’s “9… 9… 9…” number generator, “the problem with randomness, is that you can never be sure…” https://www.dilbert.com/strip/2001-10-25 https://www.dilbert.com/strip/2001-10-25
        • mjochim 4y ago
          If we are talking obligatory responses, don't forget this one: https://xkcd.com/221/ https://xkcd.com/221/
      • bornfreddy 4y ago
        Yup. Seemingly trivial questions can reveal a lot about the candidate.
        • znpy 4y ago
          Indeed. I have been routinely questioned about what happens from when you type www.somesite.com and when the webpage is displayed when interviewing over the years and realised that nowadays I could fill 2 whole hours talking about all the stuff that actually happens (and many times I would have to say “but about this specific thing I’m not very knowledgeable about)… whereas at the start of my career i would have probably spoken for like 15 seconds and felt smart about answering “such an easy question”.
• lordnacho 4y ago
  This is what happened at my Oxford interviews. They asked me stuff that I knew the answer to, thinking it would be one of those see-how-he-thinks things. Biggest problem was acting like I didn't know and getting it really fast. Total lottery, they could have asked any number of things that I didn't understand.
  • seanmcdirmid 4y ago
    Ya, this is hard. I bombed an Amazon interview because the interviewer asked me Alien Dictionary, a well known LeetCode problem that I already worked out while practicing. I told her outright that this was a problem everyone practiced, but she still dinged me for already knowing the answer and not going through the “figure this out flow” (admittedly, I could have handled that better, but it is actually difficult to work through something that you know the answer to but forgot how you got the answer). At least it was for a job I probably wouldn’t have taken.
    • darkerside 4y ago
      > it is actually difficult to work through something that you I am the answer to but forgot how you got the answer Well, yeah. That's a big part of the point of the question. Anybody can Google the answer. Do you understand it well enough to explain it, and if you don't, can you walk through your thought process as you figure it out.
      • seanmcdirmid 4y ago
        I failed to practice answering questions that I already knew the answer to. I also think the interviewers style had something to do with putting me off balance (it became adversarial after I pointed out this was just alien dictionary, I probably would have had a better result pretending not to have seen the problem before). Or maybe that’s just how things are at Amazon? My Google and Facebook interviews went much better in comparison. None of their questions were top ten LeetCode ones.
        • 4y ago
• nikhizzle 4y ago
  I’ve had this happen to me before and disclosed it during the interview. Consistently, the response was the interviewer telling me they were impressed that I was well prepared, and to go ahead with the answer.
  • pclmulqdq 4y ago
    I usually asked as an interviewer if you had seen the material before. If you were honest, it was very impressive, you could give your solution, and we could also cover other material.
  • grog454 4y ago
    The vast majority of your coworkers will have gone through a similar if not identical interview process. Do you prefer to work with people that pretend they've never seen a question before when they have? Then do that. Do you prefer to work with people that admit they have seen the question before but are not directly penalized for it? Then do that. If you somehow are penalized for it... you dodged a bullet.
    • ryandrake 4y ago
      As an interviewer, I would prefer (in this order): 1. The candidate has actual domain experience matching the question and can rattle off the answer in their sleep. We can use the remaining time to go deeper into the question and probe the boundaries of candidate's knowledge. [maybe 1 out of 200 candidates actually deliver this] 2. The candidate came prepared, studied the question ahead of time, can rattle off the answer from memory. As above, with the question out of the way, we could use time to explore around the topic and find areas the candidate didn't study but still can work their way through. It's rare that you see someone who memorized a perfect answer, but then can't go further purely because they have no canned response. 3. The candidate doesn't know the question ahead of time, and legitimately "thought hard" and solved it on the spot. We may or may not have time to probe further, but candidate has shown the ability to reason through a problem outside their domain. [above this line is my "hire" bar, below is unfortunately the vast majority of candidates] 4. The candidate doesn't immediately get there, but can be guided through with hints and can follow the bread crumbs I'm laying. 5. The candidate tries but, for many possible reasons, struggles, goes off down wrong-way roads, and doesn't make any progress. 6. The candidate freezes up, deer in headlights, won't produce anything. 7. The candidate talks and talks with a prepared speech about his background and skills, but doesn't actually do or solve anything [yes, I've seen this multiple times]
• JoeAltmaier 4y ago
  On the flip side, we questioned a candidate the usual way with pertinent technical challenges and so on. Then when driving in a van to lunch (our habit was to do a social segment as well as technical) I asked some puzzle questions - add 6 feet to a rope around the world, stretch it out and how far off the ground would it be? and suchlike. He was charmed, we brainstormed some answers and had a fun lunch. Years later, now a senior Engineer at our place, he admitted he had been going to give us a miss that day, until that conversation in the car.
  • dekhn 4y ago
    you would have lost me (principal engineer) with those questions.
    • JoeAltmaier 4y ago
      Really? You don't like to socialize with peers, with puzzles or tricky problems? Enough to make you refuse to join a company? Discussion has gone off the rails here. Maybe I didn't make it clear - the puzzles were during casual conversation at lunch. Rebutting something I didn't say, is not fair.
      • pfooti 4y ago
        I think there's a pretty clear difference between chatting about interesting puzzles between friends and asking annoying puzzle questions in a job interview. The power dynamic is very different, although honestly I don't often like those socially either. They can be deployed to trip other people up, make them feel small, etc. Can cause social anxiety. As with most things, it depends a lot on the history you have with those people and the psychological safety you feel, so it depends? Definitely not with someone I just met and is interviewing me for a job. And FWIW I also don't interview anywhere there are questions like this.
      • enumjorge 4y ago
        Happy to chat about puzzles when we really are peers. In an interview setting that’s not the case. For some candidates there could be a lot riding on the outcome of that interview and grading them based on puzzles that don’t really reflect day-to-day work is IMO kind of rude.
• LanceH 4y ago
  I answered one of those mind benders nearly immediately in an interview. I figured out the trick as they were telling it basically. They asked me if I had heard it before. I hadn't. A final interview with the CEO and he asked if I had heard it before and I said I hadn't. I later realized based on how they were asking if I had heard it before, they thought I was lying. The question: You get on a ski lift going up. It's 1000m long and you move at 20m/s. Between when you get on at the bottom and you get off at the top, how many of the chairs going down do you pass?
  • naet 4y ago
    Do you pass them all?
    • metamet 4y ago
      It could be sum of all the chairs -1, could be -2 if the chairs are two per row, could be that the hub where they turn around has a large radius and the spacing of the chairs is close enough of that you don't "pass" them, could be 0 if there aren't any other chairs. I suspect the answer to this is "not enough information", which, I suppose, hints at an applicants requirements gathering thought process?
  • giantg2 4y ago
    This seems like a stupid answer for it to be n-1, but it also seems like a stupid question. What's the answer?
    • LanceH 4y ago
      It's n-1. I should have put the number of chairs in the question. I wasn't really trying to quiz everyone here, just identify which mind bender it was. The "twist" on the answer is that you start below all the other chairs and finish above all the other chairs, so you must have passed them all along the way. I saw this immediately and answered "99" or whatever it was. In retrospect, I think they couldn't conceive of anyone figuring it out on the fly.
  • 4y ago
• giantg2 4y ago
  "I could have told them I had a massively unfair advantage, but I did not bother." I guarantee they knew you had an advantage without you saying something. That's the whole point of interviews - to find the candidates with the advantages over the other. The question becomes whether a specific advantage is unfair, or if any advantage is unfair.
• deleted 4y ago
  [deleted]
  • rhapsodic 4y ago
• tzs 4y ago
  OT: I once wondered if normal human shuffling could actually achieve all possible permutations, where by "normal human shuffle" I mean take a deck of cards, split it into two roughly equal piles, and then merge the two piles by repeatedly taking the bottom card from one then the other, with some sloppiness in the "take the bottom card" part so that sometimes you might take more than one card but not too many. The answer is yes. Here is a way to do it, although it is not very efficient. Let P be a shuffle where the deck is divided exactly in half, and the merge perfectly alternates one card at a time between piles, starting with the half that was in the bottom before the cut. Let S(n) be a shuffle that is almost a P shuffle except that when the cards that would end up at locations n and n+1 in the P shuffled deck are at the bottom of their piles we drop them in the opposite order then go back to the normal drop order. S(n) counts as a normal human shuffle. The result of an S(n) shuffle is the same as doing a P shuffle followed by swapping the cards at positions n and n+1 in the P shuffled deck. If you take any deck and apply the same shuffle repeatedly you eventually get back to where you started. For example doing P 8 times brings you back to where you started. Let O(R) be how many shuffles it takes for shuffle R to come back to where it started, so O(P) = 8. If you do O(S(n))-1 applications of S(n), then P, then one more S(n), that brings you back to where you started except that the cards at n and n+1 are swapped. With this we have the capability to exchange adjacent cards in a deck. Any permutation can be reached by a sequence of adjacent exchanges, and thus normal human shuffling can reach every permutation. As I said this method is not very efficient. The swap of n and n+1 by this method takes 120 shuffles if n is 22 or 28, 72 shuffles if n is 0 or 50, 56 shuffles for 1 or 49, 40 shuffles for 16, 17, 33, or 34, and 16 shuffles for any other n. Putting the whole deck in a given order would then take tens of thousands of shuffles. Inefficient indeed! That raises the question of how many normal human shuffles does it actually take to reach a given permutation? What permutation requires the most normal human shuffles?
• neilv 4y ago
  I had a bit similar story, though it went a different way, and prompted a few other thoughts... Earlier in my career (a few years before Google seemed to start the current techbro rituals), I went to an interview at a big-name CS dept. spinoff company which had the same problem: CS students and professors with no professional software engineering experience deciding what's most important for professional software engineers to know. The interviewer and I were both senior engineers at well-regarded companies, but he gave me a coding exercise (this was not usual, at the time), and it was a CS101 tree traversal coding exercise in C. I'd happened to remember that day of class from community college, and I just did the exercise. Nothing to brag about. Then he said "no one ever did it that fast before". So, feeling very confident and a bit disappointed/surprised, I started telling him what I thought was a better way to do interviews for software engineers. (Spoiler: it didn't involve regurgitating CS101 algorithms a person randomly happened to recall.) I got the offer, and accepted the job, partly because we had a collegial discussion about the interview methods. Very smart and likeable people. But there were a lot of people who arrived from top university departments not knowing how to do software engineering nor even how to do non-homework computer programming, but they apparently passed the interview of the CS undergrads' idea of what's important to software engineering. (Actually, the person from there who I noticed on LinkedIn many years later as eventually most accomplished from there, was the only one I knew came from a commuter state school, rather than from a big-name CS department. I don't know whether he would've gotten in, once techbro rituals took over. Maybe he would've, if his school's department had switched to teaching to the techbro interview; though, then, maybe that would've been at the cost of whatever skills development later helped him be so successful.)
  • franga2000 4y ago
    > the current techbro rituals As someone who's never interviewed at FAANG and only ever gotten either relevant (paid!) take-home programming assignments or the CS101 bullshit the author talked about, what do you mean by that?
    • jasonladuke0311 4y ago
      Probably Leetcode stuff. “You have 45 minutes to solve these two problems that were doctoral theses of famous programmers. Go.”
• SilasX 4y ago
  I had the dunce's version of this. They asked me if I had seen the problem before. I (truthfully) answered yes, and they moved on to a different problem (which I aced). I didn't tell them that I completely failed when given the original problem and didn't learn the right way since. And have bad memories of doing it and would probably panic if I tried again during that interview.