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.
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.
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.
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?
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.
Yes people "cheat" their way to success. I hate it, but they do and we support it. From just a position of basic human integrity (forget about the law), Apple "cheated" by implementing the graphical user interface from Xerox Parc without adequate compensation. Then Microsoft "cheated" by implementing Apple's GUI as Windows. Then came the lawsuits. This happens again and again.
I have experienced this personally - the USDA RUS broadband program had written rules where an ISP had to work with their regional office and not walk their application through the front door in Washington DC. Yet being the first to apply through the regional office resulted in significant delays over our competitor walking their application into USDA headquarters against procedure. They got the $20 million. We did not. Any attempt to object or litigate would only hurt us further.
> If the fraud in your story hadn't been discovered, would that have been success?
I do not consider the author talking with Eli to be fraud. There was no obligation of disclosure. For all we know the reason why Microsoft repeated this question with so many applicants may have been deliberate to see how many applicants would actually get the solution by asking around. After all, isn't that how all of us code?
He didn't call Eli randomly, he called to research an interview. That's putting the work in. That the question was the same might have been serendipitous (especially if the question was one of many possibilities). And he didn't just call and get the question, he then put in the effort to research an answer.
[1] https://www.youtube.com/watch?v=_Qd3erAPI9w