Elliott C. Back: Internet & Technology

Bye bye, Amazon.com!

Posted in Computers & Technology,Family,Friends by Elliott Back on August 19th, 2005.

Today was my last day at Amazon.com. I finished up my project, made sure the documentation was all in place, and sent some farewell emails. Then at the end of the day when all my coworkers told me to go home, I turned in my badge(s), laptop, and other miscellaneous stuffs and took off. I had a great time working there. The team was great, and I think for a first internship I really learned a lot about how corporate work in software engineering is done. Now I just need to update my resume, cross my fingers, and hope they call me back for another shot!

Update:

Funny thing–a guy just emailed me and asked:

I was looking around about amazon internships and stumbled onto your blog. I just wanted to e-mail
you and see if you’d be willing to let me know a little about the experience. I would really like to intern
there next summer, although I am not sure I will have enough experience to pass the interview. How did
you like it? How was life outside the building? Look forward to hearing back from you :)

I sent him the following more detailed note about my summer:

Today was my last day working at Amazon.com, but I loved every minute of it. My team was great! I worked for the Procurement team, which is responsible for buying all of the products that Amazon sells from their respective vendors. My job over the summer was to write a metrics framework for evaluating group progress towards business goals. I eventually created a start-to-finish solution that took raw data and after some work gave you metrics numbers. The metrics framework had to be scalable, extendable, sturdy, and fast.

Outside the Amazon buildings (there are four in Seattle), there’s a lot to do. Just the other day I went out with a friend from Cornell and a bunch of other people I didn’t know, and a couple Seattle party crashers for dinner and afterparty. There shouldn’t be any lack of fun.

From your email I would assume you’re a rising sophomore? What classes have you taken? Read this article here:

elliottback.com/wp/archives/2005/08/04/how-to-hire-the-best/

Then tell me, at the bottom, if you can write good versions of strstr, is_anagram, and atoi in at least two of c, c++, c#, java, lisp, or perl.

It’s interesting that young people are so worried about interviews, and preparing for them. I’m not going to give away any interview secrets, but not because there actually are any. Rather, you just need to be competent, self-confident, experienced, and winsome!

How to hire the best

Posted in Computers & Technology,Deals & Savings,Education,Science by Elliott Back on August 4th, 2005.

The infamous Mark Jen has posted his take on Joel’s hiring essay. Basically, Joel makes the argument that hiring the absolute best programmers is the best thing for a software company, because superb programmers are investments that more than pay for themselves. It’s basically an argument of averages–everyone can build software, but the few companies that can build great software are few and noticeable. To give a concrete example:

When everyone is making ugly square mp3 players, a stylish mp3 player with rounded edges and careful design will be king.

A coworker and I were discussing this yesterday and today. Obviously, when hiring candidates for positions, we want good ones. However, we go beyond the code of hiring the best of the best–we actually do what we say here. If there’s a candidate that you can’t respect as an equal or greater skill, a candidate who doesn’t appear to possess basic skills, or who is any way lacking is simply not good enough. A company shouldn’t hire someone that limps over the corporate minimum bar to fill a position.

Until there’s someone you find who can leap over a bar twice as high with ease, you don’t want to fill that position. So, don’t make your interviews easy. If you’re doing an interview, make it moderately challenging for someone of your level. Include a “screener” technical question that you think anyone with similar skills and general knowledge should be able to easily answer. Some good interview question choices include:

  • Tell me if there are two numbers in an array that sum to x
  • How do hashmaps work? How would you hash a string?
  • Generate permutations of x
  • Reverse a c string
  • Write a tree to linked-list function
  • Write an efficient recursive function to garbage collect memory
  • Describe how a compiler works.
  • Give an overview of DNS, TCP, filesystems, process scheduling, pipelining, or some other high-level CS topic

Once you’ve passed them through an easy coding question and another general question, you can start to interview them based on their resume, because you know that they’ve met a minimum requirement to do their job. If you’re impressed at the end, hire them. Otherwise, why bother? The negative cost of hiring someone who doesn’t impress you and your teammates is greater than the benefit of filling that vacant position.

Update:

I just noticed Shelly’s comment on this old hiring posts. It reads:

That is the worst interview question I’ve heard of. It is guaranteed to discriminate in favor of a certain type of developer, and not necessarily a good one.

No wonder you people can’t find good engineers. You don’t know how to interview worth a damn. You’re looking for code monkeys, but interviewing engineers. I had a feeling this was what was happening when I talked with someone who interviewed at Microsoft and the same thing happened. Absolutely silly questions-and yes, very biased. Your HR department has done a poor job.

Asking somebody how to do code the strstr function. I’d hire the person who looked at you like you were daft and said, “I’d use the function built into the language. Now what _job_ is it you want me to do?”

I just have to add to the conversation, and point out that asking for an interviewee to code any basic function like that is industry best practice. It’s the absolute lowest bar. Sure, if you actually can code, then these questions will seem ridiculous, but otherwise? You don’t hire a programmer who can’t write code, so you need to see if they can write code. Shelley would rather have interviews, I guess, that go like this:

Interviewer: So, you can code basic functions, do recursion, handle arrays, right?
Shelley: You bet I can! And more!
Interviewer: Fantastic–just had to check.
Shelley: Let’s move onto more interesting things…

Nope, it doesn’t work like that, because we can’t trust you to tell us the truth. Your abilities have to be assessed. Unfortunately, in another comment, Shelley goes on to say:

Any interview that resorts to having the interviewee code is a bad interview. Shows that your staff is too inexperienced to know how to interview.

She also makes a big hand-waving pseudoscientific argument about long term / short term memory with regards to coding. See, the thing is, the most basic part of this kind of job description is writing code. Sure, we create systems, do designs, model databases, and create relational object oriented structures, but then a software developer sits down and implements. Writes code. You wouldn’t believe how many people cannot write a function to reverse the elements of an array, in any language.

Here’s your challenge:

O readers, show your might. I’m going on vacation this weekend, but when I come back, I want efficient implementations of strstr, is_anagram, atoi for any base, and edit_distance. Log the time it takes you to write each one, too. Remember–these are basic interview “crawl over the bar” questions…