.comment-link {margin-left:.6em;}

Saturday, August 23, 2008

The pronunciation of "Beijing"

As someone who spent nearly a year living in Beijing - and not being Chinese, although married to a wonderful lady from that part of the world - I've been annoyed at the tendency to pronounce "Beijing" like "Beige-Ing". It is (basically) "Bay-Jing", with the second syllable starting with a hard "J" like "Juice", versus the drawled "Ge" in "Beige".

One would think that Bob Costas would have figured this out by now...

Friday, August 22, 2008

On Software Tools

In my new job, I'm in a largely Java shop for the first time. I'll be doing a "query cache accelerator" for them fairly soon, which will be done in C...

Anyway, one thing that I'm now highly exposed to is the Java world's proliferation of software tools. As a guy who figured that 20+ year old tools like make, vi, gdb, gprof, and purify are the cat's meow, it's hard to deal with tools that change every six months. Also, I hate wasting time learning the fiddly idiosyncrasies of yet another bunch of gooey-licious tools, who's main "advantage" over standbys like make is primarily their GUIness.

But, there we are. And I'm stuck with them, I suppose. The one thing I'm insisting on is that we pick a suite of tools, do all the customization we need to do, and stick with them and not change the world every few months as new tools appear.

I've always figured that software tools are like lawyers: you need to know a few good ones well for various purposes, but you don't want them to get in the way of living your life or doing your job.

Wednesday, August 06, 2008

Thoughts on "Coding Interviews"

In my job search, I was asked to write code in a couple of interviews. Personally, I don't like asking coding questions in interviews, and if I have a question about a programmer's ability, I'll use a simple programming test that's emailed to them a couple of days before - and ask them to explain their code in the interview.

For me, the problems with interview code questions are the following:

1. It's a completely weird environment. No computer, no compiler, and extremely vague requirements. Few programmers do well in this environment.

2. Lots of room for silly "gotcha" pickiness that has little to do with actual programming skill.

3. The programming problem often involves too much code for a few minutes.

As an interviewee, my strategy for programming questions was the following:

0. Get the requirements, and state any assumptions. If you're wondering about a definition or something, go ahead and ask - it's better to do this than to get "gotcha'ed". Frankly, I also like to use the requirements discussion to "run out the clock" so that the coding lasts only a few minutes.

An aside: if the interviewer gets impatient at this point, they're probably not very good programmers themselves, or they're very junior.

1. Set up the data structures.

2. Discuss the main modules/classes/APIs you expect to use. Don't get hung up on the details of library calls or whatever; in real life, you'd look these up anyway, so go ahead and say so.

3. Only code the "top level" function that implements the main algorithm, using the data structures and APIs you outlined above. Bury stuff that's tedious and that takes a lot of code behind a module that you discuss but don't write, unless the interviewer insists.

Also, up front, state that you're explicitly skipping error conditions and error handling, but discuss how you'd code error handling if you were doing this "for real".

4. If you get gotcha'ed, go ahead and make the corrections. Don't get flustered.

If you expect to have this sort of "live programming" asked in an interview, it may be useful to have a practice session where you sit in front of a "friendly" and write some code on a piece of paper so you get used to the environment.

Technology observations from my job search

For all that job searching is a pain in the butt, it gives you a chance to see what companies are doing and where their "pain points" are. Some observations from my search:

1. Companies are drowning in data, particularly small ones that can't afford to build a fancy glass house for racks of servers running Oracle. There's a golden opportunity here.

2. A few players are going after this opportunity, but they seem focused on the top of the market. This is probably reasonable from a business perspective, but my impression is that bowie-knives.com needs high performance stuff as much as Google.

3. The DB market may well end up splitting in two: high-performance query answering and search, and highly reliable archival and storage. The latter interferes with the former, and several places where I was interviewing definitely want high-performance query answering. (I'm building one of these puppies for my new company.)

4. There is lots of other movement going on in databases. With the end of Moore's Law, and data and the need for high-speed data processing growing quickly, new db architectures are appearing. Several companies are building various forms of "database appliances", and some new hardware stuff may help here.

5. Programming is about to get a whole lot harder as computer hardware changes intrude on programming in a way they haven't for at least 20 years. This is good for us old fogies who like hard "edge condition" problems, but Joe Java, who lives in a world where abstractions hide all the fun stuff, may have a hard time adjusting.

I saw this in a couple of companies: a bunch of smart young guys, steeped in the latest languages and alphabet-soup "skills", wondering how to get a factor of 100 performance speedup in their complex application without buying 100x more hardware. It can be done, but commodity approaches probably won't do it.

Adventures in job hunting...

My company went belly-up in June, and I collected my last paycheck on June 30. After that came the Great Job Search, which ended this week.

A bit about me in advance: I've been a database engine developer for the past 20 years, and work as an individual contributor with some management responsibilities, and typically work at a "director" level (ie, reports to VP Eng) in a small company.

Some observations from the job search:

o A surprisingly large number of technology companies use pedantic "employment applications" of the sort one expects to see at Burger King. An experienced professional has a very different life history than these applications are built for. One example: they have trivial notions of compensation - they only ask for base salary, without the ability to enter bonus information, profit sharing, stock options, etc.

2. I had to rewrite my resume a couple of times to get it right. I had friends proofread it and this helped greatly. I maintained a MS Word version of my resume as well as a text version.

4. I worked with several recruiters. Two of them were "active" while the others were duds. I ended up accepting an offer from a company the most active recruiter found.

5. Interviewing is a skill that needs practice. I blew my first couple of phone interviews until I analyzed them and realized I talked too much about my last company and not enough about what I could do for them. A good interview is where you ask more questions than the interviewer.

6. Again with interviewing: I accepted a couple of "practice" interviews so I could hone my interview technique.

7. A couple of interviews involved writing code in front of the interviewer. I did well here, but I always hated this practice, especially for senior people. I always preferred offline coding tests to scrawling code on paper in front of someone trying to play gotcha. More on this later...

Anyway, enough of the job search. More on it later...

This page is powered by Blogger. Isn't yours?