151–160 of 225 posts
It's not such a "mess" if you see that it just evaluates the string as a polynomial.
I don't think inverting binary trees is the problem per se. I mean, algorithms are the bread and butter of programming. You should be able to implement simple ones like that even if you'd never actually do that in practice. The real problem in my opinion is the whiteboard and time pressure.
I gave this example on Reddit this morning, but I'll repeat it. If a programmer was given an array of elements [a1, a2, a3, a4, ..., an-1, an] and asked to produce the array [a2, a1, a4, a3, ..., an, an-1] and couldn't do it, he'd be the laughing stock of /r/programming for a couple of days and we'd hear about this problem for years to come, the same way we hear about FizzBuzz. Certainly a programmer should know how…
1. I think phrasing matters a lot. Saying "invert a binary tree" creates an immediate suspicion in my mind that what I'm really being asked is not "do you know how to swap elements", but rather some kind of weeding-out trivia looking for a specific, probably named-after-a-person, algorithm they're expecting me to remember from a college course (tricky for me in particular, as I didn't do CS in college).
2. A whole lot depends on the context of the interview. While I know what a binary tree is and how it works, I've never -- in 11 years of programming professionally, and several more as a recreational/amateur before that -- actually needed to implement or even explicitly use one. There are a lot of things people will deride lack of knowledge of, things that people will consider to be hugely important CS fundamentals, that can literally just never come up in a lot of programmers' careers because they are not actually universally fundamental in all fields of programming.
So jumping into things that aren't relevant to the field you're interviewing for can achieve the opposite of what the interviewer hopes for: it's putting the candidate off-balance, but in the wrong way by making them wonder if they're interviewing for the wrong job or misunderstood what the job actually involved. Which in turn is going to affect their performance.
Yeah I remember the Google interview a few years back. I did it mostly for fun, and because their recruiters kept contacting me. So there we were, building a tree out of a forest of existing smaller trees or such. That was after they couldn't find my resume, and used a 5 year old one they found some place. They seemed annoyed and tired. By that time I felt nothing short of me proving P!=NP would have help changed the…
The difference was that I was able and to try various approaches out without pressure. I had access to my old algorithms textbook as a safety blanket. Some friends dropped by and we went out for supper, and I chewed over my ideas with them.
I also had two weeks to solve the problem, and even though it took one Friday night to solve the problem, being given 2 weeks to produce a working solution put me at ease.
Doing something like that in a high-stakes interview would be nearly impossible for me.
I recently interviewed for (and got) a new job. The interview process took about two weeks and on the whole was pretty reasonable for both sides. There was a short phone screen (~30 minutes) Then I had two technical exercises to do. For each, I was given a reasonable time period (4 hours) that started when I visited a special link to the get the problem description, and then used whatever tools I wanted to get it don…
The correct way to write a CSV parser is to import one.
An import solution is unlikely to work. Most import solutions would try to load the rows into memory, which doesn't work here. Maybe if the imported parser can be configured to run a user-supplied callback on individual rows and then discard them...
(P.S. solving the problem with awk still counts as writing a CSV parser --- in awk)
> So it exponentiates 31 by one less than the length of the string and multiples that with the first character's ascii, then exponentiates 31 by two less than the length of the string and multiples that with the second character's ascii, and so on and so forth, and sums the whole mess. And I'm supposed to know this. It's not such a "mess" if you see that it just evaluates the string as a polynomial.
> Now, in his defense, computing the dot product of the string with a random prime vector is a well known Universal Multiplicative Hash Function, but forgive me, father, for I did not pay much attention to this invaluable nugget in my Algorithms 101.
Well, I didn't pay much attention in such a class either, but isn't that just intuitively obvious? Dot-product a vector `x` with a vector `p` of (unique) primes, and well, you've got yourself a number unique to `x`.
This passage gives me a good idea: The OPower guy said they had a ton of problems where they will be using Scalding, so I asked him what they are doing in its absence. He said Oh we pojo it. Then he said pojo this and pojo that, and soon I was drowning in pojos, so I asked, Sorry, what exactly is a pojo ? Now, bear in mind I am a Scala programmer and haven't touched Java in ages, and they knew that. Their whole pitch…
Good advice! POJO (not pojo) is a virtually meaningless term. It was invented to denote any class that wasn't derived from a J2EE class (J2EE was superseded by Java EE in 2006 or so). A class with 7 levels of inheritance, implementing 14 interfaces but no J2EE class/interface among them is a "plain" POJO.
This passage gives me a good idea: The OPower guy said they had a ton of problems where they will be using Scalding, so I asked him what they are doing in its absence. He said Oh we pojo it. Then he said pojo this and pojo that, and soon I was drowning in pojos, so I asked, Sorry, what exactly is a pojo ? Now, bear in mind I am a Scala programmer and haven't touched Java in ages, and they knew that. Their whole pitch…
POJO stands for "Plain Old Java Object" and it is a somewhat common term. http://en.wikipedia.org/wiki/Plain_Old_Java_Object The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:[1] "We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely…
> So it exponentiates 31 by one less than the length of the string and multiples that with the first character's ascii, then exponentiates 31 by two less than the length of the string and multiples that with the second character's ascii, and so on and so forth, and sums the whole mess. And I'm supposed to know this. It's not such a "mess" if you see that it just evaluates the string as a polynomial.
And then the author writes: > Now, in his defense, computing the dot product of the string with a random prime vector is a well known Universal Multiplicative Hash Function, but forgive me, father, for I did not pay much attention to this invaluable nugget in my Algorithms 101. Well, I didn't pay much attention in such a class either, but isn't that just intuitively obvious? Dot-product a vector `x` with a vector `p`…
Much like hashes themselves going one direction is much harder than the other.
> The first programmer with/without a shadow walks in. He's quite annoyed, because he was neck deep in jira or git or debugging some hairy stack-trace on eclipse, and he's been unceremoniously yanked off to interview YOU - the new dude, who has no fucking idea how things really work here. Well, he must show YOU your place. You lowly worm... Oh man, I hope I n ever come off that way when I'm the interviewer. I always…
You're lucky you get a heads up. On more than one occasion I've had a manager come up to me and say "We're in the middle of interviewing a candidate right now in conference room X. Please come and ask a few questions and see what you think of him".