IMHO, this was not cheating. This is a phenomenon called success. If you are fortunate (?) to be around in the entrepreneurial world long enough, you will realize that intelligence, hard work, good time management etc are not adequate. They just qualify as deserving. There are serendipities that separate those who succeed from everybody else who was deserving. Survivor bias [1]. Calling Eli was your serendipity. The opposite is also true: killer asteroids hit the planets of otherwise deserving individuals and initiatives. I was co-founder of a municipal fiber-to-the-home initiative in 1996. We had both a winning technical recipe and also a financial engineering recipe. (Extremely rare even today) We were then fortunate enough to acquire a customer that was a newly minted public company, representing a whopping 65% of our business. Banker's dream, but in actuality a big mistake. Then the double-whammy of fraud by that public company (wiping it out completely before our contract was realized) AND the dot-com crash. Killer asteroids are real.
I agree, this is definitely not cheating. This is interview preparation. When I prepared for my FAANG interviews I googled so many questions that I couldn’t find another blue link, they were all purple. I prepped for them all. The more you want the job, the more you prep
The only mistake the OP made was in acting like they hadn’t seen the question before, but other than that everything was fine. These code screen questions are usually a basic gut check and the real evaluation comes later at the on-site. Honestly the interviewer did a bad job though because the question clearly gives an advantage to someone who has seen it before.
Once I had a candidate struggle with my screening question, flattening an array of nested arrays, and that’s fine because I normally use that as an opportunity to see how they ask questions and work together on finding a solution. But the candidate went silent for about 5 minutes and then came back with a perfect solution, using iterators, which are a pretty obscure JavaScript feature. I later found that exact code block on the MDN site, and I was pretty shocked at how brazen an action it was, because if they had just asked for direction and admitted they were struggling they could have still passed the interview.
There's a famous story about Gauss as a child (age 7 in some accounts) figuring out this trick when a teacher who probably wanted a break had the students add up the numbers from 1 to 100. He saw that you could combine numbers from the ends: 1+100=101, 2+99=101, and there are 50 pairs, so the answer is 5050.
There's also the joke that John von Neumann was given this task and "cheated" by just instantly adding all the numbers in his head the naive way, without having to write anything down.
Gauss was cheating since he was born! He fixed math errors in his father accountant stuff at age 3.(according to wikipedia) if thats not an unfair advantage i dont know what is ;)
> The only mistake the OP made was in acting like they hadn’t seen the question before
This. Everyone in the thread is claiming no wrongdoing on the part of the author. If I was in this position, I would excitedly inform the interviewer that I had seen the question before and then quickly write down the answer. But that would look be a lot less impressive than OP’s acting as he pretended to come up with the perfect answer on the fly.
The serendipitous knowledge of the question isn’t the cheating. The cheating is the deception in the interview that this is a question being encountered for the first time.
It’s cheating because it’s the type of unethical behavior you wouldn’t want in a colleague: pretending that they are brilliantly generating insights on the spot that they have actually researched previously.
I don’t think it’s an unforgivable sin, particularly for someone new to interviewing. But as a candidate, I’ve considered it appropriate to make it clear to my interviewer what my level of experience with the question was before diving in. And as an interviewer, I’ve always looked positively on candidates who have done the same
"If you are fortunate (?) to be around in the entrepreneurial world long enough, you will realize that intelligence, hard work, good time management etc are not adequate."
Not just as an entrepreneur. I have found that these traits don't guarantee a reward for ICs, or anyone really. I used to work hard. Now I just work hard enough. Pays the same either way.
So instead of working hard at your tasks, you worked hard at playing your manager. Seems like a “law of conservation of working hard” to me; you just needed the right kind of working hard.
No. Instead of working until my head exploded (and my manager telling me I wasn’t showing “a sense of urgency”) I focused on doing the right thing, and part of that is helping your manager succeed.
I'd once heard a piece of advice that was along the lines of "regardless of what it may say the duties are on paper your actual job is to make your manager look smart for having you on the team"
I had a similar realization, but it’s not really about working hard vs. not working hard, it’s about knowing what’s important to your manager. Early in my career I would never say no to any task, and would give the time estimate I thought the manager wanted, and then work over time to get it done. Half the time the finished product had bugs, got delivered too late, or ended up not matching what the client wanted, so the “hard work” didn’t translate directly into success. Now I try to figure out what the client’s actual needs are and how to meet them as quickly and with as little work as possible, and when something is requiring overtime, I immediately stop working on it and communicate that it’s a bigger issue than expected, and either push the project, get additional engineers, or find a different way to solve the issue. I think programmers really enjoy solving problems and we never like to admit that something is more difficult than we expected because we feel like we failed, but actually that’s just an expected part of the job. Obviously this only works if you have a good manager who actually cares about results. Bad managers are easy to manipulate because you just optimize for whatever BS metric they’ve decided is important, but those jobs are soul crushing.
As long there's a common understanding of the goal of the company it's easy. The tricky part is to get the manager to manage the upstream managers and across departments.
I agree that this is the common experience for those of us that never experience overwhelming "serendipity" (i.e. luck) - meaning no disrespect (or lack of gratitude for being so incredibly fortunate) - but for those few that do get shot out of a canon, it would appear that hard work (focused hours on task) makes all the difference on becoming industry dominant (Musk, Jobs, etc). When you get a tiger by the tail, you need to stay focused and not fall asleep.
I once aced an interview after the recruiter handed me the list questions, all soft balls like "what is the difference between a promise and an observable". Naturally I googled every one of them and during the interview had to hold myself back as to not to totally dunk on the questions. Afterwards the recruiter called me back with the good news, I said it was almost unfair how easy it was, he just laugh and said that not everyone that gets the questions on a silver platter actually passes the interview.
What was the point of the question? That would help determine whether or not this was cheating.
Normally with things like this the interviewer claims to want to "see how you think." If some prepared rote answer passed this interview phase, at the very least, the interview failed to meet its stated goal.
What's the difference between cheating and what's needed for your version of "success?" Can someone cheat their way to success? Or does seeing the answer key before the exam just mean being better prepared than the competition?
If the fraud in your story hadn't been discovered, would that have been success?
These sorts of screener questions are at the level of "can you write a simple function and can you answer basic questions about it"
A surprising number of candidates I've seen interviewed cannot do the following, my code screener question: "Write a function that, given a set of integers, determines the amplitude (difference between biggest and smallest) of the set."
This is literally max(set) - min(set) in more words. I have seen countless people attempt this in different ways. My favorite was the guy that sorted the list and took the end values.
The worst is when I ask the follow up question: "where might I use this function?" I almost never get the answer of where I stole the function from (matplotlib): "the size of a graph", instead usually getting an "I don't really know".
I'm not so sure about this one. Software development is quite usually "build functionality to serve a given use case" whereas this line of inquiry is more along the lines of "find a use case for the given functionality".
Perhaps if you intend for the conversation to head into a chat about charting and data science?
>These sorts of screener questions are at the level of "can you write a simple function and can you answer basic questions about it"
Some interview questions are like that, but this wasn't one of them. This is not "implement simple functionality" -- for that, you would ask e.g. fizzbuzz or "reverse the elements of a list".
This one requires you to work out something clever that reduces the time needed compared to the brute-force solution. You'll notice that, in this case, even someone at the end of a 4-year computing degree had to think about it for a while to figure out the shortcut.
Yes, once you have the insight that it can be reduced to max(set) - min(set), then it's a matter of writing a simple program. But obviously, this question isn't testing whether you can implement max(set) - min(set) when told to do exactly that. If that's all they were testing, they would have asked him that directly!
It is, rather, to test whether you are generally smart enough to, within the time of the interview, think of such a solution when it wasn't handed to you. To present yourself as having come up with that insight on the spot, when it really took you hours, is a kind of deception.
Yes people "cheat" their way to success. I hate it, but they do and we support it. From just a position of basic human integrity (forget about the law), Apple "cheated" by implementing the graphical user interface from Xerox Parc without adequate compensation. Then Microsoft "cheated" by implementing Apple's GUI as Windows. Then came the lawsuits. This happens again and again.
I have experienced this personally - the USDA RUS broadband program had written rules where an ISP had to work with their regional office and not walk their application through the front door in Washington DC. Yet being the first to apply through the regional office resulted in significant delays over our competitor walking their application into USDA headquarters against procedure. They got the $20 million. We did not. Any attempt to object or litigate would only hurt us further.
> If the fraud in your story hadn't been discovered, would that have been success?
I do not consider the author talking with Eli to be fraud. There was no obligation of disclosure. For all we know the reason why Microsoft repeated this question with so many applicants may have been deliberate to see how many applicants would actually get the solution by asking around. After all, isn't that how all of us code?
He didn't call Eli randomly, he called to research an interview. That's putting the work in. That the question was the same might have been serendipitous (especially if the question was one of many possibilities). And he didn't just call and get the question, he then put in the effort to research an answer.
The thing is, for 20+ years you didn’t have to study. Only within the last decade or so have things become so competitive. There’s been a fundamental shift in supply and demand.
Maybe I am being too cynical but I think the author knows this too but I think he wanted to frame it this way to get more attention and indirectly promote his company
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 answers instantly and could jot them down straight away. They had allocated an hour for answers I wrote in a few minutes. I could have told them I had a massively unfair advantage, but I did not bother.
They were visibly impressed and told me I was moving on to the final interview stage right away. I declined, as I hate companies that select for algorithm puzzle skill instead of real world problem solving experience.
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.
The rope question is more of a Fermi question[1]. Not that they aren't commonly called [2] puzzlers, but I think the distinction is useful. Fermis are about estimating, and that's an actual skill - innumeracy[3] is real.
What I would call puzzle problems usually involve some trick to getting the answer. If you can't figure out the trick, you're stumped. If you know the trick, you barely have to think to crank out the answer. Optimally solving the example in the article is one of those.
They weren't widely banned because they were too novel and charming. They were banned because "time to aha!" in any given instance doesn't tell you much about how someone solves problems. Also, because the bulk of the work at most jobs doesn't really resemble seeking "aha moments," these questions tend to select for people who thrive most on doing something other than the job at hand.
To me it definitely seems to be in the puzzler category based on those descriptions. The trick is realizing it's "just" asking you to solve the well known formula for radius to circumference, 2*pi*r=c, for c=6 would give r≈1 while you can ignore the rest of the information worded to trick you into thinking it's a complicated problem which would require a fancy solution. Of course if you're not dealing with geometry every day of your adult life it's more likely it leads to seeing what your general thought process is, such as "I'll fall back to Fermi Estimation to get a ballpark going".
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?
I can only imagine being "charmed" by a question like if I was much younger in my career, eager to be seen as smart and in the company of like-minded folk.
Nowadays... my focus is on solving problems... as in real problems, not made-up ones. Thankfully I haven't heard questions like this in years. But when I do, I take it as a sign that they probably don't have actual, meaty problems to work on, that is, requiring higher-level cognitive skills (and actual experience). Not to mention that this was supposed to be lunch, and here they are asking filter questions, but pretending it's just "casual conversation" when obviously it isn't.
And so would probably pause for a second, and think of a way to tactfully end the interview, and thank the interviewer for their time.
Yeah it's easy to act all butt-hurt and be too good to even try. But how outrageous is it to imagine that folks who can solve such problems might be able to solve other problems?
Also, it's not about being too good to even try but about being old enough to no longer put-up with corporate non-sense; too much bullshit in a job to put up with as it is. Once you get to a certain age, you learn to prioritize real stuff rather than appearances.
A lot of people will find your questions obnoxious and irrelevant. Ask questions about the candidate's experience in past problems. Asking abstract questions to satisfy your own ego is a narcissistic trait.
That's not the point or context; No one likes "creative" interview questions is what people are saying like this is just a variation of brain teasers from 1990's Microsoft interviews.
I think you've got it backwards. Lots of people who could solve your real world problems with a computer might not have a background in maths or physics and so may not be able to solve your puzzles. They may just feel anxious about appearing stupid in front an interviewer, and annoyed they weren't allowed any downtime in the day.
This is about empathetically understanding the stress levels between both of you would have been miles apart. Unless the candidate had brought up the subject somehow it'd have been nicer to just try to relax them and get to know them informally by asking about them - or better yet letting them do their own thing for lunch if they wanted.
add 6 feet to a rope around the world, stretch it out and how far off the ground would it be
is this a technical puzzle/question? to me it reads like a middle school geometry question. it would be fun to discuss it with friends/colleagues but I wouldn't expect it during a software engineering interview
> Although finding the answer requires only basic geometry, even professional mathematicians find the answer strangely counter-intuitive.
I guess the more a visual person you are the more counter-intuitive it is. That only 6 feet of rope is needed to widen the radius of Earth at every place at continents and oceans ect at a whole 1 feet seems crazy to me.
sure, the answer might seem counter-intuitive but the method to find the answer is not, as long as you know the connection between a circle's circumference and its diameter
I still fail to see how this is relevant for a technical interview, assuming that we're trying to hire a software engineer. Fun, but not relevant.
Hah, I just did the math on this myself, found the answer to be 0.955 feet, and assumed I had done something wrong, or was off by a factor (or two or three) of ten.
It helps me to think about it in opposite terms. You're increasing the radius by ~1ft (radius around the whole earth), and 2pi is the linear relationship with circumference, so you'll get six ft. Thinking about it this way kind of ignores the fact the circle is huge. I'm not too visual of a person though.
I think that's perhaps a naive interpretation. At the core of this question are a number of assumptions, and concepts to think about:
- What is the rope made of? How stretchy is it? How strong is it to tensile stresses?
- What model of the earth are we using? A sphere (circular cross-section?) ellipsoid? Which axis of the ellipsoid? Does it take terrain into effect, or just gravitation? How does the rope avoid hitting terrain?
- How does the rope stay suspended? how does it resist gravity? are there uniform thrusters on it? How are they fueled?
- How is length added to the rope? Is it stretched somehow? Material added? How is the added material, if applicable, inserted?
Ultimately, I think we need to know what project requirement is driving the question to be able to answer this. It would shed light on most of these assumptions. If it sounds like I'm being pedantic or overthinking the question, I'd disagree: These considerations are critical to giving a meaningful answer; otherwise the question doesn't make sense. Unless we're talking platonic forms or w/e.
It does sound like overthinking to me, but context is king. Without context/requirements we're just guessing.
Maybe the job interview is for Space X and they're working on some new system of mini-satellites-on-a-rope called Hyper-rope, or maybe google is trying to pivot their failed Loon project into some kind of air-born connectivity solution, and the rope is actually a very long fiber-optic cable.
Or the interview could be for an online eCommerce platform and the person being interviewed will most likely have to work in a huge heterogeneous codebase with all the important technical decisions already made.
otherwise the question doesn't make sense
Well that is my point. I love these types of subjects, but when I'm having a beer with friends and we find a puzzle like this one and we try to take it as far as possible without going into fiction/bullshit territory.
So it could be useful to check/signal for culture fit, and in OP's case it actually worked like that
OP: "We value people that love to get into this type of discussions/arguments"
Interviewee: "Gosh, you guys bored me to death during the technical interview but it seems like we have similar tastes when it comes to theoretical puzzles so I'll give you another chance"
Nothing wrong with this though. It just proves that interviewing is a complex process and actual merit and success are highly subjective.
The follow-on is, if you add 6 feet and put your finger under the rope and pull up until it's tight again, how far have you raised your finger? 1ft? 10ft? 100ft? 1000 miles?
The answer to that is very difficult. There are several approaches.
Yes, but that's still a geometry problem. Don't get me wrong, geometry was my favorite branch of mathematics in school, but I don't see how this is relevant for most software engineering jobs.
I guess this type of question might serve the purpose of finding like-minded people with similar interests (in your case geometry or puzzles) but it might alienate others.
I solved a very similar problem (in the context of a pathfinding and obstacle avoidance sim) 25 years ago, and I can probably describe the thought process and geometry in very digestible terms, but if I had to code it in a whiteboard I'd likely fail.
An issue is that one person's trick question is another's straightforward problem. My college algebra students thought that every problem was a trick question, and that the only strategy for passing exams was memorization.
Was this a situation in which you were asking the candidate while everybody else either already knew the answer and was listening to the candidate think?
Or was it more like everybody was discussing (and explicitly or implicitly through discussion) admitting that they don't necessarily know the answer (while assumedly is an engineer in good standing on the team), and the group is working together to solve it?
Because both situations seem equally plausible based on what you wrote, and if it's the first one then I agree with your detractors below that it's messed up. If it's the second situation then I would have loved it and been excited to join your team.
It's very possible that the ambiguity of the situation is why there's such variance in reactions.
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.
Would have been a huge negative to me. I'm fine to chat with peers and discuss little riddles.
That is not what's happening when you're interviewing me for a job position. You're not my peer. We're not having fun. There's a non-subtle implication that my ability to answer the riddle will impact whether or not I get the job. I would be very annoyed if someone asked a puzzle like this too. It's not a novel puzzle. It's mostly a gotcha where intuition meets math. I could blurt out the answer. But I would instead feel it more important to slowly reason out the answer and appear to discover it on the fly. Which is pretty bullshit. And I would think you're not very smart for thinking this is worth anyone's time.
If I didn't know the puzzle and I failed to get the job I would be mad and it would stick out as something that penalized me unfairly.
In every interview I've done, lunch was explicitly bracketed by "this is a free, casual lunch that won't affect your interview at all".
And as an interviewer, I've never been asked to report on lunch chats.
> You're not my peer. We're not having fun.
Actually, most interviewers are your peers, and they typically know that you're under interview stress and are trying to help. If you can't take a break and de-stress during lunch, you're just hurting yourself.
The power dynamics at play makes someone spending time with me during an interview process where they have nothing to lose and can exert influence in the selection of me for a full time job offer decidedly _not_ my peer in that situation.
Every time I interviewed someone, I ALWAYS asked myself if I would want to work with this person.
Not just, can they do the job? Not just, are they technically competent? But, is this someone I would be comfortable going to, asking for help? Are they someone I can build rapport with, brainstorm new approaches and products with? Do they pass the "have a beer together" test?
Someone who explicitly has an attitude of, "You're not my peer, we're not having fun" doesn't sound like a good collaborator. Doesn't sound like someone who can be an approachable. Doesn't seem like a good mentor to newer members of the team.
> Someone who explicitly has an attitude of, "You're not my peer, we're not having fun" doesn't sound like a good collaborator. Doesn't sound like someone who can be an approachable. Doesn't seem like a good mentor to newer members of the team.
Interviewing is a high stress situation where the person performing the interview ultimately has power. What you're discussing here is how well I can socially fit in - regardless of pressures/stress on my side of the table etc.
It's 100% performative - if I am an interviewee I'm showing you the professional version of myself which is positive attitude and politeness. I'm upholding a social contract.
---
> Do they pass the "have a beer together" test?
I'm not here to have beers with you - I'm here to work. And, I think this is pervasive in regards to hiring. This can be incredibly discriminatory and I would appreciate you interview me on the value I can add with my labor vs. "can I have a beer with this guy?" That's weird to me, and as someone who interviews I work hard to not think this way... "Who I like" isn't necessarily who is going to perform in the role - I have to keep my personal preferences out of my professional decisions in my world... and I think that's fair.
---
Idk - interviewing is not fun for most people. I defend op's "we're not peers, we're not having fun" perspective both as an interviewer, and interviewee. I think it's a reasonable stance to take as long as they're outwardly presenting as professional and polite as that's what actually matters... not "beers"
Neither have I, but unless I was asked to deliver my interview evaluation before the lunch, you can bet any particularly good or noticeably bad flags during lunch would go into it.
Conversely, the couple times I had those "casual" lunches as a candidate, "I'm jetlagged" was a graceful way to lie out of the question why I wasn't eating much.
I feel like everyone here is missing OPs point. It seems like they had a mostly typical interview, which the candidate had probably been through a bunch of but for whatever reason wasn't to intrigued by the company. Maybe the candidate thought it was too boilerplate... I don't know. But then during lunch, when a handful of collegues are casually throwing around brain teasers, the candidate realized he would like the atmosphere. This doesn't seem too wild to me. But then again, software engineers are some of the most sensitive people I've ever worked with.
One reason for the lunch is to try and relax a bit and test “cultural fit”, which is more like a blind date between two people to see if there is any spark. Ideally it is a two way conversation, where the candidate and the interviewers get to judge each other.
There is a problem where cultural fit “tests” are heavily biased against minorities - for example most any sports discussion is dominated by your social class.
Enjoying brain teasers matches a particular type of geek, and the discussion likely veered or was encouraged in that direction by the candidate. It wasn’t Machiavellian, which perhaps you are more responsive to?
Asking puzzle questions during lunch interview is absolutely not just socialization. In fact I remember as a kid my dad explaining how lunch interviews are culture tests and how to succeed them- but it's very unpleasant for me. Best lunch "interview" I ever had was at Noname at Google some 15 years ago, it was just a relaxed conversation where we discussed the fact that Google's chefs made and served consomme.
I absolutely don't like solving puzzles with other people. On the other hand, I do enjoy writing code on my own, solving problems (not puzzles) and then sharing the results in a readable way with others.
I do like to socialize with peers, but never playing games (I prefer to play games on the computer against NPCs).
THe reason I don't like this is there are people who've asked me ludicrous puzzle questions before and they are proxies for 'people I wouldn't want to work with'.
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.
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.
imho this is really negative. Early in my career I would have been self-browbeaten into answering such an interview question disguised as “fun” lunch conversation, but I would have hated it and thought badly of your company. Power dynamic, not subtle implications about getting the job, gaslighting, etc. all lead to a bad look.
At least normally when someone takes you out to the XYZ company “not part of the interview” lunch halfway through your eight hour interview loop and you chat small talk and background, there aren’t actual interview questions being thrown your way.
Imagine going to lunch and the interviewer striking up a conversation with “how many manholes do you suspect there are in New York.”
Well, I would have enjoyed that discussion. If the interviewer is capable of taking a break and having an engaging conversation about literally anything during an interview, that's a massive bonus in my mind. I don't need to hear about your plan to shake things up for the 10th time. If you can't see me as a person and not just a potential cog to make your department look better so that you get your bonuses, I don't want to work for you.
No, I go to work for an employer and work with my peers. My peers are not my friends in most situations. Maybe for you that is the extent of your social life so you think peers have to be friends, but you mixing the two together is your work/life balance limitation being applied to those you want to hire.
Are managers that naive with regards to power imbalances with their peers/colleagues?
I have seen people with similar insensitivity fail to understand why people in their teams dont like them: "but I treat them as if we are peers!! I like playing on the 'you are doing it wrong'games"!!
Agree that the amount of entitlement in this thread is wild. People, ostensibly respected principal engineers, will turn down jobs because they are asked a puzzle question during lunch. I _hope_ we are fortunate enough for this attitude to be a possibility in the next decade.
> "You don't like to socialize with peers, with puzzles or tricky problems?"
You have to remember that, after about 2010, the software industry is mostly comprised of people who are after a paycheck and their actual interest in computers, STEM, and other nerd activates is kind of minimal. It came as a shock to me too when I realized that the old shibboleths of being a hacker had become largely absent in the software industry.
Well, if you're thinking I said what I said because I'm not a pre-2010 hacker with an interest in STEM or other nerd activities, you'd be completely wrong. I started hacking on UNIX systems in the late 1980s, got a PhD because I wanted to be a scientist, and only went to work at Google to get access to their computer farm (where I built what was the world's largest idle cycle harvesting system, for science, at the time) although the pay was quite nice!
No, I said what I said because it's hard enough to be "on" during the coding interviews and also "on" during the culture tests, to also be "interested" in your puzzle. Wrong time, wrong place, wrong signal to send. Lunch interview (and the transport to it) is about learning about other people in a fairly non-competitive way.
When stretched, the length of the rope will be two straight lines plus part of the circle. The length of the segment can be calculated using a formula for horizon. Then we can create an equation: (s arc distance to horizon for h)*2 + delta = (d straight Distance to horizon for h)*2, or d-s-delta/2=0.
I think I found a small typo, where you have delta (instead of delta/2) in the third line. I believe it should be
sqrt(h(2R+h))-R * arccos(R/(R+h))-delta/2 = 0
This can be solved for h given delta numerically, such as with a spreadsheet. Use caution here because this formula leads to a loss of significant digits from cancellation of nearly identical terms.
For example, given R = 6378000 meters and trying h = 193 meters: the first (d) term is 49618.0 meters and the second (s) term is 49617.0 meters. The difference is 1.0 meter, which is the half delta we wanted. But there's been a loss of 4 significant digits (because the first 4 digits in each value are the same: 4961). The smaller the arc distance, the smaller the angle, the worse the relative error becomes.
It's possible to analytically factor out sqrt(2hR) from both the d and s terms. In the first case,
d = sqrt(2Rh+h^2) = sqrt(2Rh) * (1+h/4R) using Taylor series for (1+h^2/2Rh)^0.5
In the second case, I can derive one formula, but the coefficients aren't the same as my numerical best fit, which is
s = sqrt(2Rh) * (1-5h/12R)
Combining the two series versions for d and s, gives us this for delta,
delta = 4h/3 * sqrt(2h/R)
Finally, solving for h given delta, take the cube root of h^3:
h^3 = (9R/32) * delta^2
Thus for a delta of 2 meters, I get height h = 192.88 meters.
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.
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.
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?
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.)
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?
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.
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.
Is the answer to convert the letters to integers, then compare that list of integer strings before/after alphabetizing it? I haven’t studied leetcode (never needed to), but this is the first thing that occurred to me…
> 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.
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.
> I failed to practice answering questions that I already knew the answer to.
You failed for the same reason you would have failed if you had never heard the problem before. Knowing the answer has nothing to do with why you were dinged.
The interviewer turned really adversarial when I told her this was a common LeetCode problem. I guess you really had to have been there. Alien dictionary isn’t that hard otherwise, if I were allowed to work through it rather than explaining how it worked, things would have gone much better.
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.
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.
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]
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.
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.
It might be the difficulty of actually getting it right (if by "right" we mean that all 52! permutations are equally likely. Or perhaps it is more accurate to say the ease of not getting it right.
Something like this:
10 pick a number from 1 to 52
20 if not already printed it
30 print it
40 if we have printed 52 numbers
50 halt
60 goto 10
works, but could take arbitrarily long time. Most people prefer bounded run time.
Most people seem to come up with something like this:
array = [1, 2, ..., 52]
for i = 0 to 51
j = random(0,51)
swap(array[i], array[j])
print(array)
That has bounded time (constant time assuming random and swap are constant time). Unfortunately not all permutations are equally likely.
We can see that all permutations are equally likely by noting that there are 52 iterations of the loop, and each iteration has 52 possible outcomes. That gives us a total of 52^52 possible outcomes. 52! does not divide 52^52, so it is not possible for each of the 52! possible outcomes to be equally represented in the 52^52 outcomes.
To fix this, you can use the same basic idea of going through all 52 places in your array [1, 2, ..., 52] and swapping each with a random location, but instead of swapping the Nth location with a random location in the whole array, swap with a random location that is not earlier in the array.
Then you still have 52 iterations, but now the number of outcomes varies by iteration. The first iteration has 52 outcomes. The second has 51 outcomes. The third 50 outcomes and so on down to that last having only 1 outcome. That gives 52! possible outcomes, all equally likely. We just then have to show that every one of the 52! permutations is among those outcomes which is easy to do, and then we have shown that this is a correct shuffle.
What’s nice about this example is it provides lots of scope for discussion (as you did) without requiring much domain experience.
If the person can’t program their way out of a paper bag you’ll find out right away.
If they are a junior hire, any working answer is fine.
If they have more experience they can start to talk about why they chose the approach they did.
If they are quite senior you could talk about the benefits and limitations of different strategies, as you did.
In my case (if I still applied for programming jobs, which I don’t), I’d most likely do a naive shuffle and then discuss how problems using random numbers involve corner cases that require thought and domain knowledge I don’t have at my finger tips, so we could talk more about the (pseudo in this case) application needs so I could (in the real world) focus on the most important constraints.
As an interviewer I’m as happy, or even more happy, when the candidate knows their domain limitations and where they are important and where they are not.
If I was interviewing people what I'd probably do is pick 3 or 4 LeetCode problems, but not ask the person to actually solve them.
Instead, we'd pick whichever of the problems they find most interesting discuss the problem specification, and how we might approach it. We'd discuss what difficulties and special cases we anticipate. Then we'd look at the answer together and see if it seems to make sense. In these discussions I'd try to let them take the lead but would contribute enough to get things moving if they are getting hung up on something.
Finally, we'd go to the most valuable part of LeetCode, the discussion forum for the problem. In the discussion many people post their solutions and a lot of them are wrong. We'd look at a few of those and review them, again with me letting the candidate take the lead.
The great thing about the discussions is that the answers people post contain a wide variety of mistakes. Some don't solve the right problem. Some do get the right answer but don't meet the time or space constrains from the spec. Some miss edge cases. Some fall apart if the problem is too big (e.g., if an input array is big enough that every unsigned integer the language supports is a valid index).
Before we started I'd tell them we are going to do that, so when they hear the word "LeetCode" they don't have to worry even for a moment that I'm going to spring some hard trick question on them and expect to solve it under pressure. I'd probably even ask them if they have any LeetCode problems they have seen or did before and would like to use for this discussion. Since I'm not asking them to solve them, it doesn't matter if they've already seen them.
I agree, but there is a reason for having the candidate write some code: some people can talk a good talk but can’t actually write a line of code. That’s a phone screen fail, but yes, some people pass the phone screen, so the sooner you figure it out the better.
When I say “some code” I mean no more than ~20 lines and who cares about missed semicolons or such.
And only one or two interviews need this, the subsequent interviewers can do more of the important stuff you’re talking about.
Another important point about these discussions: train your interviewers. I hate interviewing with (for that matter Working with too) someone who wants to show how smart they are. If we bring someone in for a round of interviews it’s because we want to hire them so are looking to see if our prior judgement is correct. Don’t be mean to the candidate and don’t waste their time or yours.
This question came up in a weekly "random topic" talk that we had at an MIT lab I was visiting at the time, many years ago. One of the lab members - who was a very impressive coder and researcher - had been asked this question at a google interview. I remember being pretty surprised that he wasn't familiar with the fisher-yates shuffle (and that this would be considered a good question to ask at google). His first answer to the problem was actually one of the "obvious" (and incorrect) answers one might give. But then he also walked us through the process he went through with the interviewer on deriving a correct algorithm, along with a mathematical justification of its correctness. I think regardless of whether one is familiar with the typical algorithms, being able to explain and justify them does show skills. (And fwiw, he did end up getting an offer and working at google).
The questions I got were very specific to playing card patterns. The one I remember best was "How many times does it take to perfectly cut and shuffle a deck of cards before it is back in original order". Spoiler: A "perfect" shuffle is called a Faro shuffle and the holy grail of false shuffles to master as a magician. When a deck is cut evenly at 26 cards (doable with practice or a slightly bent or irregular marker card) and Faro shuffled correctly eight times, the deck will return to its original order.
If I really liked the company I might indulge your question, but it would annoy me unless you were a game development company and this was a real problem someone faced recently.
I general I don't like live coding questions because they don't reveal anywhere near the quality of work I produce if left alone to think for a bit. If the questions pertain to a real world problem I will noamally indulge them though. As an interviewer I don't make people do them. I often do live code -review- to see if people can understand code and spot security flaws or bugs as I find that a more useful skill than coding anyway, and code review -is- something actually often done together with peers in the real world.
I sometimes ask for people do take-home tests if they have no open source projects I can reference, because seeing how people code on their own is how I find out if they can do the job. If they use search engines to help, I don't care. That is how real life works.
That said, I only do this if I know the employer is willing to pay them for the time. Work simulation goes both ways.
If I am going to make it like real work, I need to pay for it like real work.
Stuff like whether the algorithm will always stop, or whether it runs O(N) vs O(N square). The main point to me was more to be able to have a conversation about the solution rather than it being absolutely right. I remember quite a few people using randomness, the most odd (and totally wrong) one using a random sort function over an array of (1..52).
Random sort meaning that sometimes a>b, other times a<b for the same values. Whatever algorithm a language's built in sort implements probably assumes that comparisons are consistent. I remember checking a few versions of perl and some created a core dump iirc.
Ah okay. Thought you meant using something like shuffle in Ruby.
I do wonder what the result of doing a randomized sort like that would be. Probably not really random. Feel like numbers near the median would be overrepresented in the middle of the array.
What is the catch here? In multi dimensional and infinite cases it can be a little tricky, but in this one is there more to it than "all permutations should have the same probability"?
I'm not an expert, but here are a few of the things that come to mind for me:
- One conception of random is subjective: the pattern must not be predictable by a particular person/entity. E.g., the Fibonacci sequence may seem random to a person with IQ 3, but not IQ 1000.
- I think related to that is the concept of cryptographically random: [0]
- Random numbers can have different statistical distributions. You referred to uniform randomness, but depending on the application, that's not necessarily what you want. E.g., [1] Especially for statistical / Monte Carlo modeling.
- Depending on just how random you need something to be and to whom, you may or may not need specialized computing hardware. [2]
- Sometimes people kinda want random, but they also want reproducibility if necessary. Think randomly generated unit test input, or randomly generated game levels. For those applications, it's helpful to know that most software uses pseudo- -random number generators (PRNG's). If you can remember the specific number used to seed the PRNG stream, you may be able to deterministically re-execute the code at will. Alternatively, if you want to (nearly) guarantee that subsequent runs of the program aren't the same, you'll want to somehow ensure that a different seed number is used for the different program runs.
So if anything about the job opening depends on this kind of stuff, IMHO it's a great interview question.
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”.
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
"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.
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?
I hate this question because it has an implicit bias that most likely the interviewer never saw. It's biased towards people who have ridden on a ski lift, which generally means someone wealthier.
If you're a poor kid who's never been skiing, you'll have a harder time conceptualizing the answer.
So... the answer is "impossible to know"? There's no data on how many seats there are, their distance, or whatever. There could theoretically be literally just the seat you're sitting on in the entire system. Then the answer is zero.
Let's neglect the horizontal distance the chair(s) travel at the bottom and at the top of the lift. Then the answer is "all of them," which holds true in your one-chair scenario.
The question reminds me of "how many groves are there on a vinyl record?"
Since I don't drink coffee, you are unlikely to ask me that question. But if you did, I might assume you are either joking or an idiot ;).
Clearly, it's a trick question (with unnecessary details to distract you from a possible solution) and the one asking probably thinks they are very clever. So now, whether you accept an equation or insist that it's impossible to solve when it's not really comes down to how you want to play that game.
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.
I suppose you assume the chairs are at even distances?
Imagine there's a circle with marks evenly spaced, eg roots of unity. When you rotate it halfway, the point that started at the bottom has passed (vertically) all the other points ahead of it, because at some stage each point has reached the top and started going down.
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?
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?
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.
I actually cheated on an online assessment for one of my first programming jobs. It was my dream job and really wanted to get into that company. Under the pressure, I just couldn't figure out the solution to the last challenge which was a recursive algorithm. Normally, I would be able to do this but I just got stuck and in a moment of panic, I StackOverflow'd the question on a secondary device which provided me the exact answer. I typed it in with my own style and submitted the assessment.
I got the job, stayed at the company for 4 years with great performance reviews and it shaped my experience as the programmer I am today. I couldn't imagine where I would be without the experience I gained there.
Nothing is perfect, but we do live in an approximation of a meritocracy, especially in tech. I had no special connections anywhere going into or coming out of college and ended up at my first company "the hard way". Any good references I made were only made through delivering results, I didn't know any interview questions in advance, and my college had no "prestige", certainly no Microsoft interviewers flying out to it - closest would be some waste of time joke of an "opportunity" I showed up to where IBM showed up to talk about their mainframes and AI stuff but offering absolutely no internship or job positions for software engineers. Coming from the tech desert of upstate New York, I actually had a lot of disadvantages working against me, working up from some low end job I only got half a year after graduating at a consultancy company to where I am now years later at a good remote programming position.
Tech is one of the biggest success stories, if not /the/ biggest, of upwardly mobile meritocracy. Anyone with an internet connection can learn what they need on their home computer and probably make it if they have the ability and time.
I hate this idea that everyone who succeeds does so only or even primarily by chance and privilege. Obviously those things will help you, but everyone I know who's tried in life has succeeded in some way, and the people I know who espouse all this "the system is rigged, everything sucks, full communism now" stuff never had any drive or patience to do or learn anything and just want to put in the least effort possible to smoke weed and sit around like a vegetable all day.
I hate how these people try to take my accomplishments away from me. My family was low earning, I had social difficulties in public school, I had no connections or help beyond FAFSA for college. Maybe some people do take the "bootstraps" thing too far but we absolutely live in a world where you can succeed on your own merit.
There's going to be nepotism and other unfair advantages anywhere in life, but I'm only interested in where a natural born programmer with a computer, some time after school, and not much else can end up. I think in the majority of cases this person can at least get an in somewhere, and once you have an in in tech, you'll be recognized by your team/manager if you do great work.
This is all made easier if there's free community college, good social safety nets, etc. which I fully support.
More like 1) Internet connection 2) [cognitive] ability 3) time
Add 4) physical health and safety 5) mental health 6) a job market that would actually hire you
You can imagine tossing a dice for each requirement. Is that meritocracy?
> I hate how these people try to take my accomplishments away from me
This is a good example of self-serving bias.
"self-serving bias as a phenomenon in which we credit ourselves for positive occurrences (our successes) but blame others or external factors when adverse events (our perceived failures) happen"
Obviously cognitive ability is important. Not everyone can do everything. The point is whether people can realize their potential to a reasonable extent, whatever that potential is, without their initial social status being a dealbreaker. And having seen a lot of cases of people lifting themselves up with programming, I'm inclined to think it's true here.
I was in your situation and then I came down with MS when I was 26. How am I to succeed on my merit when my medication costs > 300k/yr and I have no idea how long I'll be able to work (or what I'll be able to do for the scope of my career)?
Can you tell me what the correct Konami code is for success here?
You provide anecdata of your experience but no evidence of substance really. Which is fine as an opinion, but not when you make claims about others like
> the people know who espouse all this "the system is rigged, everything sucks, full communism now" stuff never had any drive or patience to do or learn anything and just want to put in the least effort possible to smoke weed and sit around like a vegetable all day.
> You provide anecdata of your experience but no evidence of substance really.
If you are a brilliant programmer in the US what short of a crippling health/personality/relationship issue would prevent you from landing a highly paid job?
Curious what you would have those of us IN that group do?
I'm far from a brilliant programmer, but I did start as a 4-year old back in the 90s and I'm competent. I also got MS in my last semester of grad school.
Why is the grandparent commenter's experience a worthy anecdote and my is not? In order to know, we'd have to somehow control for inborn programming ability and run a large study comparing career/material results after several decades, which clearly we (currently) can't do.
(And this is without getting into other factors you can't control: There were plenty of people who were happy to accept help and do projects with me until they found out I was a.) female and b.) a teenager at the time.)
I ask because the answer seems to be 'sucks for you but the system is designed for the average person'. Okay, so why are we assuming the average person has no uncontrollable roadblocks?
It is just anecdata, but I know at least 5 people on either side (besides people who were just average and got average results), and none that act in the one way but end up with the other result.
I wouldn't consider it cheating. It was either a stroke of luck, or MS wasn't really doing an especially good job of reviewing their tech questions. A big part of programming (in my book) is finding the way that works; using whatever path is required. If you peek through a hole in the curtain to do so, then that's fine. Knowing about the curtain, and the hole in it, is part of engineering.
I remember taking a photography class, where the teacher said "The first rule of photography is to cheat."
He was talking about doing something like walking into a brownfield lot in The Bronx, and taking a picture at an angle, so it looks like a remote wilderness, but I understood perfectly.
I regularly look up the most basic algorithms with Google, and StackOverflow is an integral part of my workflow. I've been shipping software since 1986. I'm thrilled to have all this information at my fingertips.
Of course, I need to do due diligence, and make sure I understand whatever code I crib (I also usually rewrite it, so it fits my style).
If you want to consider that "cheating," then knock yourself out. Whatever creams your Twinkie. I don't care, and I'll keep doing it.
I have found there are people who enjoy getting into the weeds of problem solving (possibly a minority) and other people who work really well with the weed divers in applying their results.
I am a person who has benefited from this symbiotic relationship in school and in my profession, from the helpful study partner to the helpful stackoverflow answer. All of them have enabled me to build things bigger than I would be capable of doing alone, and they have seen their efforts as a crucial building block.
Figure out what you enjoy and find people/tools/forums who compliment you.
I don't think you can consider two people, at least a year apart from each other, being asked the same question "not doing an especially good job of reviewing their tech question."
He cheated more on writing a clickbait title than actually "cheating" on the interview. This is the same thing as when a kid in class thought studying was a way to cheat.
That's harsh because TFA does mention that they feel outright uncomfortable (even after 18 years!) how big a role luck played in them clearing that fizzbuzz interview question:
> I've struggled with this a lot over the years, but I finally decided to share my story. I don’t think I would have made it past the first round of interviews at Microsoft if I hadn’t gotten so lucky. So pretty much, my entire career is built on one amazing stroke of luck.
...which explains why they felt like they "cheated".
Out of pretty much all the people I know, I can't think of any successful career not pivoting on one such fateful moment of "luck". One lucky question/answer, one fortunate encounter, one near miss. Of course we'll never know how the road not taken looks like. Any moment could actually be a pivotal one but most are very unassuming and only the memorable ones stick with us, making them feel more important.
Also, as someone who's been tested with this kind of questions (in the math and physics fields at least), I realized many times you aren't evaluated for knowing the answer but for how you go about trying to find it even if you fail.
This particular question is close to my heart as I was tested with it as a pupil in school. The teacher wrote this on the blackboard and asked me to come over and solve it (not having any prior knowledge). After a bit of fidgeting with the chalk I stared writing on consecutive lines 1, 1+1, 1+1+1 and after a few lines it dawned on me it looks like the "lower" half of a square of side n as cut by its diagonal. So I proudly concluded that the sum is n^2/2. Which was of course wrong, I forgot to add an n/2 to that since the "diagonal" is shifted right a bit. Still got top mark and maybe it was one of those moments that set me on a path. This went on through high-school, university, post graduate studies, and early career. It was only when I was knee-deep in real work that people started to care less about how I think and more about just the end result.
Preparing for this kind of question isn't cheating as long as you understood the answer.
> Preparing for this kind of question isn't cheating as long as you understood the answer.
TFA notes that because of lack of interview prep material in 2004, even when the author knew the question before-hand, it took them days to arrive at an optimal answer. And then it dawned on them that everyone else at the job fair, who may be seeing a question for the first time, only had 15 mins in a pressure-cooker situation to solve it.
TFA also notes that the author intentionally misled the interviewer as if they were solving the puzzle then and there: I casually explained how I could simply use a mathematical formula to calculate the sum of 1 to n (like, who doesn’t know the sum(1 to n) formula?) and compare that to the sum of the integers in the array. I slowly wrote out the solution I had come up with over days of thinking about the problem, being sure to pause periodically as if I was figuring it out for the first time. I talked through my thinking and made sure I had all the proper error checking in place. I double and triple checked my syntax. My handwritten code was perfect.
I understand that I just don't consider it cheating despite their reaction during the interview. I'm not going by any formal definition of "cheating" here. But this person took the question as a practice question, not with the knowledge that it will be asked. They also did the work on proving and understanding it.
Let's put it another way. If you take an exam after practicing with any kind of practice questions (something that has been done since the dawn of time and the education system) and happen to run into the same questions in the real exam, was that cheating or better targeted learning? Or if you find out about a job from a friend who works there, is it cheating because you have a significant insider advantage over people who never knew about the job?
In my opinion true cheating would have been made up of a) someone feeding them the real questions and/or b) someone feeding them the answers. It involves an unwillingness to put in effort and a premeditation that I didn't see in the story. This person was indeed in a conflict of interest but I wouldn't call them "a cheater".
P.S. If I were in that interview I would have provided the full answer almost instantly, not needing any kind of hesitation to "simulate" the thinking process. I know the answer without any relation to the interview. So there could be 2 outcomes: a) I get unfairly excluded under the suspicion of cheating justifying the need to fake the thinking to avoid this or b) I would have passed to the next stage making that whole charade effectively inconsequential.
Gotcha. Btw, I'm personally in agreement with you, as that's how I think about it all, too. TFA wasn't, and I merely attempted to point out why.
GP's claim that TFA might be over-exaggerating it a bit for marketing purposes may also be correct, given that it was authored by an exec at a recruitment firm.
I won't lie to someone's face but I've deliberately misled gatekeepers hundreds of times in order to grab the opportunity to deliver excellent work. People are judgy and scared, and we all know the exchange rate between false positives and false negatives is a farce, and when it comes to my ability, you're damn right I know better than they do. The idea that I have a moral obligation to gift them decisions about my future is laughable. I've never had any complaints and I've never lost a minute's sleep. If they don't like me after they've known me more than 45 minutes, they can put me in review and fire me. I won't cry about it.
> Out of pretty much all the people I know, I can't think of any successful career not pivoting on one such fateful moment of "luck". One lucky question/answer, one fortunate encounter, one near miss.
I remember this too, from our 4th-grade "G&T" math teacher telling us the story. Although I use the formula so rarely that I don't keep it memorized, whenever it does come up, I think back to that day in class and that moves the gears enough that I can derive it empirically pretty quickly from small-number examples and the knowledge that it involves two consecutive numbers.
I believe that the attention he is seeking is simply marketing. Almost all of his content revolves around hiring and working in tech, which is the core focus of his business. The overall trend is, "I've seen the bad, and built something better, so check us out."
I don't have a problem with people marketing themselves on LinkedIn - it that not the entire purpose of the site?
lol thanks! I actually hate the attention, in part because of comments like this one. Though this one was comparatively mild.
I do it to generate sales leads for my startup. We're bootstrapped so being able to generate leads without any ad spend or outbound sales means we don't have to raise money to grow. I used to write blog posts but they take so much longer. Hence no new posts on the blog since 2019.
Now I focus on LinkedIn. A single viral post on LinkedIn can get 2M-5M views on average. It will generate $1M-$2M in potential business for us. This way I can spend 50% of my time writing code, 45% doing CEO stuff, and 5% doing marketing.
Not only is it clickbait, the author is founder and CEO of a technical recruiting company. Clearly the article is written to generate leads for Facet. This is basically just astroturfing. The author should have opened with a conflict of interest statement at the very top.
Also, OP should have included (2019) in the title. It's kind of an old piece.
Its not cheating but it's absolutely unethical. OP is right that they should have disclosed that they had seen the problem before. It only is that the right thing to do but also good interviewers can tell when you genuinely thought about a problem vs just regurgitated the solution.
As unethical as the hundreds of interviewers who pretend to believe that the candidate in front of them, just somehow managed to find within minutes the solution to some programming puzzle, and not through hundreds of hours of mentoring and self-practice.
I would propose to change coding interviews to the following scheme:
Step 1:
Interviewer ask a coding question. If candidate is able
to answer correctly then move to Step 2
Step 2:
Candidate asks a coding question from Interviewer.
If Interviewer answers correctly go back to Step 1.
If Interviewer is not able to answer correctly
in 60 min, and Candidate is able to explain solution
and implementation, move to Step 3
Step 3:
Interview is over and Candidate automatically
qualifies for next hiring phase.
I agree that interviewers asking stupidly hard questions that they wouldn't be able to figure out in an interview is a problem, but I don't see how your solution would remotely work. How would you ensure the questions are equally difficult?
If the candidate can manage the question the Interviewer should be able also. After all he/she was already hired.
If a company decides to approach hiring with the naturally confrontational approach of, "let me find out in 60 minutes if you are smart enough to work here", I don't see why it should stop there.
After all recruiters always mention, it is good for you if you are also inquisitive, show interest in the company and ask questions :-))
Why can't a candidate also check if their future managers and the company are
worthwhile to work there? It is always mentioned that a candidate is a much interviewing the company as the company is interviewing them...
Now...how many interviewers are suddenly uncomfortable? ;-)
Is that not what is happening, when the candidate pretends he never seen the question during the interview but in reality he practiced it before on LeetCode :-)
Ohhh you mean the candidate should just be able to test the interviewer if they want, to see how technically capable the interviewer is?
That's an interesting idea. I'd support that as an interviewer - I think the question candidates ask would also give you some information about the candidate too.
Sadly I doubt that sort of thing would ever become normal. Plus interviews already take enough time. Not sure I'd really want them to take any longer.
Why are all the other comments so negative and stuck up whether it constituted “cheating” or not? That wasn’t the point of this story.
It was a beautifully well written account on luck and how sometimes the things align. The interviewee at the time was receptive towards the kind of questions that are asked at Microsoft and got the right one. Good luck. And then he passed a 6 hr on-site interview as well! No luck at all!
The author prepared with the info he had and was "lucky" that he got a question he knew and had situational awareness to sell it.
It's all positive traits in my book. The discussion about the ways to interview to smooth this out is great but I don't think he should self flagellate or consider that his entire career was predated on this.
If you have the right attitude, prepare and work for it, you find any number of paths to get to the next level.
It's unfortunate that interviews sometimes feel so badly fit to achieve the goal and we should actively challenge whatever practice we have an iterate to make things better for everyone.
It made me think of how courses take test questions straight from the class materials. And let's say I'm a big procrastinator, and I run out of time, studying the night before the test, and I decide only to go through the odd pages of my materials, and also let's imagine that the test writer, just by accident, took most (or at least, enough) questions from those odd pages, did I now cheat? (I think not...)
You cheated yourself out of knowledge acquisition by treating a course of education as only a means to get a certificate.
That's cheating.
You're supposed to study the whole course, the examination is a statistical test to see if it's likely that you studied, and can apply, the whole course. If you didn't study the course, you're misrepresenting yourself by during the exam.
That's cheating (in a different way to the first one).
Examinations are imperfect, they usually can't cover an entire course without being too onerous.
In this circumstance you cheated, but did not break the rules for taking the exam. You will be less competent on the course material than is intended for those who pass.
I highly doubt anyone will learn every bit of information in the book. I highly doubt anyone will remember every bit of information in the book. Which parts of it will be necessary are very dependent on one's future.
Making me thinking what if the author was not lucky enough to pass the initial interview. Well Microsoft just fail the author, and the on-site interview never happens?
I'm feeling that the initial interview might not be completely fair. But of course, many things in life are down to lucks. Good luck helps, I guess.
Fully agree. Add to that that the question was super standard, it was quite likely that the candidate would have heard about it one way or another before the interview.
I'm surprised that atm there is a consensus in the comments saying that it's not cheating. Companies ask interviewers to not reveal the questions they had to other candidates. It's likely that his friend was told not to say that. Overall he clearly had an unfair advantage, and even if legally it wouldn't be the definition of "cheating" it would go against the intent of the interview: which is to evaluate candidates in front of a new problem.
Kudos to the author for being honest about all this. I think it's a real issue and that we should find more solutions to prevent this than candidates signing an NDA.
Imho when doing such interview, questions should not rely on a "trick" and even if they do, candidates should be evaluated on everything else: how they explain the code, how they react to feedbacks, how easily they transcribe what they explain to code. It's not perfect but it helps.
I don’t disagree with anything you said. However, if the prevailing attitude was “fuck these companies that pay me these privileged tech salaries”, we’d all be treated much worse.
It's not "fuck them", it's just don't confuse a business relationship with a social relationship. Companies don't pay high salaries because they want to be nice, they do it because the market requires it. The second the market stops requiring it, they'll stop doing it. They'll treat employees only as well as the market and the law requires, employees should do the same or they'll be taken advantage of.
Comapre it with people who applied too, but didn't have that "internal" knowledge
Is it fair from that "not well networked" person perspective?
It's not even like he found this question randomly on the internet, he got it from MSFT employee, lol.
I have really mixed feelings about this
Edit.
Don't get me wrong, apparently author was(and is) capable of doing his job, so it isn't a big problem, but what if author wasn't capable of doing the job and passed just due to the advantage?
I know person who told beginner programmer what X company asks on interviews and that guy actually managed to pass that interview due to the knowledge
but was fired like 3 months later due to lack of skills
> but what if author wasn't capable of doing the job
Than Microsoft would've been scammed out of $350 worth of plane tickets, $150 worth of hotel commodations and $1000 worth of employee time. Hardly the end of the world for a multi billion dollar company
> and passed just due to the advantage?
Passed a six hour Microsoft on-site grilling due to knowing the question for a 15 minute off-site interview question?
> Is it fair from that "not well networked" person perspective?
Fairness becomes a bit of a contrived concept once you start to factor in higher order effects. Then it just turns into fair if it advantages me, and unfair if it doesn’t.
I helped a friend get a job once because I knew who was going to interview him, and I knew he had a blog where he published all his thought-leader technical opinions.
Is that fair or unfair? Probably neither. It’s more of a random coincidence that my friend benefitted from this. But is it fair that I have learned more about my local industry by going to industry events and listening to people present things, and talking to people, etc? That probably is fair, and that’s how I learned the tip I gave to my friend.
Fairness isn’t really relevant to the problem here. If you believe that there is a problem at all, then the problem is that the screening process can be influenced by random coincidence.
I disagree. He heard about this question beforehand during a casual encounter with an employee. So what? The onus is on Microsoft to have a more robust process than using basic riddles like those.
Would he have chosen to volunteer the info, he would have actively decided to penalize himself against all the other candidates who had also heard about this question before. This would have been borderline stupidity.
What about a case where the interviewee is given an obscure problem to solve, yet already encountered and solved the problem in a different context?
It would be difficult to classify as cheating if they did not learn about about the question from an inside source. On the other hand, it also defeats the presumed purpose of the question (i.e. to test problem solving skills).
I was in that situation before, explained how I knew the solution, and did not get the job. While there were probably other reasons for their decision, they said they wanted to give the position to someone who was pursuing a career in software development, at the end of the day the candidate is going to be up against people who would offer up the solution with out further explanation. That is an awfully good way to stifle opportunities based upon the presumed (and possibly incorrect) intent of the question.
A good example to make this question more fair, as an interviewer, would be to rapidly give the (n-1)*n/2 trick quickly if the candidate doesn't know it. And not care too much if they do know it.
While I can absolutely see why people would view this as cheating, I'm also not sure what he was suppose to do. It's a case of: "Hey, look, I really want this job so I took the time to prepare and studied the kind of question you might ask. I happen to know the answer to this question, could you ask a new one that I don't know the answer to?" If I where the interviewer, I'd just stop the interview at this point and move the candidate along to the next interview anyway. He's clearly smart enough and has already invested time.
Personally I don't put a ton of value in question like this, so I'm less inclined to view it as cheating, and more like proper preparation... and a bit of luck.
Close to 0% chance someone would find out, as that would involve the person revealing the question also facing consequences - unless the company has some elaborate scheme involving modified and unique questions tailored for each candidate, and keeping track what candidate got which question. But that obviously wouldn't work with a trivial question like the one OP got.
Either that, or some third party which could have intercepted the communication between OP and the friend revealing the question. But again, what are the chances...
And on a tangent - should candidates "grinding leetcode" reveal that they've encountered the question before? That's the whole point of leetcode.
I've seen candidates deny that they've seen the problem given, blitz through the basic version (intended as a quick warm-up), and then completely choke when a slight twist is added. Let's just say that really raises some questions...
> Companies ask interview[ees] to not reveal the questions they had to other candidates.
I'm not condoning the author's actions, but I don't think any company has explicitly told me that. (I assume by "interviewers" you meant "interviewees.")
It's not even a trick, though. The sum of zero and n is n. The sum of 1 and n-1 is also n. So is the sum of 2 and n-2, and so on. There are n+1 numbers when counting from zero to n, and they can be paired so that each pair adds up to n.
It's a pretty obvious thing that anyone who spent much time thinking about math as a kid or teenager would have encountered, and maybe that's who MS wanted to hire! Especially back then when more of their programming needs dealt with algorithms and mathematical thinking, as opposed to gluing libraries together, I think it makes some sense.
Just googled it, and it looks like he did is a little differently. He paired 1 with n and then 2 with n-1, etc... yielding n/2 pairs that add up to n+1. It still works out to (n+1) * n/2, though :)
Apparently biographers disagreed about his age at the time but they all had the same method and the same problem of summing numbers from 1 to 100.
It's a quiz problem, and it's supposed to have "trick" solutions.
However, if he wants to play that game, he should provide proof of his solution, not fiddle with syntax or error checking. That's why discussion is more important, and how he can show that understands what he's doing and not just memorizing tricks. (... none of which matters for his future role anyway.)
The formula "falls out" naturally if you're used to working with summations:
I came up with another solution (which is purposefully complicated):
It is known that the sum of n-th roots of unity is zero.
So if we choose the n-th roots of unity as ω and calculate Σ ω^ai, the result should be 0 + ω^(the duplicate number).
So I opened the python interpreter, and I used this very trivial method of calculation (instead of summing the sine and cosine functions independently), and using asin and acos functions, got the result. It turned out to be accurate for n=1e6 with an error of ~1e-5. So it should be usable for much bigger n too.
In my view the trick in this question is to think about adding up numbers not how you add them up.Since this was a programming question you don't need to know the formula you can add up the numbers in a loop. It wouldn't even be much slower since you need a loop of size N anyway for the purpose of adding up numbers in the input.
Xor solution and adding solutions are the same solution it's just a matter of what binary function you use for calculating sum. You can use any commutative, associative binary function which has inverse. You can use addition, xor or even multiplication.
I learned this formula before high school. It was considered trivial.
The demonstration was to write the sums 1+2+...N and N+(n-1)+...+1 and add them up position wise. The sum comes n*(n+1)/2 (divide by 2 for the two sums).
A company came to our school before a job fair and the recruiter talked at our club about what she does during her process. She mentioned that she writes short notes on the back of resumes to sum up her first impressions. So the next day at the fair, I saw her and turned my resume over and wrote "I love this guy, let's definitely hire him" and walked up and handed it to her and smiled and talked for a minute. Walked away and as she turned the resume over to make her notes I heard her bust out laughing. I got the interview.
I would not have though to use this formula. The sum of the integers grows as the square of n so if n is anything but small you will overflow and get an erroneous answer.
This interview question has everything bad imo: no practical uses, test knowledge of math formulas (which every math/CS major would have but none of the self learning folks). It’s very easy to stress and fail when given such a test, and even already knowing I would have tried something else because of the overflow.
Let’s not overthink this. Microsoft is using this test as a low-pass filter to get rid of candidates who would:
- not find any answer in a few minutes
- find a wrong answer and argue about it in an obnoxious way
Any reasonable answer would probably do.
You would probably get more brownie points for asking what you need to optimize for (compute, storage) than providing what seems to be the best solution (using the sum trick).
Exactly. It’s basically fizzbuzz. The fact that he thought about this in advance and had an answer ready to explain is also a green flag for such an early filter.
Yes, it's a question with a silly trick. Completely useless if one knows the answer, hard to spot if the person feigns struggle.
Although, n•(n+1)/2 formula is not necessary. One can start with an xor sum and find the duplicate by xor adding elements again. This is another silly trick.
That’s a very elegant solution. Hard looking problems that had simple, trick solutions were called Jewish Problems at the entrance of some universities.
This would let the examiner fail a student for subjective reasons instead of academic success. The examiner would then be able to say « I failed them because of their skills, not because of their religions, look how easy the solution is ».
Perhaps this is what we are reproducing as an industry with all our convoluted interview processes, and it may be a decorum to choose the candidates we want instead of using objective criteria.
I’m referring to the easy looking, tricky to solve problems. I’ve heard them referred to by that term because they have been used at Moscow University to discriminate against Jewish students but I don’t know if they have other names.
Of course, just the phrasing made me think the "trick solution" was eugenics, not a university admission trick. Unfortunately, historically "Jewish question" or "Jewish problem" has referred to these concerns [0]. Of course, following your first link it seems like the native phrase for it is in no way better, but that seems predictable as it's stemming from a racist premise in the first place.
It's interesting that doing competitive math makes it really easy to spot these kinds of problems and guess at their "true" difficulty. Honestly, I'm kind of surprised that "this problem is short" or "the solution is short" would ever fly as a measure of how easy a problem is, but I assume that a system that is intended to encode racism doesn't need a whole lot of logic behind it…
I think you missed the point of the second sentence.
It's like saying the phrasing on the Chinese Exclusion Act is unfortunate. It's not the phrasing that's unfortunate, but the history of excluding Chinese. These questions were designed to allow screeners to discriminate, and were named after the group designed to be kept out.
edit: If you edit a comment in response to a response, it's polite to say [edited]. Otherwise, the conversation is a non-sequitur, which seems to be happening here a bit.
I didn't edit my comment, at least not from what I remember. May have been a typo fix in the first few seconds though, which I do a bit too often.
Not sure if my comment was clear, but I was referring to "hard problems with trick solutions were called Jewish Problems", which sounds like it's referring to the Final Solution.
Reminds me of a funny anecdote, I was staying with a friend of mine in Berlin and asked her what the second most common religion was in Germany. She casually said "used to be Jewish, but not sure now..." She was of course referring to the influx of refugees from Africa, but for a very brief moment it looked like her life flashed in front of her eyes.
Could also just use a hashtable, the keys are the array elements and the items are the occurrence of each element, then return the one with an occurrence of 2.
> I would not have though to use this formula. The sum of the integers grows as the square of n so if n is anything but small you will overflow and get an erroneous answer.
As long as you can get wraparound semantics, the overflow is actually unproblematic. (n(n+1)/2 + k) mod 2^32 - (n(n+1)/2 mod 2^32) = k mod 2^32 = k.
Even with wraparound semantics, you can't compute n(n+1)/2 naively, because (n(n+1) mod N) / 2 ≠ n(n+1)/2 mod N.
So actually not knowing the formula is kinda advantageous, because computing the sum as 1 + 2 + … + n (with every addition mod N) gives you the right answer (mod N).
Or you can assume N is less than 2^31, and clear out the top bit in the final answer (because that's the only place the wrong values can come from). Which is admittedly pretty hackish, but…
Edit: The simplest solution is probably just doing (n/2)*(n+1) (assuming n is even; move the division for n odd).
True, but that doesn't matter at all given reasonable values of n. The number is in the range of n^2, but the algorithm is in the range O(1). Question is not that bad, my first thought was to use hash table to store what you see, then return when duplicate occurs. Don't like hash table fine, set an array of size n storing TRUE when you see the number. Notice it twice, then you've found the duplicate. No need for math, O(n) solution.
Honestly if you're stressing over a question like this, combined with thinking that integer overflow is even remotely something that you need to be concerned about in a question like this, you're definitely not passing any leetcode interview problems tossed around in today's interviewing culture.
Also it was 2004 and 64 bit machines weren't common. If I remember correctly you had only 2 GB available under Windows XP and if you wanted more, 3 GB to be more precise, you had to boot with a special parameter.
32-bit machines generally 64-bit arithmetic of some sort; for example "long long" in C is mandated by the standard to be of a width greater than or equal to 64 bits.
Yeah, 64 bit integers were available under gcc on Linux, but the memory issue remained. The array had to fit in 2 GB, unless of course the problem stated otherwise, for example the numbers were read from a file.
Ok, so how are interviews fair at all then? How do they really tell anything about the person, other than the fact they are good at interviews? How is it fair that all the other people queued up to interview didn’t get a shot because they didn’t do as well in a 5 minute high pressure period? This 5 minutes probably determined the courses of their lives. What the fuck? Does anyone feel as flabbergasted about interviews and tests? I just cannot do them, I need time and space to think.
I once worked at a tech-focused games company (sadly no longer existing) which had the best interview process I’ve ever seen.
They had this massive programmer test. It was something like 40 pages long, hardcopy, double-sided. With answers needing to be written on the test generally in essay format; no computer allowed (and so no real coding involved; it was all about concepts and not about syntax). It covered everything; math, physics, logic, sound, calculus, hardware, etc. The thing was so long that we estimated it’d take a really strong applicant about four hours to complete the whole thing if they somehow were experts on all the topics simultaneously.
We informed the applicants about the test’s length upfront; that it was designed to be a 4 hour test, and that they were only going to get to spend one hour and that we absolutely didn’t expect them to know everything (or even most things) on it. That the point was for them to pick the questions they were most interested in and to only work on those ones.
And then we never formally scored the test.
Instead, we basically used it as a conversation-starter for the interview which immediately followed the test, using it as a springboard to talk about their understanding and skills and why they had selected to do one section over another, or about particular questions which they’d provided interesting (or problematic) answers to.
The “here are a whole lot of questions, answer whichever ones you want, you can’t answer them all and we’re not scoring you on how many you get right” approach always felt kind of ‘fair’ to me in a way that pure interviews or coding questions never did, for me.
(caveat: I wasn’t hired using that test; I had been hired as a junior long before, based on my portfolio and a short interview, and the folks who did get hired via taking the test may not have liked it as much as I did. But I loved that it didn’t hang everything on a single gimmick code question the way I’d seen from a whole lot of other companies)
> caveat: I wasn’t hired using that test; I had been hired as a junior long before, based on my portfolio and a short interview
That's always the catch. The founders and initial employees of a company never had to go through the crappy hiring process that the company adds later as it gets bigger. And then we claim that the tests make tech a "meritocracy" and "objective", but those at the top are exempt from the tests.
On a related note, evaluating the quality of tests is even more challenging than writing them.
I recently tried interviewing for a growing small company, who nullified the initial good impression with a multiple choice test about certain technologies they were using, administered over the web by some test company.
The best questions were "which of these four functions or classes do you use to do $common task with $framework", testing documentation speed reading skills rather than actual coding skills; other questions were ambiguous, debatable or completely wrong.
>The best questions were "which of these four functions or classes do you use to do $common task with $framework", testing documentation speed reading skills rather than actual coding skills; other questions were ambiguous, debatable or completely wrong.
Sounds like testgorrilla. I swear they have a poor markov-chain based AI generating the questions.
Modern not-quite-AI might be able to figure out reasonable questions from high quality source material (e.g. StackOverflow questions) and synthesize wrong answers, but competent human reviewers are still needed and this is probably the weak point of the process.
This is all true, although note that I was not a founder or initial employee; I definitely arrived during the second half of the company's decades-long lifespan. The test was just developed years after I was hired, and I was not involved in its development in any way (except for once taking it to act as a baseline for what a senior programmer's answers might look like).
I just thought it was a really neat and kind idea to let the applicant choose what question or questions they wanted to discuss and in what order, instead of forcing them to answer a single pre-defined high-pressure coding question and hang the whole interview on that.
The least I would do is politely decline such an interview. I would be sorely tempted to give them the choice between letting me use a keyboard or hearing from an ADA lawyer.
I mean, obviously exceptions were frequently made for folks with special needs or just personal preferences. I’m aware of many times that was done for both situations.
I assure you that I’m not a monster and I would really appreciate it if you’d assume positive intent in such replies.
That isn't obvious at all, you explicitly say 'no computers allowed' and yeah, I consider a forty-page handwritten essay a sadistic way to find out more about a computer programmer.
I don't think you're a bad person for it, and ok, good to know you're willing to make accomodations, but my reaction to being asked to do this would be sharply negative. The keyboard is inherent to the profession.
Assuming you read the essay it is impossible to not judge the applicant on their penmanship. A difficult skill with absolutely no bearing on the qualification for the job.
I urge anyone reading this to not offer a 40 page handwritten essay to software developers in the first place. It's an awful idea.
I have explicitly and repeatedly pointed out that individual applicants each engaged with only a very small portion out of a very large test — the entirety of which had its questions printed across 40 pages.
There was obviously no “sadistic 40 page handwritten essay”; individuals engaged with whatever individual questions they wanted to, and would normally write their answers into the bits of blank space left in between the questions. I’d estimate that a normal applicant who answered ten to twenty questions would normally write substantially less than what would constitute a single page of text in total.
Again, I’m not a monster. I’d really appreciate it if you’d assume positive intent and ask for clarification rather than jumping to the worst possible interpretation you can invent and then stridently declaring that you’d take legal action on the basis of the fictional “sadistic” thing you’ve chosen to believe I was making people do.
Why so aggressive? What's the problem with the pen? The idea the OP proposes is to use it as a spring board to get a discussion going, I'm sure a pen, a keyboard or a interpretive dance would all work for what they're proposing
wow. Does ADA lawyer thing work with whiteboard interviews?
I'm only half-sarcastic, I hate my handwriting and this makes whiteboard interviews double hard for me.
Probably not, because the ADA criterion are actually reasonable, and long handwritten essays handily fail it.
Basically, don't test for something which isn't a job criterion and excludes people based on ability. An absurd example would be asking programmers to lift a 20kg sack of flour onto their shoulder and carry it across a room: this is a legal and normal thing to ask if the job involves lifting things, do it for a desk job and you'll get sued eventually.
Whiteboarding is an actual part of the job at many companies, I just let them know that words will probably be illegible and muddle through it.
No software job calls for handwritten pages of text, it clearly discriminates on ability and it shouldn't be a part of hiring. Simple as.
I wanted to add a smart remark saying that once upon a time, in better times long gone, a long time before leetcode was invented, handwriting itself was used as a criterion to hire.
Then the first hit on google was a paper from 2018 about how to hire based on handwriting.
> Does anyone feel as flabbergasted about interviews and tests?
Yes. You're at worst the average, at best part of the majority.
Almost everyone sucks at interviews and most job hiring processes are incredibly degrading. Feedback is terrible (includes no feedback). Hiring managers are all looking for different things, either subtly or wildly. Onus to get good at interviews is entirely on the individual, not on the company to make the process less of a hellscape. Hiring managers are largely biased, untrained, as are most interview processes. Many aspects of interview processes aren't even grounded in reality.
But almost nobody is talking about this as it's just something you "get done" and "bite through" once every N years. Plenty of perfectly capable people fall to the wayside and are told they are the problem. Or worse, you get a bunch of (LinkedIn) thought leaders trying to gaslight everyone into thinking corporate holds the truth and the remainder of us are peasants who simply don't understand.
It's never been as easy to interview with multiple companies as it is now. It's a numbers game, and I would (and have) had interviews purely for practice, or our of curiosity about some companies tech stack. If you make it all about the numbers, suddenly you feel less bad about blowing an interview, or filtering bad ones out early in the process.
> not on the company to make the process less of a hellscape.
I mean, they do suffer in the long term. Companies after all, are the products of their hiring processes.
Interviews often aren't fair. However, they don't have to be quiz-style.
When I conduct interviews I simply have conversations to explore subjects as if I were talking about an issue with a coworker. I tell them directly that my goal as an interviewer is to give them an opportunity to showcase something they know so I can say good things about them. I give the interviewee a choice of subjects and I let them change the subject. If the interviewee doesn't know something, I explain it. We work together, as partners, to find their strongest area -- and then we pursue it until we reach a limit.
I also tell them that I will keep exploring the subject in question until we run into things they don't know, or that I don't know. I reassure them that I expect to reach a point in our conversation where we just say "I don't know" and that it's totally OK and expected.
After the interview, I assess the communication. What did they know? What did they ask? And perhaps most important: What did they learn? Were they defensive about the boundaries of their knowledge, and how did they deal with that?
I find I usually have a very detailed understanding about the interviewee's areas of competence as well as their communication abilities. A strong communicator and learner is far more valuable than someone who can recite a few technical details.
I think quiz or challenge style interviews are easier. The interviewee doesn't need to be skilled and doesn't need to risk exposing their own ignorance on a subject - often nontechnical recruiters administer these. They can be used to maintain an illusion of superiority on part of the interviewer and company. It's perhaps a similar defensive dynamic as which keeps peer teams from openly interacting and problem-solving, when teams challenge one another with problems rather than opening up about what they know and what they want to know.
You are criticizing the "quiz or challenge" style interviews, but you are basically describing a quiz interview. I don't think that most people just expect you to know the answer (like they may in other industries or even government). They expect you to don't know the answer, and then they will try to lead you to it and see your thought process. At least this is my style too.
You could call it a free-form interactive essay interview. Pick any subject and converse on it however you like. If it's not going well, pick any other subject.
Is there that much difference between a series of questions and a series of subjects ? I am assuming it's not really "pick any subject you like" , because most subjects are going to be absolutely useless to ranking the candidate -- it's going to be "pick a subject from a list of these subjects".
And there is a reason most _interviewee_ guides tell you to always be honest and say "I don't know". That's to kickstart the discussion/next question as soon as possible rather than unnecessarily get stuck in the "bullshitting" phase that helps no one. It's rather common to encourage this, not a rare thing.
> I am assuming it's not really "pick any subject you like"
It appears your apparent confusion is due to this assumption. It's the opposite of the process I described above.
I meant exactly what I said. The candidate can pick any topic they like. I trust the candidate to pick a topic to showcase their own skills -- and if they don't, that's another useful datapoint for the hiring process.
There's a huge difference between using a predefined process vs letting the candidate drive. It guarantees we won't waste time talking about subjects the candidate isn't familiar with, and that we will focus on their strengths. Figuring out a candidate's strengths is the entire point of interviewing!
It's also relevant to the "fairness" issue mentioned above, for the same reason.
This sentiment gets shared a lot, but what's a better alternative? Without ignoring the reality that you only have 15-20 minutes with each candidate, some of them will be brilliant, and at least a third or more won't be able to code their way out of a paper bag. Oh, and keep in mind false negatives have almost no downside but false positives hurt the recruiter financially, and hiring bad people is expensive.
> keep in mind false negatives have almost no downside
Can it be said that refusing to hire women, for example, has almost no downside? In my opinion, this is a kind of ethical issue, because the "false negatives" are not just random. Audition-style coding quiz interviews tend to systematically discriminate against people who don't interview often, who haven't recently studied CS in college, who don't have time to "train" for interviews, or who tend to have situational anxiety in job interviews (which is fairly common, and not an indicator of on-the-job anxiety). A study sponsored by Microsoft itself showed that these interviews test for anxiety rather than skill. https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
Remember that the author said, "A few weeks later I’m about to go in for my interview and I’m so nervous I can barely think straight." These screening tests were all-or-nothing, so if he flubbed the question, he was eliminated. You might respond, "Well, he made it through the onsite interviews." Yes, that's precisely why using coding tests as screening is so pernicious, because a short screening test is not a good indicator of what someone can do given more time and under better working conditions.
>Oh, and keep in mind false negatives have almost no downside but false positives hurt the recruiter financially, and hiring bad people is expensive.
This gets repeated over and over, makes sense rationally on a superficial level, but falls apart once you think deeper into it without substantiating it with evidence.
We don't work on a binary false positive / true positive scale. We don't know the efficiency of each variable going into the equation with which we filter false positives. Layering proxy on proxy doesn't guarantee an increase in the ratio of true positives to false positives. All these variables are costly and subject to diminishing returns. At the end, the workplace is still arguably a far bigger deciding factor in the outcome than who you hire.
If you're a big corp like MS getting at least a few dozen candidates after initial automated filters, that's one thing. If you're a relative no-name with a handful of candidates and a fat management layer pulling these shenanigans, it's about time we get real and call them out.
> At the end, the workplace is still arguably a far bigger deciding factor in the outcome than who you hire.
I really don’t think this is true. Are there any successful programming companies who just hire whoever for development work? All the top-tier ones have settled on being extremely selective. Of course, that could be coincidence or bias… but this practice is fairly expensive, so there would be nontrivial pressure against it. Furthermore, I think a lot of people can attest to working with both very good and bad developers on the same team - so even inside a workplace you see a range of individual productivity.
Of course it does. Have they seen the question before? Are they really good with math? Are they really bad with math? Do they even know how to approach a mathematical problem like this if they've never seen the formula before? Do they even consider that there might be a mathematical formula to determine this, or do they immediately just try to brute force it?
We can debate whether or not any of the above is useful information (I think it is), but not giving them the formula definitely gives you more information than just giving it to them.
Yeah, I think this is the crux of it. Hiring sucks for everybody involved. I hate it because the process is ugly and the cost of failure is enormous (emotionally to me, financially to my budget, and personally to my reputation).
Yeah: they’re literally filtering incredibly talented but shy people and taking people who are good at bullshitting and potentially are talented. It’s really not fair for people who have a lot to offer, just not in a highly anxiety-inducing 5 minute time slot.
I also need "time and space to think" (and so would most people), but given the choice between someone who needs time and space to think, and someone who doesn't (either works well under extreme pressure or is just that self-confident), who would you choose?
Sure interviews are unfair (there are many problems like the one described in TFA, as well as people who just practice the skill), but are there better options?
> but given the choice between someone who needs time and space to think, and someone who doesn't.
I’ve worked with people who needed time to think, but at the end of that time came up with better solutions than the people who were quicker.
High pressure leetcode tests select for a specific type of thinker who may or may not be good at solving the problems you’re actually hiring them for.
> but are there better options
I’ve had success pair programming together on a problem you both don’t know the immediate answer to. I’ve also had success with allowing candidates to choose take home assignments.
I’ve also had success doing what every other other industry does: trust their resume, ask them to talk me through projects, and talk to references. Then fire them quickly if it turns out they are one of those dreaded fake programmers that everyone is worried about.
> I’ve had success pair programming together on a problem you both don’t know the immediate answer to.
This is not different to what is being described in TFA -- you do discuss with the interview in order to reach the solution, and as many have said in these comments already, if you just lash out the solution without revealing your thinking process, many interviewers get disappointed and may throw you another problem.
They are not simply asking you for your leetcode ranking (or whatever the name of the-site-of-this-week for this type of problems). That may actually be much more fair, but it is a much worse experience.
> I’ve also had success with allowing candidates to choose take home assignments.
I was giving take at home assignments until one candidate basically scolded me for wasting his time with these. I think he actually had a point -- I would probably refuse a take at home assignment myself -- and I have since stopped giving them (we hired that guy and he became a friend of mine). They are also not very fair -- they are skewed towards people with more free time at home -- and very prone to cheating, so you have do the whiteboard discussion afterwards. Overall I find this one of the worst experiences.
> I’ve also had success doing what every other other industry does: trust their resume, ask them to talk me through projects, and talk to references.
In the same way that the whiteboard interview is the only practical method I know for junior positions, at some level of seniority this becomes the only practical way to hire people. But like the whiteboard interviews, this is practically the opposite of fairness. Like in every other industry indeed.
>This is not different to what is being described in TFA -- you do discuss with the interview in order to reach the solution
It's very different. If the interviewer already knows the answer and is careful not to give it away, it creates an artificially adversarial process that is completely divorced from the reality of the job.
Working together to solve a common problem is a much more accurate work sample test.
>if you just lash out the solution without revealing your thinking process, many interviewers get disappointed and may throw you another problem.
Knowing the answer upfront makes it much easier to explain your thought process in a way that makes you look smart. Many (most?) companies doing leetcode interviews are more interested in you correctly solving x number of medium-hard problems than they are in hearing how you think.
>They are also not very fair -- they are skewed towards people with more free time at home
That's why I've given them as one alternative among several.
>so you have do the whiteboard discussion afterwards.
You can talk to them about the problem and ask them to explain their decisions. Also if someone cheats and the result is that you hire a fake programmer, fire them.
>this is practically the opposite of fairness
Leetcode interviews aren't more "fair" they just test a different skill than other types of interviews. The hope is that the skill they test is more correlated with job performance than other types of interviews. I don't think that's true.
Thing is, you can get the 'fake' programmer even with algorithm tests since they are only looking through a keyhole at someones overall employability. For many (most?) jobs work ethic, attitude, and don't be an asshole are all more important after a minimum programming bar is met.
Admittedly I've never had to hire at Google/MS scale, but my best luck hiring has been like you said - talk to people and be up front about expectations and that we fire if needed.
I’d pick the person who can prove themselves capable in their own way. Their tyrannical measure of capability simply rubs a lot of people the wrong way. I should not be pushed aside because I’ve got anxiety issues stopping me from jumping through their fucking little hoop.
I'm honestly disappointed that I've never faced an interview with a question like this. I think this kind of test is fun and a good chance to show off liquid thinking skills. I did them for practice for a while in college preparing for the job market but then it just never came up.
Solving a toy problem on the fly in a language you're going to be working in seems totally fair and reasonable to me.
Our candidate found us via a college campus job fair and was given a Codility test for screening. He didn't do particularly well, but got through and, unfortunately, was given another Codility test by mistake.
I suppose he got upset at that point and just copied the solutions from a friend, who was also applying(we only had four sets of questions). That score was of course considerably higher, even though he made the exact same mistakes his friend did.
We found out what was going on and had reservations whether to continue with the process, but he was invited to the second round and aced it.
I think he spent around a year with us and left for a much better paid position.
Overall that Codility test was wholly unnecessary (both the first and the second) and got me thinking how many talented people never made it to the second round because of it.
EDIT: I checked that candidate's current LinkedIn profile and at the moment he's a Tech Lead at globally recognized big data analytics company.
I told that story to my friend's daughter a couple of years ago. Next time I visited she was excited to tell me how she used it to win a sheet of stickers by betting one of her classmates she could add up the numbers faster than they could with a calculator. It was clever of her to add the calculator handicap into the mix. Makes me wonder if there are math hustlers outside of casinos.
"So pretty much, my entire career is built on one amazing stroke of luck."
This, to me, is the buried lede. Much of success is due to luck. Not all; some people on balance are more talented and persistent and hard working than lucky. Others have more luck (a referral, inside info for helping them prep, etc.). I just landed a new job that I am quite confident I would not have been considered for without a referral from someone close to me working for the company already.
After multiple rounds of interviews and assessments I am confident they feel I am a good match, but without the luck of that referral I very well may not have gotten past the call with the recruiter.
I've been explicitly told on a phone interview that "we really wouldn't be considering someone of your experience without the referral". Nailing the technical interview and getting the job felt amazing, but that referral came in _clutch_.
I recently had an interview with a startup that asked me the same exact question that I got from a faang interview the week prior. It was a problem I hadn't practiced/seen before the first interview, but I was able to figure it out just before we were out of time. In the second interview, I stopped him right away once I realized I had just seen it, explained the solution that I came to the week prior, and he went on to choose a much more difficult problem that I couldn't solve in the time requirement.
I regret nothing -- it was a better spend of time for both of us. Interviews are bullshit, but they're not such bullshit to me that I'm willing to sit there and pretend to have a eureka moment about a question that I already know. I had the opportunity to show my skills and he got to see me struggle through it, and that's what it's really about. By the time you get to a final round, they moreso want to know what it's like to work with you than they want to know what you know.
If you're ever in this situation, there's really no wrong answer. Play pretend and look like a rockstar, kudos, or be forthcoming and show some ambition -- also kudos. Job interviews are stressful and I would never fault someone for playing dumb. OP shouldn't feel like he needs to explain his sins. This is a systemic problem with leetcode style interviews, and it's not your job to correct for that as the candidate.
When I interviewed at my current company, I was pretty stressed about the interview and watched some Numberphile videos the night before to take my mind off things.
Weirdly enough one of the problems discussed in the interview was about the Josephus problem which has a neat solution in binary [0]. I don’t recall if I ever asked the interviewer whether they also watched the video recently or how they came to think of it.
I've got a story of my own that has some remarkable similarities to this one. When I interviewed with Microsoft, they asked me to write a program that detects whether the stack grows toward lower address or higher addresses. Since I had studied computer engineering with an emphasis on CPU architecture, this was trivial for me, and I got the job.
A few years later I interviewed with Google, and they asked me the exact same question. I didn't tell them I've already done this question with another company, in part because I knew the answer the first time around and didn't see the point in potentially torpedoing an opportunity to work at Google. For another interview question at Google, they asked me to write a heap allocation algorithm for the Linux kernel, and since I had recently written some kernel code, I happened to know (at the time) exactly how to use the kernel linked list manipulation macros from memory, which really impressed the interviewer. I ended up getting the job at Google too.
Both jobs defined my career in many ways -- especially the Google gig. I've never performed quite so well on coding interviews since then, but somehow internal references and prior accomplishments seem to give enough momentum to make mediocre coding performance a non-issue. In fact I've never interviewed for a job for which I didn't end up getting an offer.
In my case, I really did spend a lot of time in college getting as much exposure in breadth and depth to computer architecture as I could, and so I feel I earned my career. But at the same time I can't help but wonder to what degree dumb luck came into play with respect to the interview questions I got asked when I started out in Big Tech.
> they asked me to write a heap allocation algorithm for the Linux kernel, and since I had recently written some kernel code, I happened to know (at the time) exactly how to use the kernel linked list manipulation macros from memory, which really impressed the interviewer.
> seem to give enough momentum to make mediocre coding performance a non-issue.
The arms race of coding interviews legitimately keeps some of the best most experienced candidates out of the candidate pool, replacing them with newbies who have time to make cheat sheets with every new type of leer code question, and maybe that’s the goal. When question lookup, exchange, cheating etc happens, it makes interviewers pick and design increasingly harder questions over time. That makes it impossible to pass interviews without months of prep memorizing/practicing the majority of latest questions, or cheating. What you lose are ethical candidates, or those with better things to do on their hands. That may be a feature and not a bug - you are left with those who will do the grind and do whatever it takes, until burning out in their own turn. After all the most intense hiring competition happens right out of college - capturing the developers with little experience, a lot of energy, and complete nativité on burnout. The companies that cause the most burnout, are the most intense competitors in that space too.
That’s exactly the point of the interviews. Companies are looking for some combination of dedicated enough to grind endless problems, moderately high IQ, not “old”, willing to sacrifice for the company, etc. On top of this, managers are often looking for cultural similarity, same educational backgrounds, and more.
If you want a company to have to take on and train engineers, well, that ship sailed in the 90s.
I recently got interviewed by MS, I met 3 individuals on the team hiring, they discussed what I'd done previously, and what they were doing now.
The first interviewer was focused on culture and values.
The second interviewer asked me to describe how I'd approach pathfinding a simple 2D maze, and explicitly told me that they weren't worried about "best" algorithms like A*, but were more interested in how I'd model the problem in the first place, and seemed happy when I suggested building a graph as a better way to reason about it, and write readable code than just index twiddling a 2D array.
They then asked me to code review a pre-existing index twiddling solution, they liked my suggestions, and I even picked up an error (that didn't seem deliberate) that one of my suggestions would've prevented.
The last interviewer was more interested in architecture, and their only technical question was "name a design pattern you've used and why you used it".
Then they asked me to submit a GitHub repo that translated Roman numerals into Arabic numerals in Go, with a specific requirement to "obey Postel's law".
At the same time, a small medtech firm looking to recruit me for a data engineering role had me meet two engineers for an hour, then complete an online coding test on one of those annoying online editors, where the goal was to calculate waiting times in TypeScript from ISO-8601 formatted strings.
Then I met more of their engineers, got asked trivia like "What's the difference between ETL and ELT?" and then did some live coding on that same annoying online editor to implement the "maximum sub-array" problem before discussing Big-O...
I felt like they'd taken algorithmic questions you'd use for a recent CS grad and applied it to a senior data engineering role where if I'm ever needing to calculate the maximum sub-array in TS, you're doing very many bad things.
So all in all, MS's interview technique felt far more relevant and useful.
When I did my geography exam at 16 I'd given up with normal revision, so I spent the morning reading about one particular extremely obscure topic - something like the natural resources of Nigeria - because it was on the back of the weekly installment encyclopedia my parents were buying for me.
It hadn't been mentioned in class. It hadn't even been mentioned as a possibility.
But it came up anyway. I wrote a nice little mini-essay on it, and I aced the exam.
I suspect that happens a lot in exams and job interviews. You get $random_question and it's supposed to be a test of broad knowledge, because clearly if you know the domain you'll know $random_answer.
But it doesn't exclude people who are lucky. (Or possibly mildly precognitive.)
Ultimately, interviews are about a process of elimination. There are M applicants and N spots open. If M>N (which is most cases) we need some way to go from M candidates to N job offers.
How do you run this selection process? One way to do this is to ask the applicants who are all the candidates who can do the job. But this is a lousy way. Some people might simply say they are qualified even though they are not.
Recruiters obviously need some way to filter out the candidates who cannot do the job. But let's say that even after doing that, the number of qualified candidates are still greater than N. What do you do now? Obviously, the company should hire those individuals who, when hired, maximizes the value to the firm over the tenure of the candidate at the company.
Obviously, the company cannot simply ask the candidates who are the most valuable, because each person might respond that it is they themselves.
So, the company is ultimately looking for certain signals. These signals, if present, indicate that the candidate, when hired, will bring maximum value to the company over their tenure.
However, once the candidates understand that these are the signals that a company is looking for, they can fake it[1]. For example, in this case, the candidate figured out that the company asks toy problems in the interview and memorized the answer, albeit in this case, accidentally. However, nothing is stopping a candidate from doing this deliberately. In this case, the author is reliably able to emit this "toy problem solving skill" signal even though he may not have been able to solve the problem in the time allotted during the interview. However, the company was unable to detect this possibly false signal and therefore, he was hired. In this case, it does not look like a bad outcome for most people involved
This problem of minimizing false positives would be an interesting problem to solve. A company that solves this problem well will probably enjoy a huge competitive advantage in the market.
Arrest this man! How dare you practice for an interview? /s
Granted some people practice 100+ questions, you practiced only 1, and it was the right one. Same same.
Lucky indeed, but I wouldn't attribute your success to luck. You were clearly a good enough engineer to receive 2 offers, and good enough to build a career there.
We all have multiple encounters with low-probability scenarios in life. If you have a 10% chance of succeeding at something, and you have 50 attempts, and you only need one success, then your actual chance of succeeding is 99.5% rather than 10% - almost inevitable.
I think it's fair game. You called ahead of the job fair, which allowed you to prepare.
They were also lazy with their recruiting questions.
If they wanted to select on skills instead of knowledge of interview question gimmicks, they would have asked for a link to your profile showing off your work, and look at it after the fair.
I remember this formula was part of a book called "Formelsammlung" (german for equation-collection) that we were allowed to take to math exams in university in cs. This is a simple know or don't than you have to deduct issue.
That’s not cheating, that’s not a problem at all. Neither ethical nor otherwise.
You happened to know a working solution, this was by chance, but you also managed to sell it, explain it and it’s a solution you developped.
And the fact that the poster did well on the full-day follow up at Redmond and was invited to join either of the teams he interviewed with means that he was certainly qualified to pass the on-campus interview.
The whole game of studying is predicting what's going to be on the test, rather than nobly mastering the material in general and then doing well on the test by applying your knowledge. Anyone saying this is cheating either did badly in school, spent impossibly exorbitant amounts of time on school, or is being a hypocrite.
Also, if the article hadn't revealed the interview question, I would've assumed it was like, write out a proof of Fermat's last theorem or something. Even if you don't think of comparing the sum, the next obvious solution is to use a hash table to track duplicates, which I highly doubt they would've failed someone for. So basically this is a story of someone's non-cheating on something relatively trivial anyway.
This probably increased the author's chances of going to hell about as much as standing next to your friend in 7th grade while he smoked a cigarette contributed to your chances of lung cancer.
> nobly mastering the material in general and then doing well on the test
This is what I almost always did, because I was there to learn and wanted to better myself and actually know the material. Sometimes I'd know some nonsense was on the test like memorizing an arbitrary complicated formula but that was the exception. Always tended to do well too.
Could be different era/circumstances, but when I was in school this would've been impossible. There was just way too much material to cover. If someone from my high school had claimed they aced all their classes by actually learning the shit out of every subject, I would've been like, either you have a 200 IQ, or you have more hours in the day than me, or you're actually doing some version of this: http://paulgraham.com/lesson.html
The question is very unrealistic... how often do you know there is exactly one duplicate in a list?
Much more common is there are zero or more duplicates.
Here is what I came up with:
- We need a way to record what has been already seen
- A hash-map could work, but I think we can be more efficient
- We know that all elements are less than the array length in size...
- So we can allocate a single array of flags with the same length as the input
- The flag for value `n` is at position `n` in this array
let findDuplicates xs =
let seen = Array.create (Seq.length xs) false
let mutable duplicates = []
for x in xs do
if seen[x] then
duplicates <- x :: duplicates
else
seen[x] <- true
duplicates
I'm pretty sure this is O(n)?
I think it's interesting that the mathematical trick (sum of numbers 1 to n formula) does not work in the more realistic variant. This fact is probably why leet-code problems are so disconnected from the real world. It's like AI for board-games.
The question isn't really about finding duplicates in a list, but a slightly backhanded way to ask "do you remember high school math and can you apply it". A less artificial problem would just make things more complicated.
Also, your way is O(n) memory when O(1) would be enough for the original question.
Always start a programming interview by asking questions. You know there is exactly one duplicate in the list because you wouldn’t start coding without thinking about what the problem left unspecified and getting the interviewer to clarify.
I don’t think this person would have done badly on the interview if they hadn’t practiced the question in advance. At least according to the narrative, when they first heard the problem they thought about summing the numbers: presumably they would also have gotten there during the interview.
It also begs the question that a direct path to “perfect code” is the intended goal. Admittedly this story takes place quite a while ago and there’s no one approach to interviewing in big tech, but I think it’s safe to say it’s generally a more nuanced evaluation. In a situation like this, the textbook approach is to start by proposing a quick and dirty naive solution, like storing all the seen values in an array, and telling the interviewer why or under what conditions you think it’s a bad solution. You could realize that there’s only one bit needed, so you could track eight values per byte. That’s probably the point at which the interviewer might prompt you to start coding, since there are a few details to get right to show that you know how to implement a simple algorithm, and there’s opportunity for followup about boundary conditions, scaling, big-O, etc.
At that point, you may have enough time for another prompt like “can you think of a way to do it without an array to store all the values?” If the candidate is still stuck, I’d offer them “what if I give you this formula for the sum of the numbers from 1 to N?” Similarly, if at some point earlier on they said “I think there’s a formula for this”, I’d probably give them a minute to think about it and then just tell them what it is. Because I want to move on to see if they can implement it.
Are a lot of FAANG interview questions math puzzles pretending to be programming questions? Unfortunately, yes. It’s hard to avoid when you have a people who are smart at math and not particularly skilled at interviewing. They tend to create questions based on something they’re impressed with themselves for knowing. I’m not suggesting anyone has solved the problem of how to decide, based on 45 minutes talking to someone, whether they’re going to be successful at the job.
I wouldn't even call this cheating to be honest, people practice interview programming questions all the time, he just practiced the right one for the day.
Every time the topic of cheating comes up on HN, I become increasingly disheartened by the amount of people chiming in who think it's not only alright to cheat but also laudable to do so.
Ethics are foundational to engineering. Jettisoning them is a sign of a discipline in decline.
Cheating is bad - this is an overly broad and generalized position, isn't it? Lets say the blogger had seen that n+1 question online somewhere or in a book (instead of hearing from his friend), before the interview. Is he obligated to inform the interviewer in this case too?
There are many people who get stressed and can't really write good code in an interview setting, but are perfectly capable of writing great software otherwise. Lying in a software job interview (especially when you know you can do the job well, if hired) is totally different from lying in an emissions test like Volkswagon did.
As with most things in life, ethics isn't black or white, it is much more nuanced and complex. This is not to say that one should be unethical at every chance, just that reducing a hugely complex topic like ethics to binary is naive.
I'd like to agree with the statement Cheating is bad. I don't think that's overly broad and generalized, or not nuanced and complex enough, or naive. Like the GP, I'm amazed at the number of people on here[0] who somehow seem to think cheating is fine. In real life I've never heard anyone defending cheating as ever a good thing, I guess. When I hear the word "cheating", it..just sounds like an obviously bad thing. Seems not everyone has that response?! I would have thought it's basic to human decency.
[0] Last time was a week ago, when I and others responded to this comment, which seems to be saying, cheating is ok if the reward is big enough: https://news.ycombinator.com/item?id=31546436
I am not saying cheating is fine, all I am saying is that it is not as rigid as rules in mathematics. If we are just talking in strict theoretical sense, sure, all cheating is bad. But life doesn't work that way. This is why we have courts and judges and lawsuits.
My guess is this (based on nothing but personal opinion) - most people would say cheating is bad, but the same people wouldn't be surprised at rampant cheating that happens around them. They may themselves even cheat, if they get a chance. Whether we like it or not, cheating happens all over, so people are just used to it.
I desperately wish there were some kind of equivalent to the Bar Association for software. A higher power that can punish blatant ethical violations in the face of the relentless greed of an engineer's boss, company, or industry. I think of the Volkswagen emissions snafu and how that might have been handled differently if the engineers had something with teeth to use to push back against unethical and illegal practices.
On the other hand, I feel that it would be a moot point. 'Ethics violations' require a code of ethics and an intent to violate them. I was recently at a meeting where an engineer was describing how they used an A/B test to prove that creating an extra modal dialogue in the account deletion process reduced the number of people who deleted their account. They described the entire process as being good for the user, who might be 'confused' about 'accidentally' deleting their account and how they would be more 'empowered' to 'remain loyal'. I realized I was listening to someone describe a dark pattern, but this person was convinced that dark was light.
> I desperately wish there were some kind of equivalent to the Bar Association for software.
There are many bar associations, not just one. The American Bar Association is a voluntary organization with no punishment power. Some US states have mandatory bar associations, other states don't.
Whenever someone suggests a professional organization governing software, it's usually overlooked that all such organizations are only regional. Ultimately, the power derives from local governments.
Is it cheating if the person asks his recently hired friend what the interviews were like and he just happens to get the same question?
This is a case of random chance and Microsoft not having a wide enough of an interviewer pool. It didn't seem willful, malicious, or pre-planned on the part of the candidate.
How would you respond in the moment? They admitted they were shocked to see the question. They were probably expending so much mental effort to maintain composure that the thought never crossed their mind on how to appropriately handle the scenario. High stakes and nerves. That's not at all what they prepared for.
I can almost guarantee you the "friend" was not supposed to disclose what the problem was that was asked of him. It's not a problem of the pool. It's a problem of the ethics of both his friend, and him.
Also "cheated" for my campus interview for a Microsoft internship -- there was enough demand and limited slots that they'd set a minimum GPA if you wanted to get a campus interview slot, which I wouldn't have met so didn't even apply.
My friend got one, though, and she was scheduled near the end of the day. Her interviewer mentioned to her that his last slot had cancelled and hie was just killing time until the other interviewer was done and they were heading back to the airport... So she tells him she knows someone and calls me to run across campus to the career center to catch him before they left.
Ended up w/ the internship and my first FTE job out of that.
That's neither cheating, nor pure luck, but good preparation. I've gone through lots of questions asked in interviews and if I got one of them for real I'd answer it immediately without an ethical soul searching
I've had similar experience - in an interview for my current job I got asked same question that I've already encountered in a previous job interview. It must be pretty popular in the area :)
It wasn't hard, and I solved it first time without help so it didn't feel like cheating, but I told the guy afterwards anyway. I did tech interviews from the other side before and from my experience having the perfect answer doesn't matter that much - what matters is showing how you solve problems and that you're familiar with common solutions and trade-offs.
When I asked well-known questions like this in an interview, I usually ask the candidate if they have seen the question before. Almost everyone says "no."
But if you then go on to solve the question without thinking about any alternatives, red flags go up. Even worse, some people would try to pretend that they didn't know the answer. Their line of thought to the solution would be a LOT more linear and less branchy than someone who truly didn't know. I would never fail someone who found the answer to the question, but I did note the possibilities: either they lied about knowing the answer, or are very smart and lucky to get straight to the answer.
Now, I was happy if the candidate said "yes" and gave me the solution. Then we could move on to something else (usually an easier question), and I noted your preparation and honesty for the hiring committee.
Almost everyone who said "yes" got an offer at that company. Almost everyone who lied about their "no" didn't get hired.
By the way, this particular question has an easy way to weed out the mathematicians from people who are well-prepared: add another repeated number. It's possible to solve for both that are repeated.
In 2012, I moved from a long-term job to a small startup. I was the first engineering hire for the startup, and they had started building their product with consultants at Pivotal Labs. They also used Pivotal to test my programming ability -- I did an interview in which I implemented sets in Java in a style where the interviewer actually typed the code, I told him what to build.
That startup failed pretty soon afterward, and I got an interview at another startup -- that had also used Pivotal as contractors. That startup did its own interviewing, but they had liked Pivotal's style of interviewing, so I went into an interview with the CTO who started saying, "Okay, we're going to build a set in Java, I'll type the code..."
I said, "Look, I'm happy to do this interview, but I've done this exact thing before. Why don't you let me sit down with one of your coders for the time period you've allotted to this, and I'll help him do his work, which I think gives you a good sense for how I'd actually work."
I sat down with a JS developer and figured out a bug in his tests which was causing him to think that he had a bug in his main code.
This reminds me of all the people that memorize leetcode problems to pass FAANG interviews instead of actually working real problems. Yes, it’s cheating.
The consent is you’re given a random question and let’s see how you do under pressure to solve it. What creativity do you have? What can you remember? How do you interact with the interviewer?
Memorizing the question or the patterns commonly used and being able to regurgitate it out doesn’t make you good. You’re lying and breaking the agreed upon consent. You don’t know what you’re doing, you’re just regurgitating out a string answer instead of creating the object oriented program you lead them to believe you have. This puts real programmers who don’t have time to memorize trivial work at a disadvantage.
Programming interviews need to be based on real world situations. If that’s not possible, memorizing a bag of tricks that aren’t useful or practical in the real world is not an acceptable solution.
(How about you do a paired code review instead? You’d see real code, show team work skills, and demonstrate your knowledge by the questions you ask or bugs you flag as potential problems.)
> You’re lying and breaking the agreed upon consent.
“Consent“ is a mutual agreement. If you haven't represented to the potential employer that you haven't studied the class of common interview problems, you have not broken any “consent”. In fact, given that employer are aware of the existence of numerous platforms that exist to prep candidates by practicing the class of problems, and indeed many use one or more of those platforms as part of their hiring funnel, that you have practiced on them is probably more of the base expectation than that you have not.
I had a similar lucky break when interviewing for my first real job at $FANG. They asked me a question which I happened to have done a research project on. So not only did I give the optimal algorithm I also was able to teach the interviewer some new aspects of the problem. I got the job very easily.
Conversely at my interview for $FANG2 I got unlucky and didn’t do as well. So I didn’t get that job.
I never cheated but after being rejected by clueless recruiters (javascript != java) that only reacted to big company names (no matter the quality of work I did) I decided to scramble my resume and turn projects into paid gigs. Interview went just like the others. I felt like a criminal for a few hours after that though.
The unfairness doesn't derive so much from the act of cheating. It's more that he got the answer ahead of time because of his connection to someone at the company. When people talk about certain inequities in tech demographics I think it's not unreasonable to point to situations like this as part of the problem.
One of my friends cousin immigrated to Canada recently from India.
They both are shady and like to use shortcuts to reach success.
Few years back, she rang me up at 12am in the night. She sent me a link asking me to solve a coding assessment for her. I was naive and idiot. I spent 2 hours on the test and submitted it.
After that, both of them did not contact me for year.
A year later, I came to know from him that her cousin passed that coding assessment and secured a full-time job with top 10 tech company for $140k/yr. She bought a house in one of the most prestigious community in Canada after probation.
On the other hand, I never got a job higher than $50k/yr. I continue to rent and survive.
Both of them came as immigrant few years after me and own houses. I cannot. I blocked both of them. I regret participating in that assessment everyday. It was against my morals and principles.
Never make friends in Canada. They use and through you like a condom.
> Few years back, she rang me up at 12am in the night. She sent me a link asking me to solve a coding assessment for her.
> A year later, I came to know from him that her cousin passed that coding assessment and secured a full-time job with top 10 tech company for $140k/yr. She bought a house in one of the most prestigious community in Canada after probation.
It seems everyone not qualified enough to pass an RFE ends up north. This isn't the first time I hear that story.
you should not blame them for your situation. just be smarter and find a better paying job.
i also found that it's not so important how much you make, but how wise you spend.
but 50k in IT, that is ridiculous, even for a first job. you're definitely not trying hard enough.
This is pretty hilarious. If you spend any time on CS career forums like /r/csMajors or /r/cscareerquestions, you realize that peoples strategy appears to be “grinding leetcode” for hours and hours until they can regurgitate the exact question that they’re asked on the interview. It’s gotten to the point where some people are terrified at the prospect that they won’t get a question that they know already. As if figuring out the question in the interview is just such an impossibility.
It’s quite sad because it reflects an attitude that problem solving is too stressful/challenging, so people will take the route of blind busywork to avoid actually solving problems. Granted leetcode problems are pretty useless and stupid. I don’t fault people for coming up with a stupid solution to a stupid problem.
Something similar happened to my actual job interview: in the preparation I had read a long list of questions and most of them was part of the technical interview. I was able to reply in seconds, just because I already know that.
I was very honest and I told them after the 3rd question.
Luck has played an outsized role in my life. Two notable examples:
1. In 1992 I learned that a colleague of mine was a member of the Magic Castle [1] and offered me a guest pass. I had a long-standing love of magic, and the chance to go to the Castle seemed like a once-in-a-lifetime opportunity. I invited some friends to go with me, and one of those friends asked if she could bring a friend, and of course I said yes. Fast-forward 30 years and that friend-of-a-friend and I just celebrated our 25th wedding anniversary.
2. In early 2000, at the height of the dotcom boom, I sent a resume to an obscure little startup with about 50 employees. They made me an offer, but I turned them down because I decided that it was not worth giving up my secure position at NASA to go chasing a pipe dream. But they wouldn't take no for an answer. They offered me all kinds of additional perks (back then anyone with a CS degree and a pulse could pretty much write their own ticket) and so I decided to go. Four years later that company had an IPO. Their stock symbol was GOOG.
[UPDATE] Two more examples that I just thought of, with a somewhat different dynamic:
3. When I was in high school I attended a football game. I drove myself in my parents' car. At the game, I met my best friend at the time (who has since died from complications resulting from malaria, but that's another story) who had arrived on a motorcycle. After the game we decided to go meet somewhere (I don't recall exactly where). I followed him. At one point he was stopped at a stop sign. I expected him to pull away from the intersection fairly quickly and I didn't want to lose him, so I stepped on the gas. By the time I realized that he wasn't pulling away as I expected it was almost too late to stop. I screeched to a halt (this was before ABS brakes) with my front bumper about a foot away from his rear wheel. If I had reacted even a second later I almost certainly would have hit him, and quite possibly killed him.
4. After college some friends and I went on a tour of Europe. We rented a car in England and picked up two girls so there were five of us in the car along with our backpacks. One of my friends was driving, and I was in the passenger seat. We were going at speed down a non-divided highway when I saw my friend turn his head to say something to one of the girls in the back seat. The car started drifting into oncoming traffic, which in England of course is on the right. We were heading straight for a semi-truck. In a split my brain decided that telling him to look out might be a bad idea because, as an American driver, his reflex reaction would be to turn the wheel to the right instead of left. So I grabbed the wheel myself and turned to the left. My friend of course did not know realize right away why I had done this. He thought I had just gone rogue, looked at me instead of out the window, and gave my hand a karate chop to get me to let go of the wheel. He never saw the truck. To this day I'm not sure I did the right thing. But we didn't hit the truck.
I didn't put my NASA story on the list because I consider my career there to have been largely a failure, but there is a luck story behind that as well: I never actually applied for my NASA job. I got it because I was a grad student and my Ph.D. advisor got offered a job (from one of his Yale buddies) and took me and another one of his students with him. And the only reason I had the advisor that I did was because I had applied to Stanford and MIT and both of them rejected me, so I was stuck at Virginia Tech. And the only reason I went to Virginia Tech instead of Stanford or MIT, both of which had admitted me as an undergrad, was because VT offered me a full scholarship and I have had a life-long aversion to being in debt.
I have no opinion whether or not it's cheating. Feels like a definitional issue more than anything.
I work and interview for one of the FAANG's. I had a candidate tell me just the other day: "Oh, I've done this in another form." We went on, talked about some details that are not a part of the core algorithm but that I think are interesting to suss out things like: "Do they understand concurrency", "Do they understand good API design", etc and then we moved on.
As I was doing the writeup, I scored the person high on a measure that I rarely get a read from in technical interviews. I guess my point: I don't know if it's cheating and in no way shape or form feel judgy towards people who do what the author did. But when I've encountered people disclosing this, I have noted that.
I think you're being unfair to yourself if you're calling this cheating.
Also FWIW, I interviewed with Microsoft at my college, got asked the very same question as the OP and actually solved it the same way. I knew the formula for the sum and the rest just came to me at that moment.
I was flown to Redmond, given series of interviews and an offer in OSG. Even though it was my dream to work on Windows kernel growing up, in the last 4-5 years, I had become a FOSS Linux guy so I turned down their offer, much to the surprise of the recruiter whom I had shared this was a life-long dream, and took an entirely different direction with my career and life.
Worked out nicely. I am sure I'd be very happy in Microsoft but maybe I am happier.
It's just simple luck, not cheating. I had a similar experience, at a Microsoft interview no less, a decade+ ago. I had been playing around with AI Pathfinding algorithms for a game I was working on. The first interviewer tries to toss me a difficult question that involved navigating a complex graph. I'm sure it was supposed to be a multi-stage problem that we work through together. Instead, I walked up to the board and wrote out an A* algo in 45 seconds because I had been writing this F-ing algo over and over, troubleshooting it for days in my game.
The interviewer looked awestruck, and we spent the rest of the time discussing other things. Of course, I got the job.
Holy crap, I wouldn't have thought twice about being lucky enough to roll out a solution I'd happened to have been thinking about for days. I am not seeing an ethics problem here, the guy was just very lucky to get a problem he was intimately familiar with.
As an interviewer I've seen candidates immediately recognize my interview question (let's be honest, with Leetcode unless you invest time to keep crafting new questions, sooner or later it gets leaked).
The interesting part is that you can still get enough signal to tell who understood the solution vs who only memorized it. (e.g. in my question you had to do a pre-processing to transform it into a classical question on leetcode; people who only memorized the solution wouldn't even recognize that and would find the input does not "fit" into the canned solution)
This isn't the sad part. The sad part is that technical interviews cannot be audited externally so they can ratchet up the difficulty if they don't want you. To my knowledge Google and Microsoft don't do that, but I would not be surprised if other companies who are more tolerant of dark patterns have already started.
Second, after reading that blog post, you just know that there are some poor saps out there who have informed their interviewer: "I've already seen this question before." It breaks my heart that they are (likely) punished for their honesty.
If this would have been true, he would have asked about Gauss (it's one of the most famous math tricks in highschool afterall). he didn't ask, op didn't know either. so I would have suspected cheating.
op's answer is constant n, but could have been improved to n/2 on average with a hash table. (but some constant overhead). so it really depends on the size of n.
Preparing is not cheating. You learned and used your knowledge in an appropriate setting. That is the skill set companies are looking for, also the colleague I would like to work with
I wouldn't consider this cheating, I would rather call this preparation. Is looking at question banks before an exam considered cheating? I think this is in the same vein. Interviewers are people too, everyone knows there is a finite, albeit large, pool of questions to ask. If I ever see a candidate that has prepared to the point that he/she can code up the answer to the majority of leetcode style questions, I'd hire them without hesitation.
Sample size of 1, but it seems like questions used to be easier. I remember seeing this question on Leetcode, and this formula was covered in my high school math class and so I solved it within a few minutes. By contrast, I’ve had a couple of online assessments with Microsoft this past year and the problems were a lot harder (design a simple word processor with copy/paste, undo, etc, and the other was something about optimal scheduling of some finite resource)
I don't think this is cheating.. if someone asks me how to design a distributed join and I answer because I worked on distributed joins directly, is that cheating?
This reminds me of a guy who, on the contrary, probably thinks I wronged him during an interview. He couldn't solve my relatively simple programming question and then remarked, sounding rather unhappy, that this question "wasn't on leetcode", and so he wasn't prepared for it ;)
This is what happens when companies use riddles that have nothing to do with the job you’ll do and do not remotely relate to the skills that will be required on the ground.
On one of my programming courses, while studying for midterms,
I was reading a alternate textbook which covers similar material to our course, and I noticed that question 1 and 3 from the textbook had already been used on our homework.
So I was like, excellent, question 2 is a good practice question for studying. I even called my roommates over and got them to study it too.
Turns out it was the bonus question on the exam.
I was surprised, but my roommates were pretty happy with me.
This happened to me with multiple questions when I interviewed for a Facebook internship back in 2010.
I didn't really understand that this was bad (if I wasn't supposed to memorize the answers to all the questions, why were they all online and completely unrelated to the skills needed to be a developer?)
The interviewer got upset and asked me a poorly worded question which I think he made up on the spot.
Recruitment agents are always pumping failed interviewees for the questions they were asked. They then make sure their next candidates are better prepared with this knowledge.
This guy really shouldn't feel so bad. It's Microsoft's fault for not rotating the questions better. That, or they did rotate the questions, and it really was absolute pot luck.
/*
Not sure if this is correct,
but there should be a solution along these lines
will explode if the array contains values outside of 1...n
also, invalidates the array
*/
int v = values[0];
for(;;){
if(v == values[v])return v;
int t = v;
v = values[v];
values[v] = t;
}
/*
I used to be able to do this without a compiler
*/
for(;;){
int i = values[0];
if(i == values[i])return i;
values[i] ^= values[0];
values[0] ^= values[i];
values[i] ^= values[0];
}
/*
full test code, does java really not have Arrays.shuffle?
*/
public static void main(String...args){
final int result;
Integer[] values = new Integer[12];
for(int i = 1; i < values.length; i++){
values[i] = i;
}
final int dupe = values[0] = 1 + new Random().nextInt(values.length - 1);
final var list = Arrays.asList(values);
Collections.shuffle(list);
System.err.println(list);
for(;;){
int i = values[0];
if(i == values[i]){
result = i;
break;
}
values[i] ^= values[0];
values[0] ^= values[i];
values[i] ^= values[0];
}
System.err.println(dupe + " " + result);
}
It's cheating if and only if he couldn't perform after he was hired. If the interview was his "peak" contribution then yes, one could consider it cheating. However, as long as he performed competitively subsequently, it's just good luck and good preparation.
This has happened to me a couple times and I tell the interviewer that I already know the answer and to move on to the next question. It’s good because you get to see more questions and makes the interview more interesting and at the same time the employer sees that you like a good challenge.
Got a chuckle out of the author thinking this was some kind of cardinal sin.
The only person "at fault" here is his friend for telling him what interview question he received and I'd expect companies know this happens, which is one of the benefits of having further interview stages in the first place.
I would say the only person “at fault” is the interviewer for using such an awful question. This is precisely the kind of question that gives programming puzzle interviews a bad name. If you’ve heard it before, it’s trivial and proves nothing. If you haven’t, you have to have a clever a-ha moment in order to do anything but brute-force it. “Have you heard this one story about Karl Gauss as a child” is a really terrible hiring criterion.
So,based on reading the article; you'll see that to arrive at the solution the writer:
* Communicated with a colleague (communications/interpersonal networking)
* Thought hard about it (applying previous knowledge and experience)
* Looked up and found relevant information (knowing where to look)
* Combined the above to come to a solution. (and had the skill to put it together)
By coincidence the practice practice question was also the one that was asked at the interview. If the interviewers had asked a different question, similar steps would have needed to be applied[1].
The question itself was an obvious practice question. There are many decent answers to the problem. What they were looking for were the knowledge, skills and experience that needed to be applied in the process of solving the problem. The point was to see if the candidate had those abilities.
I'm fine with using a practice question for this. A real world problem often involves a lot of real world noise, which makes it impossible to efficiently resolve within the constraints of a 60 minute chat.
I am -however- fully open to an argument that perhaps some form of Goodhart's Law ("When a measure becomes a target, it ceases to be a good measure") may have struck again.
[1] Perhaps not the exact same set of skills, given the constraints of the interview setting. One COULD argue that the interviewers accidentally picked up on more than they were looking for.
Unless I'm misreading, the question as stated in the blog post never says there is only one duplicate (there might be many!), so in that sense I think his answer may be wrong. A more robust solution is just to have an array of n counters and just count how many times each item appears.
What I take from this is that luck takes a big part of happy stories in life.
Nobody is infinitely lucky and nobody is infinitely unlucky. To be successful means most of the time to be prepared when the luck comes and be ready to take advantage of the opportunity.
> it definitely didn’t work the way Microsoft had intended
I think this is a poor conclusion. This person has no clue what Microsoft intended. And I think preparation and knowing a person who works at Microsoft may have been what Microsoft intended.
This is basically no different than a take home assignment, and not cheating.
I always do better thinking about problems in my own space, without the quiz show drama of someone staring at you and "taking notes".
I had the same experience in my Cambridge University entrance interview. The kid before me came out and said the professor asked xx and she ended up asking me the same question and I had a chance to look up the answer.
Strange, I read the problem statement, paused, and worked out the answer in 30 seconds. Maybe I have just done enough of these kinds of challenge problems before.
All totally irrelevant to the actual work of software engineering.
I think the author should not feel guilty for this and frankly he is overthinking about it a bit. Isn’t it true that most of the things do depend upon little bit of luck? Being born itself is sheer luck!
On the other hand that first question was just a filter. He managed to do well in the on site interview. So even if he had an unfair advantage to get the foot in the door, he managed to back it up
Many interviewers would expect the author to own ip to having seen the exact question before. I certainly would prefer to work with people who would say so.
"Leetcode" algo questions are supposed to test how you think and programming skills but for most people it just tests if they've seen the question before or not.
I don’t agree that this would be considered “cheating”. I think though that this is another reason why interviews with coding assessments are quite useless.
The author spent days thinking about it, whereas sorting is the immediate obvious answer. Developer time is massively more valuable than computer time by a factor of 1000
And the clever approach only works on data that is perfect, and that’s extremely rare in the real world
[1] https://www.youtube.com/watch?v=_Qd3erAPI9w