I cheated on my Microsoft interview (2019)
facet.net
facet.net
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.
My review from management actually got much better once I stopped knocking myself out working too hard and instead worked just enough.
That was a pivotal moment for me. That and also learning how to manage your manager.
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.
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.
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.
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.
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?
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?
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?
If only :)
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.
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
we're talking about Microsoft here, embrace, extend, extinguish, and all manner of other perfidy.I'd say he fit right, apart from his conscience.
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
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.
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.
On the contrary, when I was an interviewer, we had a policy of giving a detailed technical reasoning for the decision within 3 days.
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”.
- 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.
[0] https://crypto.stackexchange.com/questions/39186/what-does-i...
[1] https://stackoverflow.com/questions/37828955/what-is-the-dif...
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
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)
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.
j = random(0,51)
j = random(i,51)
?[1] https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#T...
I now have a bunch of theory to read through that I hadn't encountered before.
And I also have some more to think about how I assess people's skills too.
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.
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.
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.
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.
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.
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.
At least it was for a job I probably wouldn’t have taken.
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.
My Google and Facebook interviews went much better in comparison. None of their questions were top ten LeetCode ones.
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.
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]
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.
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.
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.
Didn't you have anything more interesting/relevant to talk about?
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.
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.
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.
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.
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"
Sexual innuendos from peers at the bar are one thing, sexual innuendos from interviewer are another
TBH I'd just have found it contrived and boring. I wouldn't be excited to have colleagues who couldn't just talk about normal stuff at lunch.
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?
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'.
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.”
No, we like to talk about normal stuff.
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"!!
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.
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.
An interviewer is most certainly not a peer.
> with puzzles or tricky problems
Seeing a a middle school question as "tricky" it's a bit worrying.
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.
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.
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.
That is unexpected!
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.
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.
- 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?
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.
It's very counter intuitive, and very easy to solve.
d=sqrt(h(2R+h)) km/m (see https://en.wikipedia.org/wiki/Horizon#Approximation )
s=R*arccos(R/(R+h)) (see https://en.wikipedia.org/wiki/Horizon#Arc_distance )
sqrt(h(2R+h))-R*arccos(R/(R+h))-delta = 0
6 foots is about 2 meters.
sqrt(h(2*6371000+h))-6371000*arccos(6371000/(6371000+h))-2 = 0
h=306m
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.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Fermi_problem
[2] https://blog.codinghorror.com/the-hardest-interview-puzzle-q...
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.
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?
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.
The question reminds me of "how many groves are there on a vinyl record?"
If I ask you how many sugars you want in your coffee and you answer with an equation I will assume you're 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.
I suspect the answer to this is "not enough information", which, I suppose, hints at an applicants requirements gathering thought process?
If you're a poor kid who's never been skiing, you'll have a harder time conceptualizing the answer.
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.
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.
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?
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?
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 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.
So please, more of this! Let the kids know that we don't live in a meritocracy!
Otherwise, the good ones will become discouraged and we will all lose.
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.
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.
I still don’t think tech is a meritocracy and will continue to know that. Do not buy into this delusion.
Just because you made it - meritocracy it does not make.
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.
Why are you so sure of this?
It is naive to think every work environment is like this.
> 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.
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?
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?
Can you tell me what the correct Konami code is for success here?
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"
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'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".
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.
You are so correct (at proper timestamp): https://youtu.be/3LopI4YeC4I?t=211
> 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.
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.
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 don't have a problem with people marketing themselves on LinkedIn - it that not the entire purpose of the site?
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.
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.
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? ;-)
You mean ask them the same question that they asked? Of course they'll be able to answer it. What does that prove?
And I mean a different question.
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.
Also, OP should have included (2019) in the title. It's kind of an old piece.
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 story resonated with me.
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.
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'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.
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.
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
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.
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?
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...
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.
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.
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.
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 = Σ(n-i+1) = n² - Σi + n
2Σi = n² + n
... but the xor solution is more elegant.
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).
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.
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'm not sure modulus-addition would be correct.
Don’t pretend they are an authority. They’re a bunch of idiots making it up as they go along like the rest of us.
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.")
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.
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.
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).
Where S is the sum of the array achieved through iterative addition with every addition mod N and N > 2n.
Edit: The simplest solution is probably just doing (n/2)*(n+1) (assuming n is even; move the division for n odd).
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.
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.
There is some discussions and examples of such problems at https://arxiv.org/pdf/1110.1556.pdf and http://3038.org/press/shen.pdf.
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.
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.
• n if n mod 4 = 0,
• 1 if n mod 4 = 1,
• n + 1 if n mod 4 = 2,
• 0 if n mod 4 = 3.
Or alternatively:
• s(4n) = 4n
• s(4n + 1) = 1
• s(4n + 2) = 4n + 3
• s(4n + 3) = 0
Proof by induction:
• s(4n + 1) = s(4n) ⊕ (4n + 1) = 4n ⊕ (4n + 1) = 1
• s(4n + 2) = s(4n + 1) ⊕ (4n + 2) = 1 ⊕ (4n + 2) = 4n + 3
• s(4n + 3) = s(4n + 2) ⊕ (4n + 3) = (4n + 3) ⊕ (4n + 3) = 0
• s(4n + 4) = s(4n + 3) ⊕ (4n + 4) = 0 ⊕ (4n + 4) = 4n + 4
I mean they might. Its a very famous formula, with a famous story attached, which is often covered in high school level math.
Regardless its a stupid question.
- 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).
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.
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.
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?
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.
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.
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.
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.
That they can get away with such a bad measurement though just shows that there’s a large gap between the costs per and profits per developer.
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.
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.
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.
"Write a function that, when given an array of length n + 1 containing integers 1 through n, find the duplicate integer in an array.
You can use this equation: sum(1 to n) = n(n + 1) / 2"
Basically, if your solution is made trivial by someone knowing a generic formula or equation, just give it to them.
Not giving them the formula doesn't give you any additional information.
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.
They are not, and no company cares about fairness
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)
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.
Then the first hit on google was a paper from 2018 about how to hire based on handwriting.
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 assure you that I’m not a monster and I would really appreciate it if you’d assume positive intent in such replies.
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.
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.
In most of the world a "no thanks I pass" will suffice
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.
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.
Sounds like testgorrilla. I swear they have a poor markov-chain based AI generating the questions.
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.
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 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.
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.
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.
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.
Did you ask the candidate about the copied code? To me that's an honesty issue.
https://www.americanscientist.org/article/gausss-day-of-reck...
http://bit-player.org/wp-content/extras/gaussfiles/gauss-sni...
would have helped as well.
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 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.
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.
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.
> seem to give enough momentum to make mediocre coding performance a non-issue.
These two statements contradict each other.
If you want a company to have to take on and train engineers, well, that ship sailed in the 90s.
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.
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.)
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.
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.
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.
All good.
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.
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.
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 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.
Also, your way is O(n) memory when O(1) would be enough for the original question.
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.
Isn't this the very premise of LeetCode - do a bunch of LeetCode questions and you're likely to have a similar one in the interview?
Ethics are foundational to engineering. Jettisoning them is a sign of a discipline in decline.
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.
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.
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.
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.
[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
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.
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.
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.
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.
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.
I got the job.
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.)
“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.
This is utilizing your network and preparing for potential questions.
If Microsoft is risking to ask the exact same question to someone, it's their problem.
Conversely at my interview for $FANG2 I got unlucky and didn’t do as well. So I didn’t get that job.
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.
> 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.
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.
It seems that they appreciate that.
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.
[1] https://en.wikipedia.org/wiki/Magic_Castle
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.
Also, the girls at VT were better-looking. :-)
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.
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.
The interviewer looked awestruck, and we spent the rest of the time discussing other things. Of course, I got the job.
It's just plain luck. Enjoy it when it happens.
BTW you probably earned extra points for not naming the Gaussian sum you used, because that's pretentious.
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)
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.
Is it so bad if you’re able to implement it in real time and all through the trade offs?
If they were truly testing for engineering skills, the interview would mirror real day to day world more.
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.
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 ;)
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.
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.
I told him I had already seen the question before and knew the answer. He said that’s fine and just had me show him the solution.
We used the extra time to just chat about my interests and side projects and I got the offer anyway.
So it doesn’t matter, you didn’t “cheat” any more than I did.
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 wasn't joking though - I haven't been able to work for years and have no real hope of piecing myself back together.
(Mushrooms help, though they're seasonal - and there's no damned way the government's ever going to legalise them.)
/*
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);
}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.
* 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.
I do believe it is only one.
Then in the actual interviews they did ok as well.
Sounds like the system worked the way it was supposed to.
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.
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.
All totally irrelevant to the actual work of software engineering.
Whiteboard leetcode crap is simply a test for "have you heard the trick for this one or not?"
It’s also a shitty and very (old school) Microsoftian interview question.
Every comment below OP's post
Real world requirements usually contain inaccurate assumptions. He spent days to find a terrible answer, when the obvious solution is much better
Start with what works and then optimize
Sophomoric is exactly the word here, and it’s no surprise that the story is about Microsoft
In the lack of additional constraint, sorting seems massively overkill.
Not sure why you are saying that sorting is simpler than the sum trick.
And the clever approach only works on data that is perfect, and that’s extremely rare in the real world
This is a hypersophomoric question