Thursday, August 30, 2007


I just don't understand it. Almost everyone I interview is pretty clueless. It's very frustrating to go into an interview with a list of questions and have the candidate strike out on nearly every one.

My group is looking for a person who would be a good lead developer for the GUI portion of one of the Calibre tools. So, obviously a NUB probably wouldn't qualify. But to be honest, the recent grads probably know more than the two ... um ... candidates (biting my tongue here) I've had the ... joy of interviewing.

The first was someone already working for Mentor. He'd been there for 7 years. Turns out he had a masters - of mechanical engineering (I didn't notice the area of study until after the interview). I lined up my standard line of questions, the first couple of which I'm embarrassed to even ask. Because the the first set of questions are embarrassing, I begin by saying something to the effect that I always ask these questions and if they seem too simple, we'll blow right through them, it's not to be taken as an indication of my first impression of the candidate.

Here's essentially what I ask:

  • Name some basic data structures. What are the trade-offs of using one over the other?

  • Define the following C++ terms:
    • inheritance
    • virtual functions
    • static functions/data
    • abstract base class
    • pure virtual function
    • operator overloading
    • templates
    • polymorphism

  • When do you use templates and when should you use inheritance?

  • First programming question, complete the following:
    int string_to_int(char *str) {
    /* convert string representing a number into an integer */

    Restrictions come in as appropriate: (can't use atoi, strlen, exp, use only O(n) multiplications.

  • You are given a long line and are told to cut it up into pieces.
    The restrictions are:
    .) No piece can be shorter than some MIN length
    .) No piece can be longer than MAX length
    .) Every cut must be on a unit boundary
    .) There are locations that cannot be cut, presume the function can_cut(x) tells you whether or not you can cut at a location x

    Describe how you would do this.
    Can it be done in linear time/space?
  • A design question from my brother: design a messaging system to handle arbitrary messages of a variety of types, with listeners and senders who may be geographically diverse.
  • And lastly, because we had a little time:
    Write a function `samepattern' that takes two string arguments, 
    and returns true iff the strings have the same pattern. Two strings
    have the same pattern if when elements are equal in the first string,
    the corresponding elements in the second string are equal, and vice

Well, the first guy barely answered the data structures questions - which is a bad sign. He did marginally better with the C++ questions, and then we hit the first programming question. He had a horribly difficult time realizing that 123 is 1*10^2 + 2*10^1 + 3*10^0, and finally, after I provided that information he had a tough time figuring out the solution (we never went through refinements, I needed a break). The rail-cutter problem simply baffled him - he had no idea where to start when his algorithm reached a point where he couldn't make a cut. The design question was abysmal, I got a couple of class names out of him, but I had to hold his hand to get each one. I forget how I ended things, but I tried to keep a smile on my face.

The second guy I interviewed did better. He got a little flustered with an impromptu virtual function question I wrote, but it was obscure. He had written string_to_int sometime in his long history (he'd graduated college before I was born), so he nailed that. At that point I noticed he didn't write anything down - no big deal as he nailed the question. We moved on to the rail cutter question and he had some trouble. His code (once I got him to write things down) was horribly ugly and showed he had no idea how to actually return the results. Furthermore, he had NO confidence his program would work, and simply guessed at the runtime. The design question was like pulling teeth, he didn't seem to like talking about design, nor did he seem to think about the scaling implications of a large system. Then, with the few remaining minutes I thought I'd throw him a softball, the 'samepattern' function, so we could end on a high note. He stared at the problem (only responding by saying he understood it) for 8 minutes before giving up.

The first guy just bombed, the only feedback for him would be to go back and study your CS101 and other introductory courses. He, at least, was eager and energetic and put forth a great effort.

The second guy, well, he's been around long enough to know better.

First, be confident about what you're doing, and if you're not, have an idea where the problems might be. He literally told me he didn't think his solution would find all the test cases. Ok, that's honest, but it tells me he really didn't understand the problem he told me he did, nor can he recognize the exhaustive search he just wrote (which did cover all cases).

He then said it'd run in polynomial time, which covers most everything. I asked him to refine that, b/c that covers everything from linear to N^100000 and beyond. He had no idea, letting me know he'd just guessed. His solution ran in exponential time, much worse than polynomial.

Third, write stuff down. It's fine to talk, I encourage people to talk, talking is good because it lets me know your thought process. But if the interviewer passes you a piece of paper and a pen and asks you to "write a solution" then you'd better do that. Hand-waving only gets you so far and I, as an interviewer, am going to ask specific questions to get through your hand-waving.

Lastly, never simply give up on a problem. Try talking through it, brainstorm, do something. Staring at a problem for 8 minutes w/out saying anything is a sure way to lose the interview. Especially when the problem was literally taken out of an introductory CS course.

Lastly, at the beginning of the interviews I ask candidates how they think they rate on a scale of 1 to 10 (clueless to expert) for each of their programming languages. People seem to respond 7 or 8, regardless of their actual background. For C++, I find it very interesting that someone would answer that high of a number when they either don't use STL, or have only used STL. Now a scale is rather arbitrary (and the geeks who're reading this far are thinking, "well, is is the scale linear, logarithmic, what?"), but still. If you've never done template programming, nor can you explain *why* you'd want to do template programming, you're likely not an 7, surely not an 8. And if you stumble horribly on a virtual function question, you don't rate above a 6.

Ironically I think I'm a 7 or 8. At least I can answer all my questions.

iBike WW34 & WW35

Two rides happened this weekend. The standard "go to farmer's market" on Saturday, only this time Tom joined us, riding on my single speed. You could tell Tom really grooved on riding a single speed by his constant praise, "um.... why?"

And on Sunday, the Wyatt's came down to see us and ride. We went down town, then through campus, over the covered bridge, and back on 53rd. It was a beautiful day for a ride, and we finished by picking a quart of black berries to make dessert. yum!

Wednesday, August 22, 2007

NPR Touts Pro-Nuke 'Environmentalists'

I remember hearing the NPR piece about nuclear power which talked with David Whitford. When I got to work I briefly tried Googling him to see what his ties were, but didn't get much past the fact he is a writer for FORTUNE. And I couldn't remember the 'environmentalist' mentioned in the piece, Stewart Brand, who turns out to have strong ties to the nuclear industry.

I'm glad FAIR did a little critique of the piece and of NPR's coverage of nuclear power, as even I found it to be woefully one-sided: NPR Touts Pro-Nuke 'Environmentalists'

Tuesday, August 21, 2007

The Problems With 401ks

I'd heard the same logic applied to Bush's plan to privatize social security, namely that it'd be a horrible idea because it ultimately would just give Wall Street incentive to skim money off the top, and puts the onus on Joe Blow to properly invest that money (which is *exactly* what pensions/social security was to solve). If you look at the stats, over 80% of actively managed funds fail to beat the S&P 500. A big portion of that is the fees involved are often 1% or higher of the the value of the funds (not just off the profits). That has a huge impact on the returns you'll make in the long run.

So, it seems obvious to me that when investing, you should invest in the index funds (perhaps S&P 500, maybe a mid or small-cap fund, a european/asian fund (to diversify outside of the U.S. market)). Do you really think you're going to do to better than people whose job it is to invest? And given the fact that 8/10 of them cannot reliably beat the S&P 500...

And you can always find short-term winners. I know people who are gung-ho on AAPL because it's done great things for the past couple of years, and that's great. But like others who I know who are still heavy into INTC and MSFT (which have essentially been flat for 10 years), all quick risers come to an end. The regression toward the mean is really strong.

Anyway, that's a long intro to the same analysis of 401ks done here:

Joe Ponzio's F Wall Street

And he agrees with me, invest in index funds with low overhead.

Saturday, August 18, 2007

6 Years!

6 years ago Mary and I tied the knot on a beautiful August day at Belknap (holy cow, they have a web site). Today we went out to a movie (Once - thumbs up) to celebrate.

Hoping the next 6 years are just as good (or even better).


Three weeks of updates here.
Today I took a nice ride toward Philomath, cut across Bald Hill, and back over Witham Hill. 45 min

Last week, Simone and I took a beautiful ride on a Friday (was working from home for the first time @ Mentor). 45 min

And the week before we rode downtown as a family and played in the fountain. Lovely time had by all.

Thursday, August 16, 2007

Pollution is Bad

Ok, this is kind of a 'no duh' article, but to carry any weight with the "the market solves everything" crowd, you need to quantify how much of an impact bad environmental policies have. Turns out that nearly half the deaths world wide are caused by pollution. The researchers are from Cornell, so it must be true (Go Big Red!!!!), but even if they're off by a factor of 2 or 4, that's still a heck of a lot of deaths attributed to pollution.

Check it out: ScienceDaily: Pollution Causes 40 Percent Of Deaths Worldwide, Study Finds

Wednesday, August 08, 2007

Do Biofuels Mean Inexpensive Food Is a Thing of the Past?

Ok, so it seems I was a bit wrong about the connection between farm subsidies and food prices. A new study is out that explains things in plain English: Do Biofuels Mean Inexpensive Food Is a Thing of the Past?

Tuesday, August 07, 2007

Nine in 10 Americans say ban texting while driving - Yahoo! News

There are studies out there showing that talking on the phone while driving is equivalent to driving drunk. Some states are legislating against driving while talking on the phone. Turns out people are pretty unanimous in wanting texting while driving to be banned.

What I find ironic about all this is that almost everyone you talk to seems to agree with the above statements, but will say that they think they're an exception to the rule. "Oh - yeah, that's true, but I'm really careful when I'm talking on the phone."

Ha ha ha, right.

I'll go on the record and say I'm sure I'm not as safe when I'm talking on the phone while driving.

Nice Math Proof

I was never very good at math proofs (I could do math classes, but I'm sure I never came up with anything that wasn't an answer to a textbook question). This proof is pretty neat in that it's solving something relatively complicated, but the math works out so beautifully.

Polymathematics: Trekking Into the Desert

The New Math Of Global Warming

The math geek in me + the environmentalist just can't resist this set of slides:

The New Math Of Global Warming