Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT

'How I Cheated On My Microsoft Job Interview' (facetdev.com) 263

Robert Sweeney spent 10 years working as a software engineer at Microsoft and Netflix, before becoming founder and CEO of the software development agency Facet. This week he blogged about how he cheated on his 2004 interview for a job at Microsoft.

It was his first job interview ever, when he was still a college senior majoring in computer science, and a Microsoft recruiter had invited him to an interview at an on-campus career fair: I immediately called my good friend Eli who had just started a new job at Microsoft. I asked him what the on campus interviews were like and how I should prepare for them. He explained that they would ask a random programming question that I would need to solve on a sheet of paper. If you did well, then they would fly you out for a full day of interviews at the Microsoft headquarters in Redmond, Washington. He had been asked to write a function that, when given an array of length n + 1 containing integers 1 through n, find the duplicate integer in an array. I wasn't sure how to prepare for answering a "random programming question", so I decided to just use the question Eli had been asked as practice and hope for the best...

Most of the interview is a blur, but I remember the interviewer being nice and I remember the programming question he asked me... I couldn't believe it. He asked me the exact same question as Eli. Should I tell him? I hesitated for a moment, pretending to be thinking about how to solve the problem. In reality I was having an intense internal debate on the ethics of interviewing. He didn't ask me if I had heard the question before, he just asked me to solve it. So I decided to just answer the question... 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... A few days later I received an invite to fly out to the Microsoft main offices. I interviewed with two teams over a period of 6+ hours. I didn't get asked any questions I had heard before this time, but I did my best... Sure enough, that next week I had a job offer from Microsoft from both teams... Within a couple of years of graduating from college, I had shipped software that was being used by nearly a billion people...

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. I also think my experience is a great example of one of the many reasons why the coding problems we use in developer interviews are so problematic: on the spot coding is just not a good way to judge technical ability.

Stack Overflow's CEO founder Joel Spolsky actually wrote some of Microsoft's internal programmer-testing guidelines when he worked there in the mid-1990s, and he later publicized them in a 2006 blog post which he says was later adopted by other tech companies, including Google.

He has since said that recruiting for IT is broken, adding "I think that I'm responsible."

Microsoft has since changed its interviewing practices.
This discussion has been archived. No new comments can be posted.

'How I Cheated On My Microsoft Job Interview'

Comments Filter:
  • by itomato ( 91092 ) on Saturday May 25, 2019 @12:45PM (#58653184)
    This is just another "life hack". Carry on.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Amateurs call it cheating.
      Professionals call it networking.

    • Re:GP didnt cheat (Score:4, Insightful)

      by ShanghaiBill ( 739463 ) on Saturday May 25, 2019 @01:18PM (#58653338)

      It doesn't sound like cheating to me either. Just proper preparation. There are sets of "interview problems" available in books and online, and if you practice them, at least one is likely to be close to a question you are actually asked.

      But you can still get "honesty points" for admitting that you have seen the problem before. The interviewer may be impressed by your integrity.

      A really slick interview hack is if you get a hard problem that you have no idea how to solve, you can say "Sorry, but I have seen this identical problem before. I don't want to take advantage of that, so can you give me another instead?" Then you get the points for "integrity" while also avoiding the hard problem.

      The obvious approaches to finding a duplicate element in an array are:
      1. Sort the array, and then scan for duplicates.
      2. Scan the array once, and use a bit array offset to identify dupes.

      For #1, time=O(n*log(n)), space=O(log(n))
      For #2, time=O(n), space=O(n)

      Is there another way?

      • Re:GP didnt cheat (Score:4, Interesting)

        by dwillmore ( 673044 ) on Saturday May 25, 2019 @01:26PM (#58653378)
        Scan through the array. Keep a counter and at each index, add in the contents of the array, but subtract the index. At the end, the conunter will have your duplicated value in it. It's important that the array indexes start at zero, otherwise you'll have to subtract N from it as well.
        • Does not cover edge cases as in there are multiple duplicated values, or the whole array only has the same value (yes, edge cases where not asked, but we call that "robust" or "robustness" in SE)

      • Re: GP didnt cheat (Score:3, Interesting)

        by mapkinase ( 958129 )

        sum - n(n+1)/2

        • sum - n(n+1)/2

          I should have RTFA. I also should have read the summary more carefully. I was thinking it was an array of random integers, not a list of exactly 1 to n, with only one duplicate.

          This guy's solution was very insightful. I don't think I would have thought of it.

          • Apparently, Microsoft hired a bunch of dweebs who could quickly think of this one weird trick for a situation that would never happen in the real world... But for decades these same people couldn't figure out how to do things like support multiple styles of line endings in a simple text edit control.

          • by zilym ( 3470 )

            While that solution is elegant to write, it still isn't the fastest executing solution. Getting the the sum requires iterating through the entire array and reading each element, plus doing an ADD operation. A faster way for finding the duplicated element would be to do a binary search.

            Since you know what value SHOULD be stored at any given point in the array with no duplicates up to that point (array[n] == n + 1), you can easily tell which side of your inspection point contains the duplicated element. By sp

            • by Phaid ( 938 )

              That assumes the array is sorted. The problem doesn't state that.

            • You assume the array is sorted.
              Which it is not.

              The two duplicates are at random positions. And the numbers in the array are "arbitrarily distributed". There is no way not scanning the whole array.

        • by v1 ( 525388 )

          I love problems that have elegant solutions! The knee-jerk answer is "loop through the array, looping each time through the remainder of the array, looking for the duplicate", but of course that's not only O(n^2), but is a lot of comparisons, so not only doesn't it scale well, but it's an expensive way to go about n^2 anyway.

          It wasn't until I thought about it for a second that I realized that the entire content of the array (excluding the duplicate) was known, and that made me start thinking of how I could

        • Go through the array and do a modulus function. If any two integers in the array result in mod=0, you have a duplicate.
          • Not true; all of the even numbers will have a mod=0 when tested with two. There are a large number of other examples, but one is sufficient.
      • 1. Sort the array, and then scan for duplicates.

        The problem as stated does not require that the array be sorted, order of the data is neither implicit nor explicit in this problem. If the arrays are in memory or can be read sequentially from a data source, then the duplicate can be found by whatever method, saving a chunk of time by not sorting. Of course, sorting the array is one way to sample each element and do comparisons thereby finding the duplicate, but the statement "sort AND THEN scan" seems redundant, double the time and effort.

      • by jevvim ( 826181 )
        if the algorithm can destroy the input array:

        while ( A[A[N+1]] != 0 ) // valid data set is 1..N

        {

        t = A{N+1];

        A[N+1} = A[t];

        A[t] = 0;

        }

        // on completion: A[N+1] is the duplicate.

      • For #1, time=O(n*log(n)), space=O(log(n))
        Space is O(n).

        Is there another way?
        Yes, many ... you could use a hashtable e.g.

      • Is there another way?

        $integers = array(1, 15, 9, 7, 1, 1000000); // they don't have to be sequential or sorted
        $tmp = array();
        foreach ($integers as $integer) {
        if (isset($tmp[$integer])) { // have I seen this one before?
        echo $integer;
        break;
        }
        $tmp[$integer] = 'junk';
        }

    • by raymorris ( 2726007 ) on Saturday May 25, 2019 @02:07PM (#58653636) Journal

      Him getting the one exact question he had prepared for reminds me of a lucky thing that happened to me in an interview.

      Interviewer: Which Linux distros are you most familiar with?

      Me: I use Redhat / Centos for almost everything.

      Interviewer (frowning): We use Debian. Do you have experience with Debian?

      Me: Are you on the Debian security mailing list?

      Interviewer: Yes ... ?

      Me: Can you pull up the Debian announcement from this morning real quick?

      Debian security alert email: Ray Morris discovered (a big security issue in Debian)

      He had no more questions about my Debian experience after that. :)

      • by antdude ( 79039 )

        But did you get the job? :P

        • Actually I was surprised I didn't get the job. I always kinda wondered why. The limited feedback I got in that time period was that I was applying for lower-level jobs than I should have. Hiring managers thought I'd either demand too high of a salary or less as soon as a better offer came along.

          The phrase "imposter syndrome" came up here on Slashdot earlier today. I think I have a bit of that.

          • That should be "or leave as soon as a better offer came along".

            That would be a reasonable concern. My salary has increased 6X over the last few years; I keep getting significantly better offers.

          • I've found that most smart people exhibit some form of imposter syndrome.

            Dumb people just think they are freaking great.
    • This is just another "life hack". Carry on.

      And that was moderated as "insightful"? Really, Slashdot.

      My approach to the discussion was quite obvious. I looked for "imagination" or "creativity" and found no mention of either word anywhere in the discussion. Perhaps that was the only programming problem they used in those years? (I've read at least one book on the Microsoft interviews and they had other questions later on...)

      Actually the discussion should have considered either term, but in the negative, as in Microsoft interviewers lack imagination or

  • Get Over It (Score:5, Insightful)

    by mykepredko ( 40154 ) on Saturday May 25, 2019 @12:45PM (#58653186) Homepage

    Honestly, this is a case where the Sweeney did the research on the Microsoft interview process and was properly prepared for it. If he worked there a few years, went on to NetFlix and is now CEO of his own company, then it could be argued that Microsoft got a good hire out of their process.

    Nice O(n) algorithm to solve the problem - I'll have to remember it.

    • by Cederic ( 9623 )

      What worries me is that it took him a few days to come up with that.

      Took me less than two minutes, and I stopped midway to explore a less optimal but perfectly functional way of doing it that actually allows capabilities the algorithm lacks.

      I mean, shit, this isn't exactly hard. Didn't everybody learn the n(n+1)/2 algorithm when they were 13?

    • by ranton ( 36917 )

      What he should also get over is any guilt that his career is built on a lucky moment. Most successful people with any level of self-awareness understand the lucky breaks which led to their success. Hard work only gets you so far. Most of these people made their own luck to some extent, but pure random chance nearly always plays a large part as well.

      I had middling success in my career until I happened to join a rapidly growing company where I quickly climbed the ranks from senior developer to VP in just a fe

  • Ethics (Score:5, Insightful)

    by kackle ( 910159 ) on Saturday May 25, 2019 @12:46PM (#58653188)
    In this day and age, I'm glad he had an ethical crisis.
  • Basically, he's describing his feelings as impostor syndrome [wikipedia.org].
  • You got a job and it seems you were pretty good at it too. Don't do the "my entire career is built on one amazing stroke of luck" thing, it's wrong. You had a stroke of luck at the start, but seeing how you got an offer from both teams, and kept the job for a decade, you obviously were good enough.

    Maybe you would have passed that first test too without the preparation, who can tell. But even if you hadn't, would that have meant that your future wasn't in software development?

    • by Herkum01 ( 592704 ) on Saturday May 25, 2019 @01:09PM (#58653298)

      I think he is pointing out, the weakness of recruiting. He got lucky to get a question he had time to think about and give an appropriate answer. Depending upon whether you have encountered a problem previously, most people cannot come up with a good solution at the snap of their fingers.

      I also think that this is a serious problem, people want good answer immediately, like everyone has the same experiences as them and should be able to give them the same answer or process. I like to take my time and understand the problem I am trying to address and usually the first solution I come up with works, but it is not the best, but gets me along the lines towards that better answer.

      If this were not true, why do this big companies keep shoveling S**T out the door so often? Management is part of the problem, but so is the whole hiring process. We don't really know how to ID good developers any more than we know to whether someone is going to be a good basketball player or football star.

      • by AmiMoJo ( 196126 )

        In my experience most companies don't care about the best solution or the fastest solution, they just want something that works. So what they really care about is that you can solve problems quickly, even if the solution is not great.

        In this case I expect many people would try to iterate over the array repeatedly. It's not the fastest but it works, and the performance problems belong to someone else who comes along later.

  • He did his research on the interview process by asking somebody who went through it. He then prepared for it as best he could. It’s no different than his learning that a potential employer asks “tell us about a time you...” questions about customer service methods, workplace interactions, etc, and then preparing answers to those questions instead.

    If anything, what he did was highlight the lazy stupidity that is demonstrated in the hiring practices of many companies these days.

  • Is it OK to respond to a random programming question that you'd post it to Stack Overflow and see what is the best response?

    Or is that answer a bit too "management" for a coding job.

  • by Anonymous Coward

    This is the question the author had to agonize over for days? Study up on the problem?

    It's kinda sad that he couldn't think of 3 or 4 different solutions within minutes of hearing the question, all of which have different complexity (both big-O and terseness of the solution). I'd have asked questions like "Is the complexity an issue? Would you favor a solution that uses available libraries or do you prefer directly coded function? Is there any optimization you want (time/space tradeoffs). Would a clever use

  • Congrats dude, you cheated on an programming interview question that any competent programmer would know, even one fresh out of college.
    • Congrats dude, you cheated on an programming interview question that any competent programmer would know, even one fresh out of college.

      There is a trick to this question, that is only applicable to this particular question. It's of no practical use whatsoever. Many competent programmers don't know that trick.

      Finding duplicates in an array, on the other hand, is useful. I'd just create a counted set and pick the elements with count ⥠2.

    • First of all: he did not cheat.

      I basically only get interview questions where I know the answer because:
      a) I saw the problem somewhere and have a half memorized answer how to solve it
      b) solved the problem myself long ago
      c) it is a silly question, everyone should be able to answer. However I ask back after silly questions when the interview is over and I got several times: you were the only one answering correctly!

      Secondly:
      Half the answers here on /. are either wrong, or the explanation is wrong or the O cal

  • by quax ( 19371 ) on Saturday May 25, 2019 @01:24PM (#58653362)

    The way the condition is given

    "an array of length n + 1 containing integers 1 through n"

    The array contains all integers in the interval [1,n] plus one duplicate, so you can write the sum over all its elements as the n-th partial sum plus the duplicate integer d:

    sum(1+2+..+d+....+n) + d

    (For illustration I chose d not to be 1,2, or n)

    So all you have to do to find the duplicate integer, is to sum up over all integers in your n+1 long array and subtract the n-th partial sum from it. That yields d.

    (I guess I could have been working at MS as it took me just a moment to come up with this answer, but yikes, than I would have had to work for MS. A company I disdained for almost as long as I have been working with computers).

    • by quax ( 19371 )

      Then again, I still manage to misspell "then" as "than".
       

    • Another similar solution is to use the fact that the sum of the first n integers is n(n+1)/2 . So you can take the whole sum and subtract off n(n+1)/2 from the total. Here's a fun problem: Suppose that the you have n+1 integers and you don't have any guarantee that they are from 1 to n, just some set of n integers, and there's a single duplicate, can you still find a linear time algorithm to find the duplicate? (The answer is yes.)
      • Another similar solution is to use the fact that the sum of the first n integers is n(n+1)/2 . So you can take the whole sum and subtract off n(n+1)/2 from the total.

        Here's a fun problem: Suppose that the you have n+1 integers and you don't have any guarantee that they are from 1 to n, just some set of n integers, and there's a single duplicate, can you still find a linear time algorithm to find the duplicate? (The answer is yes.)

        A hash table is what first comes to mind.

        • A hash table is what first comes to mind.

          Hash tables are not linear. The hashing is linear, but handling collisions is log(n), so you end up with O(n*log(n)).

          A fast hash for integers is to make the table size BIG_PRIME and then the hash function is just (k % BIG_PRIME). But you still need to handle collisions.

          • A hash table is what first comes to mind.

            Hash tables are not linear. The hashing is linear, but handling collisions is log(n)

            This is wrong. A decent hash table implementation has average case O(1) for insert, delete and search. Individual operations may be slower, but the amortized time is still constant. To be precise, if the hash function approximates a uniformly distributed random variable (actually a pretty reasonable assumption; we have good hash functions), and the table is resized whenever the load factor exceeds a fixed c Also, for the stated problem you know the number of elements to be inserted, so it is possible to

        • A hash table is what first comes to mind.

          You, I would hire. The summing approach is clever but it's also idiotic as it will only work for this one specific contrived problem. It can't be extended to more general cases, while a hash table approach can.

          • well yeah, expect that practically speaking it's an idiotic problem is the first place. the only reason for the problem, is to test whether the applicant knows or can figure out a trick as other posters have shown.

            finding the index of the repeated entry, now that might be something of some practical utility in some cases, but just finding the value? completely useless apart from being a veiled IQ test (which may or may not be useful; i don't know or care).

      • by quax ( 19371 )

        Yep, if you know the formula for the partial sum this is much more efficient.

      • by henni16 ( 586412 )

        If you're talking int32 and have a GB of memory to waste, you could simply walk over the array and use each value as an index in one or two bit sets and flip the bit at that position until you encounter an already flipped bit.
        If you want to be fancy, you can do another walk prior to that to collect the min and max values in the array and use those to (down)size the bit set(s) to the range of values you're actually dealing with.

    • findRepeatedInteger(int arraySize, int* array) { // I know that "int" should be something like uint32_t but for clarity...

      int i;
      int actualArraySum;
      int arraySum = (arraySize * (arraySize + 1)) / 2; // Get the sum of the numbers from 1 to arraySize;

      for (i = actualArraySum = 0; arraySize > i; ++i) {
      actualArraySum += array[i];
      }

      return actualArraySum - arraySum;

      }

      • This should be correct. I forgot that I should be looking for the sum of arraySize - 1 and not the full array.

        findRepeatedInteger(int arraySize, int* array) { // I know that "int" should be something like uint32_t but for clarity...

        int i;
        int actualArraySum;
        int arraySum = (arraySize * (arraySize - 1)) / 2; // Get the sum of the numbers from 1 to arraySize - 1;

        for (i = actualArraySum = 0; arraySize > i; ++i) {
        actualArray

        • You failed. if arraySize >= 40,000 or so, the addition will overflow, leading to undefined behaviour. Easily fixed by using unsigned int.
          • If "int" is a signed 32 bit number, shouldn't the array size where problems start be 65,535?

            I'm calculating this by knowing the square root of 2^32 is 2^16 and if I multiply 2^16 and (2^16 + 1) I'll end up with a negative 32bit value as the result will be greater than the maximum positive number is (2^31 - 1) or 2,147,483,647.

            If I use unsigned 32 bit numbers, I can theoretically go as high as 91,681 but there is the problem that 91,681 x 91,682 is 8,405,497,442 and is greater than 2^32 (4,294,967,296). In

    • While the answer is correct, the guy performing the interview, aka the interviewer, would most likely not grasp it and most likely would not have it on his list of "correct answers".

    • This isn't so much a program problem as a puzzle. If, under pressure, you happen to see the trick, great. If not, you're screwed.

      Better would be a problem that requires more ordinary slogging, to model some data, use some data structures, etc.

    • by Jamu ( 852752 )
      Create a boolean array of length n + 1.
      Initialize all to false.
      Tick off all the integers you find in the integer array, unless the value is already true.
      If it is already true: You have the duplicate.
  • . . . Hmmmmm. . . . . ". . when he was still a college senior majoring in computer science. ."

    Well, that line says it all (especially if he was from an Ivy League school.

    I recall, that while an on-and-off contractor at M$, I once emailed them my cover letter stating I was undecided as to whether apply to Micro$oft or become a crack ho --- the only time I ever received a response from them, and was never able to score any interviews during my gigs there, but then I am not a grad of an Ivy League insti
  • by Anonymous Coward

    CSC wanted to give me an aptitude test on my suitability to be a programmer. This was after 20+ years of writing software.
    I deliberately failed it and told the guy running it.

    I said, "This test is an insult to me and my profession."
    I then pulled out two papers I'd presented on specific development techniques.
    "This is what I can do."
    Then I walked out.
    A week later I got a letter telling me that I wasn't suitable to work as a programmer.
    Numpties.

  • "Sir, I do not know off hand the best solution for that problem. But let me show you a great way of when given an array of length n + 1 containing integers 1 through n, finding the duplicate integer in an array."

  • by jeff4747 ( 256583 ) on Saturday May 25, 2019 @02:12PM (#58653672)

    From the interviewing side, it doesn't really matter if you got the answer right, or could even complete it. Especially as an entry-level hire. Sure, it's a plus, but it's not a giant one.

    What I'm looking for when I ask these kinds of questions is how do you approach the problem, what is your thought process while solving it, how do you respond to any wrenches I throw into it, and do you understand a more elegant solution when I lead you to it or provide it. (It's also a spot-check on do you understand the basics of the language, but that's a secondary use of these questions)

    The fact that you could or could not solve it isn't all that important - we can all find google and it's extremely unlikely that you will actually face these kinds of trick problems in the real world.

    In the real world, you'd do something inefficient but simple-to-read and only switch to an elegant and fast solution if the profiler show it to be a bottleneck. Saving 100ms is huge, but if you only do it once in the lifetime of a long-running process, it isn't worth your time or the time of everyone after you who has to take 5 minutes to understand the elegant solution.

    So the questions are about you and the way you think, not whether or not you get the right answer.

    TL:DR - TFAuthor wasn't being asked what they thought they were, so they did not cheat.

    • Taking some time to research an optimized solution beyond what a basic coder would have typically written probably added points. It is one thing to be able to do something, it is another to provide an optimal way of doing something.
    • by m00sh ( 2538182 )

      From the interviewing side, it doesn't really matter if you got the answer right, or could even complete it. Especially as an entry-level hire. Sure, it's a plus, but it's not a giant one.

      What I'm looking for when I ask these kinds of questions is how do you approach the problem, what is your thought process while solving it, how do you respond to any wrenches I throw into it, and do you understand a more elegant solution when I lead you to it or provide it. (It's also a spot-check on do you understand the basics of the language, but that's a secondary use of these questions)

      The fact that you could or could not solve it isn't all that important - we can all find google and it's extremely unlikely that you will actually face these kinds of trick problems in the real world.

      In the real world, you'd do something inefficient but simple-to-read and only switch to an elegant and fast solution if the profiler show it to be a bottleneck. Saving 100ms is huge, but if you only do it once in the lifetime of a long-running process, it isn't worth your time or the time of everyone after you who has to take 5 minutes to understand the elegant solution.

      So the questions are about you and the way you think, not whether or not you get the right answer.

      TL:DR - TFAuthor wasn't being asked what they thought they were, so they did not cheat.

      It's the first few second that determines if you're going to give someone an offer.

      The rest of the time is just spent reaffirming that belief.

  • Counter-Anecdote (Score:4, Interesting)

    by dcollins ( 135727 ) on Saturday May 25, 2019 @02:18PM (#58653698) Homepage

    On the other hand, I was once asked a question in an interview (convert a C-string of digits to the equivalent integer), I gave the textbook answer from my college's computer architecture course, and the producer interviewing me refused to believe it worked. Even after I stepped him through a concrete example. I did not get that job.

    Full story. [madmath.com]

    • I had an C++ phone interview a few weeks ago.

      [A] I stopped the interview and told them: ok, let me talk first, perhaps after 5 minutes you think I'm not the right guy.

      Background is, I did a lot of C++ from 1988 or so till 1999 (wrote my own subset of the STL etc.), and a few gigs later in embedded area up to about 2014. So, they wanted a coach for template meta programming in embedded devices.

      One of the interviewers was a eastern european marketing droid, proclaiming loudly in the first place, she has no cl

  • Easy (Score:5, Funny)

    by caywen ( 942955 ) on Saturday May 25, 2019 @03:06PM (#58653954)

    I would setup a new table in Oracle with a unique constraint on the column. Then I would use a SQL builder and insert items until I get an error. I would parse the XML error response, and infer from it whether it was the unique constraint that was violated.

    Efficiency is my middle name!

    • +3 Funny, right?

      I would expect from the parameters that you would be looking for duplicate records in a table if you were to approach the problem from a SQL perspective.

      Surely, though, if the data is held in a SQL array (how it would get there I'm not sure), then a more traditional solution to the problem would be more efficient? I suppose it would depend on the size of the array, and CPU and Memory constraints of the database hardware, and rather the disk writes would be the bottleneck or the compute.
    • Interesting approach.

      You would have got the job if you had printed out the stack trace of the error message and figured the result on your free time traveling home in the bus/train.

      Try better next time! You know, don't work smarter, work harder and most importantly, work longer!!!

    • The user enters the numbers on their Microsoft Surface Pro tablet using Microsoft Cortana. From there a web service will send the data to the MS Azure Cloud Computing platform which will make use of the MS Windows OS backend. The numbers will be inserted into a Microsoft SQL Server database that has the constraint to prevent duplicate numbers from being added. When the duplicate number is found Microsoft Clippy will announce the number on the users MS Surface Pro tablet.

  • If you're doing tests like this in your interviews I hope that at the very least you know that this test is Fizz Buzz but I've seen enough of these done badly that I think many, if not most don't even know that much. If you're doing this test you should at least know what the point of it was. To see if the person can code at all and think like a coder. No, it's not to see if the person can give a logically and syntactically correct answer. It's to see if the person knows what functions are, conditionals, re
    • Last time I ran into an online Fizz Buzz test, it was entirely automated. Rather than Pseudocode, or something similar, it had a choice of several languages I was not especially familiar with. Furthermore an IDE was allowed, which implied that accurate syntax was expected. I simply didn't have confidence in the designers of the process to submit a solution which wouldn't pass muster in an automated system. Probably take me longer than the short test/interview period to choose a language from the options and
  • Big secret: my company uses the same set of problems when interviewing technical staff. It takes effort to make a good set, so we don't bother to change it. We want to see how candidates approach the tasks and present their solutions, so we give them several hours and access to internet and phone while they work on the set.

    Probably the same thing happened, they were reusing good problems. I wouldn't worry. Life has a lot of lottery elements. Also there was much more to the selection process than this one pr

  • More than a half-century ago, I was a student at UCLA. Only three universities in the U.S. offered degrees in computer science, and UCLA was not one of them. Thus, I majored in mathematics with an emphasis on numerical analysis. I had just learned FORTRAN II but had not yet used it for pay.

    I was looking for a summer job, and IBM (then the largest company in computers) was hiring students locally for summer jobs. I went to their offices and joined a number of other students seeking work there. The HR pe

  • This falls under the heading of "Did my homework."

    If you happen to pick up valuable data during this process, kudos to you!

    And he's right, he was merely asked to solve the problem, and did.

    How is the Microsoft guy to know you weren't asked an IDENTICAL question at your last three job interviews?

  • Since most programming interviews are mostly pointless exercises in memory recall. I'd rather spend a few hours talking about design hypotheticals and the merits of different languages than force someone to sweat through a programming test. Tests are for colleges so a CS degree should tell you all you need to know about their abilities.

  • Comment removed based on user account deletion

Work is the crab grass in the lawn of life. -- Schulz

Working...