• JJ (unregistered)

    To everyone who said, "Perhaps the interviewer could have phrased the question better," THAT'S THE WHOLE POINT! It's not that snoofle didn't understand what the interviewer wanted; it's that he recognized that the interviewer (who would probably have become his boss) was a bad communicator, and that was a red flag. I've worked with people like that, and I'd prefer never to again. If I were to glean such insight from interview questions, I'd end the interview as well.

  • derp (unregistered) in reply to JJ
    JJ:
    To everyone who said, "Perhaps the interviewer could have phrased the question better," THAT'S THE WHOLE POINT! It's not that snoofle didn't understand what the interviewer wanted; it's that he recognized that the interviewer (who would probably have become his boss) was a bad communicator, and that was a red flag. I've worked with people like that, and I'd prefer never to again. If I were to glean such insight from interview questions, I'd end the interview as well.

    This. The core of the interview question in and of itself is in no way unreasonable, in my opinion. I think it's a fine candidate for a programming question. But it should be phrased as such right off the bat: "Please implement a function that calculates the square root of an integer without using a Math library." or whatever.

    Going through a chain of "what if's" is 90% of the time irritating and petty UNLESS you are, in fact, trying to iron out an obscure problem and gather requirements. That is not the case here, however. And if you wanted to have such a question, it would be approached with "what if you had this input," or "what if there was this corner case" but probably not "what if you didn't have this basic technology that you might actually need to solve this problem effectively."

    That said, anything where you want to have the candidate explore the problem needs to be designed that way right off the bat, and needs to be much more complex than "implement sqrt."

  • DSkoll (unregistered) in reply to snoofle
    snoofle:
    coder guy:
    It seems to me that anyone who can't even come up with a lame attempt at successive approximation to figure out a square root without running to a reference isn't fit for a programming job.
    Why? The guy wanted an exact value, not an approximation.

    OK, snoofle. I won't be hiring you.

  • DSkoll (unregistered) in reply to Level 2
    Level 2:
    Your computer does not have enough memory for an exact representation of sqrt(2).

    Actually, mine does because it represents numbers in base(sqrt(2)). It seems to have problems with numbers like "1", however.

  • DSkoll (unregistered) in reply to QJo
    QJo:
    Fail. You can't get it exact because square roots are (in all cases except when all the prime factors are to an even power) irrational.

    Oh? So sqrt(0.789 * 0.789) is irrational?

  • PG4 (unregistered)

    Snoofle for president!!!!!!!!!!

    OK, yes we know that interviewer wanted to find out how snoofle would approach a problem. However......

    The BS of keep taking away valid answers is just stupid. Others have said it, the interviewer should have asked the question in a different way. If you ask the question that way because that's the only way you have heard it done, then it shows just how small minded the interviewer is.

    And snoofle said it, he has seen what happens in job when they ask these types of questions, and he doesn't like it.

  • Whatever (unregistered)

    I think snoofle makes too much about the specific problem, sqrt. The interviewer is trying to find out his problem solving skills, and the only thing snoofle is thinking about is how he can copy it off of someone or sth. I wonder how many hours he will spend trying to find a design pattern for each and every small problem that comes at him. Would he even do any creative work? Or maybe he just designs gui. I dont know. I mean, he know what a square root is, doesnt he?

  • PG4 (unregistered) in reply to Whatever

    Well I think you would fail in just about any security situation.

    Ever see the code that people write when they really don't understand all the crypto issues? Better to take a WELL proven chunk of code and use it than reinvet the wheel with all kinds of security issues.

  • Anonymous Coward (unregistered) in reply to DSkoll
    DSkoll:
    QJo:
    Fail. You can't get it exact because square roots are (in all cases except when all the prime factors are to an even power) irrational.

    Oh? So sqrt(0.789 * 0.789) is irrational?

    No, in sqrt(3^2 * 263^2 / 2^6 / 5^6), all the prime factors are to an even power.
  • (cs) in reply to Niels
    Niels:
    An iterative approximation for a square root shouldn't be hard to come up with.

    It's really worth it to (re)learn Newton's method. Just to see if I can do this off the top of my head:

    You're looking for a zero, right? So you're going to guess an x, calculate f(x), giving you a y. Then you want to draw a line tangent to the curve at that (x, y), and the zero of that line is your next guess.

    Obviously, the slope of the tangent line is the derivative, and we're looking for is the solutions to x^2 - n = 0, where 'n' is the number we're taking the square root of.

    The derivative of x^y (where y is constant) is the first rule you learned: y * x^(y-1). n is constant, so the derivative is just 2x

    To find the tangent line from a point, expess it parametrically by setting the slope equal to itself:

    m = (0 - Y) / (x - X) x = X - Y/m

    In python:

    def newton(func, deriv, guess):
        x = guess
        while True:
            y = func(x)
            yield (x, y)
            x = x - y / deriv(x)
    
    n = 20.0
    eps = 1e-12
    for x, y in newton(lambda x: x * x - n, lambda x : 2 * x, 1.0):
        print x
        if abs(y) < eps:
            break
    

    To make it more robust, you can pick some random number if 'm' turns out to be zero :-)

  • dv (unregistered) in reply to ME2
    ME2:
    The correct answer to the Square root question is obviously:

    How does having me re-implement standard library functions bring in revenue to this company?

    You god damn geekass bastards.

    No, the correct answer to the Square root question is obviously: "Is this to be an empathy test?"

  • David (unregistered) in reply to derp
    derp:
    Going through a chain of "what if's" is 90% of the time irritating and petty UNLESS you are, in fact, trying to iron out an obscure problem and gather requirements. That is not the case here, however. And if you wanted to have such a question, it would be approached with "what if you had this input," or "what if there was this corner case" but probably not "what if you didn't have this basic technology that you might actually need to solve this problem effectively."

    Doublethis.

    Being asked "what if $REASONABLE_THING" is perfectly valid. But being asked "what if $DUMB_THING" is as redflagful as being asked to "code up a web 2.0 app to leverage our synergies going forward". Both should be treated accordingly.

    Clearly the interviewer heard about this really cool interview techique and cant wait to try it out without actually understanding it at all. Of course, that may be his only fault. And unlike snoofle, others might be quite happy to take a chance on that being his only fault, and go to work for him anyway.

    Indeed, I look forward to seeing some of their code on this very blog.

  • (cs)

    A Taylor series works as a calcuation of f(x+a) based on the evalution of f(x) being simple to calculate as well as all the derivatives of f at x.

    The derivatives of sqrt are powers of -.5, -1.5, -2.5 etc so you need the square root of the x. Therefore we start based on a squared number.

    mod(a) should be < x for this and you should probably factor it down to make x==1 so divide the whole series by a constant so it ends up being that way.

    If you want the square root of 29, for example, you would divide by 25 to get the square root of 1.16 so x = 1 and a = 0.16

    If you want the square root of 47, you could divide by 49 (better than 36) and a would be negative.

    Incidentally if x is rational then you would be able to store root(x) "exactly" in your memory as long as you don't store it in IEEE format but store it in a special class either as a square-root (algebraic number in general) or as a recurring continued fraction. Irrational square roots are always recurring continued fractions.

    pi and e are transcendental (numbers that are real but not algebraic) but both are sums of an infinite series of rationals. pi/4 is atan(1) so usually pi is calculated as atan(1)*4.

    Understanding Taylor series expansions, interpolation techniques and other solving problems may well be required in a programming job. Most of the equations you will be solving won't be square-roots and won't be solvable by a library function. Of course the interviewer may have said after the square root one, "ok now solve this" and give a function that has no library solution...

    Incidentally I would normally only ask at interview something that either:

    • was relevant for the job or
    • was something the user specified on their CV.

    and usually the latter. So if the candidate doesn't want to be tested on it, they shouldn't put it on their CV.

  • (cs)

    You see it is interesting to read the solutions here as to how you handle the "epsilon" situation.

    I am seeing people use absolute epsilon which is faulty. Error is relative, not absolute.

    IEEE numbers allow exponents of 2 to the power of something like 1023 so if you are asked to find the square root of 2 to the power of -1022, you can find it exactly, it will be 2 to the power of -511. Not approximately that, exactly that. No rounding errors. Similarly 9pow(2,-1022) (yeah, 1.125pow(2,-1019) has an exact square root of 3pow(2,-511) (1.5pow(2,-510)).

    If it is 5*pow(2,-1022) there won't be an exact square root, of course, but have your answer out by 2 to the power of -15 and you are way out...

    Conversely if we are going to find the square root of 5 * pow(2,1014) your epsilon will need to be a LOT higher...

    The "error" needs to be in the square root, not in the square.

    For me, the ability to ensure the algorithm terminates properly is more important than the fastest merging numerical method, so I would rather see a correctly-terminating binary interpolation algorithm than a faulty Newton-Raphson.

    The weird way doubles are processed means that when you do reach the final destination, it won't neceesarily equate "equal" to either of your lower and upper bounds. (And actually I was not quite correct earlier. You won't always move between solutions too low and too high. You will for square root but not for functions in general).

    Incidentally alternative interpolation methods are:

    • Quadratic interpolation, although it requires you know how to calculate square-roots. Also assumes you know derivatives, but works in "general". You solve current value, last value and current slope (but not last scope).

    • Cubic spline interpolation. For just 2 points you would use values and slopes at both points. The only issue is actually "solving" the cubic (which is solvable, Nicolo Tartaglia).

    Normally used to interpolate when you don't have absolute values and usually done with multiple values, and the "slope" is not known at the key points but continual ranges are assumed to be continuous in slope at these points, which does give you a bit of scope at the end points.

    These interpolations are worth using when the function you need to evaluate is very expensive compared to all else.

  • (cs)

    Ok, I am going to comment on the Founders issue, and the real WTF there is that in most cases, the business of the start-ups should be based on market research on what they are going to sell, and not on how they will implement it.

    The development side should be trusted to the technical architects.

  • Wazza (unregistered) in reply to Cbuttius

    Its not hard:

    public static double sqrt(double val)

    { return 1; # accuracy increases as val -> 1

    }

  • chfexcel (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL

    How about: "Imagine all the people / Living life in trees"

    • it rhymes better
  • DES (unregistered) in reply to dv
    dv:
    No, the correct answer to the Square root question is obviously: "Is this to be an empathy test?"

    This.

  • eil (unregistered)

    My final answer to the last interview question would have gone something like:

    "I wouldn't have time to be worrying about square roots, I would be with my family trying to find the nearest fallout shelter."

  • (cs)
    1. In the hypothetical situation there is no google or search engines so I can now have a great idea for a start-up.. No need to be reinventing the wheel of calculating the square root, I will reinvent the wheel that is google instead and make billions.
  • Sam I am (unregistered)

    I'm disturbed by everyone suggesting that the square root problem is some sort of interview 2.0 question.

    it is a numeric theory and algorithmic question, and the skills that you need to solve it can actually be very relevant to your job even if it might not seem so at first.

    It's as though everyone expects you to be given actual problems from production when you go to an interview.

  • (cs) in reply to Sam I am
    Sam I am:
    I'm disturbed by everyone suggesting that the square root problem is some sort of interview 2.0 question.

    it is a numeric theory and algorithmic question, and the skills that you need to solve it can actually be very relevant to your job even if it might not seem so at first.

    The skills to correctly solve it "in real life" are exactly the skills that have been shown by the author:

    1.) Don't reinvent the wheel (badly). Know that it is a solved problem. Know what your platform provides. 2.) If your platform does not provide it, use a search engine to find out if it already has been solved by someone else (bonus points for knowing a good search term for this). 3.) If that still is insufficient, look up (scientific) literature about the problem. If others already have tackled the problem, chances are that they know about problems that you will run into with a "invent-it-myself-in-10-seconds" approach. (see sqrt(x) when x < 1)

  • Shea (unregistered)

    Wow that last one sounds like an old naval joke:

    CO: "Sailor, what would you do if a strong wind came up the port side?" Sailor: "I'd drop an anchor off the port side, sir." CO: "Then what would you do if there was a strong gust from starboard?" Sailor: "I'd drop an anchor off the starboard side, sir." CO: "But what if a wind came up from astern?" Sailor: "I'd drop an anchor off the stern, sir." CO: "Wait a minute, sailor. Where are you getting all of those anchors?" Sailor: "The same place you're getting all of the wind, sir."

    The first sign of a bad technical job is often a bad interviewer.

    Shea

  • Capt. Obvious (unregistered) in reply to Severity One
    Severity One:
    If he wanted to know how you'd deal with a situation where you don't have all the information readily available, he should have bloody asked and not come up with some Interview 2.0 rubbish that he clearly didn't understand himself.
    He did: "What if you couldn't use Google"

    Leaving aside whether Google is "all information", the interviewee clearly understood it to mean "no internet". After all, the next suggestion wasn't to Bing it.

  • (cs)

    That recruitment question is far from stupid in my opinion. The point of it was most likely determining whether or not the candidate is capable of coming up with an ad-hoc solution to a relatively simple problem when having nothing to rely on outside his own memory and reasoning ability.

    The solution to the problem is a simple - if slow - approach known as the bisection method. It's not unlike binary search (which you should be familiar with): given a range between a and b where the root should be present (for numbers larger than 1 this initial range will be between 1 and 1/2 x) and then check whether the number between a and b is within set precision from the root ( return it ), smaller than the root ( set a to this number, repeat ) or larger than the root ( set b to this number, repeat ).

    This is literally something out of a beginner grade algorithms course, and a fairly reasonable way of finding out whether you can reason your way out of a wet paper bag. The problem is simple, practical and can be solved in a few minutes without bizzarro lateral logic.

  • (cs) in reply to Capt. Obvious
    Capt. Obvious:
    Severity One:
    If he wanted to know how you'd deal with a situation where you don't have all the information readily available, he should have bloody asked and not come up with some Interview 2.0 rubbish that he clearly didn't understand himself.
    He did: "What if you couldn't use Google"

    Leaving aside whether Google is "all information", the interviewee clearly understood it to mean "no internet". After all, the next suggestion wasn't to Bing it.

    Well the interviewee understood! Severity One's point however was that the interviewer did not understand his own questions - and that you have proven: He asked "What if you couldn't use Google?" when he should have asked "What if you couldn't access the internet?".

  • satoshi (unregistered)

    Personally I'd rather work with somebody who already knew what "square root" means than somebody who knows details of an old TV series, apparently I'm in a minority around here.

  • foo (unregistered) in reply to ctd
    ctd:
    foo:
    OccupyWallStreet:
    What if you're not allowed to use NAND gates? And no, wiring transistors up to form NAND gates is not allowed. You are, however, free to wire up transistors to form any other logic gate (except NAND), but the gate you choose is the only one you can use.
    That's neither funny nor relevant.
    Sure it's relevant. Having followed a line of reasoning (Brownian motion though it may be) we're discovering how far the candidate's knowledge goes. Knowing one can build a full computer out of NAND gates indicates (not guarantees; that's why we keep digging!) his knowledge goes pretty deep. Now, let's see if he just happens to know the random factoid "you can create a computer with just NAND gates", or is his knowledge at that point broad enough to also know the same of NOR gates?

    What snoofle and others miss in their insistence "you're not learning anything useful about the candidate! but the interviewer's tone shows he's an idiot!" is the reverse is true too: the candidate's tone (including the quasi-hypothetical "that's neither funny nor relevant") derives the same conclusion.

    Sure, you're not going to be required to code up square root functions, nor will you be limited to your choice of non-NAND gates. If you don't find inherent challenge or humor in such hypotheticals, if http://xkcd.com/505/ or http://ioccc.org/ don't intrigue you despite their obtuse irrelevance, you're not the droid we're looking for.

    I repeat: That's neither funny nor relevant.

    Got it now?

  • raduma (unregistered) in reply to Spewin Coffee

    I'm not sure I agree with that reasoning. It seems to imply that for every single problem you might run across there's already an sdk or book or such that tells how to solve it. Which if true it basically says that there's nothing new to solve in the realm of CS. I don't think lots of people would agree with that.

    While asking for something like implement sqrt may be a bit lacking in signal since it's very math oriented instead of cs oriented (though personally I'd expect most decent engineers to be able to come up with even a bad solution), asking interview candidates to try and solve problems that aren't in their comfort zone I do think can give you some good insights into the candidate. You do get to see how they think as opposed to how regurgitate patterns and solutions they've been repeating for years. God knows I've interviewed plenty of people who on paper were serious engineers but couldn't solve a basic problem like reverse-a-singly-linked-list w/o access to their precious sdks.

  • qbolec (unregistered)

    I find amussing comments from people who claim to have forgotten the formula for square root. Let us know when you recall it. It will be fun.

    So many of you are missing the beauty of binary search which lays preceisly in the fact that it does not require you to know anything more about the function than if its argument is too large.

    Recently I had to icompute number of weekes between two timestamp. After writing unit tests and considering for a moment precomputing for all possible inputs, I given the standard library a chance. Unfortuanately php's date_diff returned wrong number of weeks. But I knew that there is strtotime function which uses very robust linux library and I knew it had +n weeks functionality, so in a minute I hacked a simple binary search workaround for a buggy library.

    Another example. I had a system in which I could access rows only by a key, yet I needed to know number of rows. Again, binary search came in handy.

    Please, skip "trwtf is php" and "a man with a hammer sees only nails" comments, and admit it: the real wtf is not knowing binary search, and not recognizing theoretical question despite hints. I doubt the same attitide at school was helpful. If someone treats everything so literally he might have some troubles with abstract thinking whoch might be necessary to model parts of the reality in a program.

  • (cs) in reply to raduma
    raduma:
    I'm not sure I agree with that reasoning. It seems to imply that for every single problem you might run across there's already an sdk or book or such that tells how to solve it. Which if true it basically says that there's nothing new to solve in the realm of CS. I don't think lots of people would agree with that.
    Let's remember Finagle's Law. :) For every simple and effective Plan A you have, you may end up going through Plans B up to F when that plan meets reality. Likewise, that there is an SDK, book, guide or implementation does not mean we have it on hand - or that we have time to obtain it.

    In a practical scenario, I'd implement the bisection method as a temporary stopgap solution, leaving myself a note to redo it properly when I have access to my precious reference materials.

  • (cs) in reply to Sam I am
    Sam I am:
    It's as though everyone expects you to be given actual problems from production when you go to an interview.

    For which the answer should be "if you want me to solve your production issues you have to hire me first, or at least pay me a one-off consultancy fee of £500 (or whatever)".

  • katastrofa (unregistered)

    snoofle failed the interview and made an idiot of himself. The interviewer was clearly trying to check if snoofle knows about Newton's root finding algorithm. This is basic stuff which every programmer who's ever worked with numerical code should know.

    There were many ways to handle this situation with dignity:

    1. describe the root finding algo snoofle would have used to solve the equation x*x = y for given y
    2. answer "I'm sorry, I don't know much about numerical programming"
    3. if 2. would be false, attempt 1. but fail, and consider this a lesson learned

    This was a valid question and I think snoofle's interviewer showed him much patience as things were.

  • (cs) in reply to qbolec
    qbolec:
    So many of you are missing the beauty of binary search which lays preceisly in the fact that it does not require you to know anything more about the function than if its argument is too large. ... Please, skip "trwtf is php" and "a man with a hammer sees only nails" comments, and admit it: the real wtf is not knowing binary search (...)
    Three points: 1.) TRWTF is PHP 2.) A man with a hammer sees only nails. 3.) The real real WTF is not knowing the limits of your silver bullet: binary search works if you have a monotonic function. sqrt(x) is monotonic when x >= 1. However for non-monotonic functions a binary search will fail.
  • byobg (unregistered)

    Just to pile on snoofle some more here...

    I've gotten job offers out of interviews that were really, really easy, where I knew all the answers AND could come up with them in ten seconds. I've never taken one of those offers, though I certainly would if I had no other options and needed the paycheck - I'm not an idiot.

    But if the interview was easy, then they don't KNOW I'm not an idiot. Which means that they don't know if my future co-workers or bosses were idiots when they hired THEM. Maybe they got really lucky, but idiots are really easy to find, especially at job interviews, so the odds aren't great.

    And snoofle - leaving aside the whole issue of not figuring out the point of the question, even after many (admittedly coy & overly-"cute") hints - would you really drive to a bookstore and buy a book about square roots (that'd be some dry reading) rather than try to figure out your own solution? Even assuming a car parked nearby, no traffic, and no line at the checkout, that shouldn't be the fastest way to solve the problem.

    There are all sorts of approaches to take to a "How would you solve this hypothetical problem?" question. Yours, repeatedly, was basically, "I'd look for somebody else's solution to it and copy that into my code and probably change some variable names until it compiled. That would be efficient, because I'd never have to waste time understanding the problem OR its solution." I've seen a depressingly large number of programmers who take that approach to their jobs, but few who actually admit to it in interviews.

  • qbolec (unregistered) in reply to no laughing matter

    i assume you are joking based on the first two points, but i will answer anyway.

    1. Sqrt is monotone in whole domain of no negative real numbers
    2. One should apply binary search to the inverse of the function(in this case squaring) and not to the function itself (in this case square root). Although i will admit that function is monotone iff its inverse is as well.
  • (cs) in reply to qbolec
    qbolec:
    i assume you are joking based on the first two points, but i will answer anyway. 1. Sqrt is monotone in whole domain of no negative real numbers 2. One should apply binary search to the inverse of the function(in this case squaring) and not to the function itself (in this case square root). Although i will admit that function is monotone iff its inverse is as well.
    1. I did not claim contrary. 2. Binary search is still the wrong tool if the function is not monotone.
  • Sam I am (unregistered) in reply to no laughing matter
    no laughing matter:
    Sam I am:
    I'm disturbed by everyone suggesting that the square root problem is some sort of interview 2.0 question.

    it is a numeric theory and algorithmic question, and the skills that you need to solve it can actually be very relevant to your job even if it might not seem so at first.

    The skills to correctly solve it "in real life" are exactly the skills that have been shown by the author:

    1.) Don't reinvent the wheel (badly). Know that it is a solved problem. Know what your platform provides. 2.) If your platform does not provide it, use a search engine to find out if it already has been solved by someone else (bonus points for knowing a good search term for this). 3.) If that still is insufficient, look up (scientific) literature about the problem. If others already have tackled the problem, chances are that they know about problems that you will run into with a "invent-it-myself-in-10-seconds" approach. (see sqrt(x) when x < 1)

    Would you rather the interviewer spend the time to invent an unsolved unconventional question, what would really serve no additional benefit other than the fact that you don't get smarmy answers from people like snoofle and you?

  • Gabe (unregistered) in reply to coder guy

    My guess was the interviewer was feeling the waters to see how he thinks through recursion. Interviewer won that one. NEXT!

  • Meep (unregistered) in reply to katastrofa
    katastrofa:
    snoofle failed the interview and made an idiot of himself.

    As he said, the interviewer was condescending. If you get a bad vibe from an interviewer or during any business deal, you have to trust your instincts.

  • Ides (unregistered)

    The interviewer did learn how he thought: the guy told him all the steps he would go through, i.e. ask someone, go to a bookstore. After the interviewer learned this information he kept asking for the guy to solve the problem that the guy already explained how he would solve! Definite fail. The job wasn't a good fit -- walking away was probably short tempered, but definite time saver for them both!

  • Andrew Au (unregistered) in reply to Cbuttius

    Can't help to comment on the last line. It was wrong.

    In the square root case, the Newton iteration values will always be a upper bound to the root, to see why:

    Let square root of y be z, and x is an upper estimate of it, we have

    (x - z)^2 > 0 x^2 - 2xz + z^2 > 0 x^2 - 2xz + y > 0 x^2 + y > 2xz x + y/x > 2z

    Now we see the value of next iteration = (x+y/x)/2 > z and therefore is also another upper estimate of z.

    That is critical because you can also compute a lower estimate of z by simply doing y/x and have an interval estimate of z - one can stop at any point the both estimate agree to the level of precision one is good enough.

  • qbolec (unregistered) in reply to Andrew Au

    this is also a direct effect of covexity of f(x)=x^2

  • belzebub (unregistered)

    I'm not so sure about that snoofle's interview. I can see what the interviewer was trying to do - find out how resourceful he is. Which is fine by me. Snoofle on the other hand proved that he is not willing to find solution by himself being proud that he is not "math wiz" (I really don't understand why people claim this so proudly). I'll bet the interviewer would be happy even with a STUPID, SIMPLE, APPROXIMATED and SLOW solution (like computing squares of increasing numbers and comparing result with given number), but snoofle was too lazy to think. Don't get me wrong, I do not thing that creating your own sqrt in java is important programmer's skill, I just think that while people who REFUSE to think may be good enough for some "generic" code monkey positions, they may not be good enough for position where you have to design and not just code.

  • Thomas (unregistered)

    Trouble With Founders pretty much sums up Deep Space 9.

  • (cs)

    Snoofle isn't an idiot, he is an arrogant type that storms off an interview if he doesn't like the questions he is asked... or the attitude of an interviewer... or something else that triggers his red flag. Whatever. Never mind that he might be interviewed by someone who is:

    • new,
    • young,
    • inexperienced,
    • wants something other than a canned answer,
    • want's a canned answer,
    • is not going to be working on his team at all,
    • will be working in his team and wants to see how he does under stress,
    • does not represent the company at all, any combination of above plus a gazillion other reasons this situation could've come up... who cares, snoofle already knows that this job is not for him, so he walks out. Good for him, good for the company he walked out on. It's a win-win, as far as I am concerned, in fact I think these kinds of questions should be used more often if nothing else just to weed out the snoofle types of people because from what I've read in the post and in the comments it doesn't look like he is a pleasant person to be working with, especially under pressure... of course I could be wrong, that is just an impression I got from reading this thread.
  • Narpas (unregistered)

    Regarding "What's the Square Root of Stupid?"

    Most people don't really know how to do this, obviously. The interviewer might want somebody who's willing to take an earnest crack at something that they're pretty sure is impossible. Or maybe the interviewer's looking for somebody who is humble enough to say, "Unfortunately, I don't really have a good idea on that."

    If I were the interviewer, I'd keep that question on the list to weed out people who couldn't accept that their job might push them past their reasonable limits.

    Besides, I don't think it's that hard. "First, we're going to find the two integers that the square root is between. Let's take an example of sqrt(30). We can iterate though integers to find this, although if we weren't in an interview I might think of a better way of getting these. 1 goes to 1, 2 goes to 4, 3 goes to 9, 4 goes to sixteen, 5 goes to 20. Then, we'll iterate though 4.1 to 4.9 to determine the next digit. 4.4^2 is 19.36, 4.5^2 is 20.25. Then, we repeat the process to the desired precision. Eventually, we'd get 4.472."

    There. I just answered the damn interview question in less than five minutes.

  • Narpas (unregistered) in reply to Narpas

    To anybody who reads my last comment, I've never commented on TDWTF before, and I am just now learning that the two "Featured Comments" are not the entire comment chain. XD

    I still think storming out of an interview over a bad question might be a self-damaging habit. Having a mediocre job offer is better than having no job offer.

  • me (unregistered) in reply to me myself and I
    me myself and I:
    John:
    Hey, where can I get a computer like yours, that can represent sqrt(2) exactly?
    Your computer can already represent that perfectly.

    √2

    See, that was not soo difficult, or was it?

    that is presentation not representation. The computer see's that as (U+221A) '2'. It can't use that value in a computation nor would it present it as the result of one, it will always present 1.141..

  • Buddy (unregistered)

    From way back!

    double sqrt(double d) { int n, invert, exponent; double working;

    /* Handle bad input */
    if (d < 0.0) return -HUGE_VAL;
    
    /* Handle 0.0 case */
    if (d == 0.0) return d;
    
    /* Invert any input less than 1.0 */
    invert = (d < 1.0);
    if (invert) d = 1.0 / d;
    
    /*
     * Normalize the input to 1.0 <= d < 2.0 by splitting it into a
     * mantissa and exponent.
     */
    d = frexp(d, &exponent);
    
    /* Save the mantissa */
    working = d;
    
    /* Do a first approximation */
    d = (d + 1.0) / 2.0;
    
    /* Iterate using Newton's method */
    for (n = 0; n < 4; n++)
    {
    	d += working / d;
    	d /= 2.0;
    }
    
    /* Correct for odd exponents */
    if (exponent & 1) d *= 1.414213562373095049;
    
    /* Recombine the comp1.0nts */
    d = ldexp(d, exponent / 2);
    
    /* Invert if required */
    if (invert) d = 1.0 / d;
    
    return d;
    

    }

Leave a comment on “Trouble With Founders, the Lost Candidate, and More”

Log In or post as a guest

Replying to comment #:

« Return to Article