Braindump after interviews at Microsoft

February 12, 2010

I interviewed onsite at Microsoft this week. Here’s an assortment of thoughts and lessons learned, in roughly chronological order.

I flew in early on Monday and left late on Wednesday so I could spend some time exploring Seattle. This was a good move.

Day One: Arrival and Exploring Seattle

Microsoft provided a rental car that I picked up at Sea-Tac airport. At the rental desk I met and rapidly befriended another MS candidate who was interviewing for a SDET position. We both got Nissan Versas—a fun, small car with good kick and very tight brakes.

I drove straight to the hotel. First lesson, to be observed again and again over the next couple days: Seattle’s road signage is out to get you. It is actually malicious. I am imagining some angry, bitter and crazed road sign designer cackling in a basement, carefully crafting terrible navigational design. I know I’m not the only who thinks this.

Microsoft put me up at the Hilton in Bellevue. It’s a gorgeous place, and unlike some pricey hotels I’ve stayed at, the staff were actually friendly and helpful. The guy at the desk loaded me up with exploration recommendations, maps, and coupons. In the hotel, I met another Microsoft candidate who was hoping to join the Bing team.

We three candidates drove downtown to grab lunch at Etta in Pike Place market. Tasty, warm and cozy food with a wonderful server. The other two returned to the hotel, and I went to catch a boat tour of the harbor. Unfortunately the Argosy boat tours only run once a day in the winter, and I had missed the day’s trip. I wandered around downtown, saw a nice sunset, and went back to the hotel.

I was determined to have some pacific coast seafood, so I met up with one my new friends and we went to Sea Star in Bellevue. Bellevue doesn’t seem to have any nightlife, but it’s got good restaurants. The hotel gave us as coupon for a free appetizer. Lesson: Tell the hotel your plans, they might have good suggestions or freebies.

One thing I should mention: Microsoft provided a food budget of around $75 a day (15/20/40). I thought it was extravagant at first, but once I started eating around the area I realized that the restaurant costs in the area made it just reasonable. Stuff is just expensive out there…

Day Two: Microsoft

I had an overpriced breakfast at the hotel and then headed out to the Microsoft campus in Redmond for the day.

Lesson one: The traffic is awful on the way from Bellevue to Redmond. Google Maps and Bing both measured the trip at 8 minutes. It took me over 30. If I end up at Microsoft, I’m going to have to be very careful about where I live because I do not want to deal with that every day.

Lesson two: I needed to find my way to Building 111, where the Microsoft recruiters live. It turns out that Building 111 was bought from Honeywell, and it’s near a bunch of other Honeywell buildings, which confused this poor guy who was looking for signs that said “Microsoft.”

The lobby of Building 111 is tricked out. You’d think you’d just walked into a 23rd century spaceship. Multicolored modern furniture; a few new HP TouchSmart computers; young, jovial, smiling receptionists and a concierge; a Starbucks coffee machine.

I met my recruiter, who told me I’d be interviewing in the Windows division. It also turned out that GMail had spam-filtered an email she had sent me. (Eeeek!)

The Microsoft campus is enormous. I can’t communicate the scale of it. It’s a city. You can’t just walk from building to building—they have a fleet of Toyota Priuses to chauffeur people from place to place. (The brakes worked fine, thankyouverymuch.) My recruiter ordered a ride to send me to my interview-building for the day.

The first interview was straight-out technical. “Split a linked list into elements above and below the average of the list.” I did a simple two-pass solution, and we spent most of the time talking about coding practices and API design. I used an assert to crash if the linked-list was NULL, and my interviewer explained why it would be better not to fail in this case.

My second interview was a lunch interview. We walked over to a building that had a cafe—Good food, but nothing to compete with Facebook’s. After lunch, we came back to sketch an algorithm: Print the numbers 1..n^2 in a spiral, with 1 in the center and going outward.

My third interview was a “soft skills” interview. We talked about passions, tools, programming languages, some past experiences and that sort of thing.

My fourth interview was mostly technical. After a few “soft” questions we talked about an efficient algorithm to find the common ancestor of two nodes in a binary search tree.

My fifth interview felt like I was meeting the End Boss. It was with the manager of the team—a guy who had more than twenty years of experience at Microsoft. The problem was to print the permutations of a C string. I’ve been doing all sorts of functional programming lately, so I sketched an immutable-string recursive version in Haskell, with the intention of translating to C afterward. This was a brutally bad idea, because 1) String manipulation is a pain in C and 2) Of course the way to do it in C takes advantage of mutability. So I started off in a completely-wrong mindset.

One lesson across the interviews: Say what you want about language-independent interview questions, these guys wanted C.

I returned to Building 111, chatted a bit with the recruiter to debrief the day, and went back to the hotel.

I was happy that they didn’t waste any time telling me “pitching” Microsoft. At least one other large company treated me like I lived in a cave and felt it necessary to go over the breadth and depth of their businesses. Microsoft clearly respected my intelligence enough to know that I know about them. Also, thankfully there was no hint at any point of their brutally-condescending “Hey Genius” recruiting marketing materials. That was a relief.

For dinner I went to Flo in Bellevue for (phenomenal) sushi. I met a friend-of-a-friend there… a guy my age who has been at Microsoft for a couple years. It’s very refreshing to get an unbiased, straight-dope opinion from an insider about the good and bad. I can’t speak highly enough about chatting with someone like this in a casual setting. It made me feel much more informed and comfortable. Interviewers and recruiters seem to think it’s helpful not to talk about negatives, but since I know there must be negatives, instead it just leaves me feeling like I’m in for some nasty surprises. So hearing about some negatives counterintuitively lets me feel better about a place.

Day Three: Explorations Part Two

Another day of exploration, this time with planning:

  • Washington Park Arboretum, Japanese Tea Garden. The gardens were closed for the winter, unfortunately.
  • Seattle Public Library. Colossal, gorgeous library, well worth a short visit.
  • My first Mocha Diablo: Coffee with cayenne—a warming, delicious idea.
  • Argosy cruise. Some fun facts:
    • Seattle gets less rain volume than most other coastal cities, but it’s spread out over nine months of overcast, drizzly days.
    • Seattle has one boat per ten residents.
    • “Seattle” is the name of the Native chief who helped the settlers figure out where to build the port city.
    • The giant orange cranes in the harbor can load or unload one 150-ton shipping container every sixty to ninety seconds.
  • Wandering around the ritzy Queen Anne neighbourhood and stellar views from Kerry park. Had a Mocha Sevilla: Coffee with chocolate and orange rinds.

Lesson: Toronto’s coffee is easily as good as Seattle’s.

I went back to the airport in the evening, hopped to Vancouver and then took the red-eye back to Toronto. Lesson learned: No more red-eyes. I couldn’t sleep a wink, and made up for it with a 14-hour sleep last night.

All in all it was a good trip. I was impressed at every turn with Microsoft’s environment, professionalism and friendliness. I have to give it to them, they’re good at this stuff.


Mirvish/TicketKing Lies About Security

February 1, 2010

Not cool in this geek’s books.


“Relevant After” for todo lists

January 26, 2010
Andrew and I used FogBugz to organize ourselves leading up to our YC interviews last fall. I just filled out a customer survey; here’s what I told them for “Missing Features”:
I’ve wanted this from every project-management system I’ve ever used: A “Relevant after” field that hides items from all default views until a trigger (e.g. date, or other task completion).
This would let me brainstorm todo items without being annoyed by clutter that isn’t relevant yet.
For example, I handed in a draft of my Master’s thesis on Monday afternoon. My second reader told me, “OK, I’ll read it Wednesday morning and get back to you.”
As of that moment, I have a new todo item: Either deal with her feedback or remind her that I need her feedback. This new task is not relevant to me until Wednesday except when planning other tasks to be done that day.  And I know how you feel about software that gets in your face with irrelevant shit.

English is hard

January 13, 2010

I asked my sister and father for help on a point of grammar. Each found a separate flaw in my example sentence.

Where does an adult go to improve his writing?


The Roles of Journals

January 8, 2010

Academic journal publications are the lifeblood of science: The medium for serious communication, the marker of career success, and moderator of scientific integrity. Modern technology is disrupting the funding model that has supported the system for hundreds of years. As things change, it becomes worthwhile to consider the various functions journals perform. Only with new understanding can we identify the pieces we shall need to rebuild if the established structures cannot adapt.

Before the Internet, printing and distributing physical documents was sufficiently complicated to warrant specialized organizations. It was natural to capture the value of this service by asking readers to pay. These subscriptions effectively subsidized other journal services.

Now, printing and distribution are cheap commodities. For pennies, a scientist can make work available to every interested reader. This undermines the subscription business model, and it isn’t clear how existing journals can measure or capture the value of their other jobs.

To stave off collapse, journal publishers now fight bitterly to keep their publications closed to all but paying subscribers. This pits them directly against their contributing authors, who favour openness on principle and on the pragmatic realization that open publication means more citation.

Let us explore some of the unfunded roles journals play:

Editing: Journal-funded editors raise the basic quality of writing in scientific publication, filtering out spelling and grammatical errors.

Coordination of peer review: Journals arrange for qualified scientists to review others’ work, guaranteeing authors a source of feedback that is sometimes even useful.

Formalization of discussion: Journals provide a generally-accepted forum for comments on a paper and a system of retraction for severe flaws discovered after publication.

Reputation assignment: Within every scientific subfield, there is a generally-understood status hierarchy of journals. Publication in prestigious journals bestows honor on a paper, its authors, and their institutions. In some fields and journals, the order of the author list tweaks this assignment of credit.

Some fields formalize this system into a mathematical formula in an attempt to fairly measure the impact of a scientist, institution or journal.

Attention assignment: Journals regularly aggregate related content in a field, focusing the attention of interested parties. The structure of journal articles permits sophisticated searches of the literature.

Durability assurance: Journal publications are archived reliably, making it rare for a piece of work to become completely inaccessible.

Canonical citation: The scientific community generally agrees on how to cite articles from journals. A journal article citation is sufficient for a reader to uniquely identify the work being discussed.

Any serious effort to replace or fix journals will need to consider more than just the obvious, formal processes. The unwritten social roles and subtle benefits must not be overlooked.


The New Airport Security

January 6, 2010

Rory and Aran fly to San Jose.

We pack checked baggage only, knowing we won’t be allowed to carry much on.

The airport is empty. Flying on Wednesday afternoon has its perks.

It takes a while to figure out that flying NorthWest Airlines means checking in at Delta.

We breeze through checkin. I had a cheerful, friendly agent who helped me through checkin and waived my checked baggage fee of $20. Rory was not so lucky, with a surly woman who gave no such favour.

Customs had a couple agents working and no line. My agent found out I was interviewing at Yahoo!, so he asked me why they should hire me instead of some other candidate.

The usual X-Ray screening station was overstaffed. We didn’t wait, and the agents with nothing to do were joking around.

Beyond usual security, there was a new station staffed with a dozen RCMP men and women. They were doing full pat-down searches and inspection of electronics. They were way more cheerful than the usual security types. I guess they still had their souls. We cracked jokes about my trying to earn a pat down from one of the cute female officers. (No luck.)

Total time from entering the airport to reaching my gate: Less than one hour.


Language Monoliths

December 30, 2009

“Write programs that do one thing and do it well.”

The Little Computer Scientist appreciates simple design. To design systems, design teams of cooperating specialists. To keep warm, wear a coat on your body, scarf on your neck, boots on your feet, and mittens on your hands. Don’t wear a seamless fullbody wintersuit—it will be hard to go pee.

Computer people mostly get it. We write special-purpose programs and break them down into special purpose pieces. We try not to make mittens that spontaneously unravel when you change your hat.

We get it, that is, until we build our programming languages.

Programmers have gotten used to the idea that choosing a programming language is a big important decision. Why? Because you can’t just choose a syntax expressing a few core abstractions. For each language, only a handful of editors are reasonable. There’s a standard library to mentally index. There’s an incumbent community of developers, and they have a philosophy of software development. There are idioms to learn and implicit “you’re a bad programmer unless you do it this way” rules. There’s a generally accepted tao of quality assurance. There’s a small council of key thought leaders and They have RSS feeds. There’s a preferred build tool, a deployment tool, and the non-standard-library standard library, like CPAN or Ruby Gems or PyPI.

Now, there are many valid forces that push things to be this way. The people who go with the grain aren’t dumb.  But we should recognize the problem and ensuing opportunities here. Monoliths are bad. Programming languages are intrinsically monolithic. Working to oppose monolithic forces is good.

Many projects do it right. XML, JSON, Protocol Buffers and Avro tackle interlanguage data representation: programmers should use them for making their data objects. Tools like CouchDB with language-agnostic HTTP interfaces are winners. CoffeeScript puts a new syntax on JavaScript: A worthy experiment. Scala and Closure compile to the JVM: There’s little excuse for language designers building VMs any more.

The Little Computer Scientist hopes to see more work breaking languages down. Make them smaller, less monolithic, more flexible. Compose them of special-purpose pieces. Expose the AST as a protobuf. Give a meta-circular interpreter and little compiler so that building correct new implementations is a day’s work. Isolate the syntax as much as possible so it’s easy to make correct highlighting editors, pretty printers and style-checkers.

Decouple, specialize, cooperate. One thing done well is a good thing.


The Death of JavaScript

December 24, 2009

Jash Kenas released CoffeeScript today, a programming language that compiles to human-readable JavaScript.

It addresses a real need, exemplified by this image:

JavaScript was designed quickly and extended by dumb committees. It’s a messy language with a potent core. CoffeeScript aims give programmers the core without the mess. It’s nice. It’s broken in many of the same ways as JavaScript, because it’s just syntactic sugar on JavaScript, and JavaScript’s problems run deeper than syntax. But it can grow to fix these.

CoffeeScript and languages like it are the reason why JavaScript is going to die. Steve Yegge thinks JavaScript is the next big language, poised to take over the programming world. I disagree.

CoffeeScript is a baby in the growing family of languages that compile to JavaScript. These include Scheme, Hop, Java (via GWT), Smalltalk (via Clamato) and Objective-J. These languages are good. A programming language is a programmer’s main tool—and is thus the most rewarding place for improvement.

Imagine you can quantify the productivity of programmer using JavaScript. Over time, everything’s getting better: Libraries, JavaScript VMs, tools like Google Closure. JavaScript programmers are getting better at writing more better faster code as time goes on. Hurray!

There is another productivity curve. This is the curve of compiles-to-JavaScript language users. In this world, you can increase your productivity by using better languages.

Here’s the question: Does the compiles-to-JavaScript curve intersect the raw JavaScript curve anytime soon? If not, Steve Yegge is right. JavaScript wins as long as web browsers are the dominant application platform. But if it does… if it has happened already, even… then JavaScript as a human-use language will die, relegated to being a target language for compilers, like assembly code.

Here’s a brainstorm of some implications.

  • The ECMAScript committee should stop making up features to make JavaScript easier on programmers, and start changing features to make JavaScript more of a good target language.
  • The V8, SpiderMonkey, Carakan and other JavaScript implementations should start benchmarking on workloads that come out of code generators. (Actually, V8 already does this. They should do it more.)
  • The folks working on server-side JavaScript frameworks should just stop and go lie down, for the love of god.
  • Finally, future HTML standards should make allowances for JavaScript to be replaced. Something along the lines of <script language="CoffeeScript" compiler="coffee-script.js">code</script> could mean: Run code if this browser understands CoffeeScript natively. Otherwise, load coffee-script.js, find the compile function inside, call compile(code), and eval the result as JavaScript. I say this not as a proposal of how the forward-compatibility should work (I can think of at least one other way) but to make the point that we should be talking about it.

Research Ideas

December 17, 2009

I’m planning Project February: What Aran Does When His Master’s Is Done. I’ve got a startup on standby, and interviews with companies large and small.

One possibility to stay in academia for a PhD. If I were to do this, I would need a research direction. This would then influence who I’d court as a supervisor (Greg is leaving for industry) and therefore where I’d go to school.

I could stay at the University of Toronto (I’m already in. I love it here. Path of least resistance.) or look elsewhere and aim for a later start date. Washington is on the up and up. Stanford is the de facto Silicon Valley university. It would be a good fit for my entrepreneurial ambitions. And I follow the work of researchers at many other UK and American universities.

Of course, there’s no guarantee I could get in to these places. I have no connections, no reputation, no GRE scores and currently no publication record.

In any case, the first step is to figure out if I want to do more research. Since I’m brainstorming anyway, I figure I’d post my thoughts.

Dataflow languages

Dataflow languages don’t just separate what from how, as declarative languages do, they separate what and how from when. Spreadsheets are dataflow, and there are a couple dataflow languages and libraries, but I don’t feel dataflow programming as a general-purpose paradigm has gotten the attention it deserves. Dataflow becomes especially interesting when the execution is distributed and operations are expensive, since there are all sorts of wonderful scheduling problems and optimization opportunities.

Performance Types

Traditional separation of interface from implementation deals only with functionality. But sometimes, we want to specify performance characteristics in an interface. Take real-time programming or large-scale programming for example. What’s a good language for describing performance specifications? Can we encode it into a type system?

A/B User Interfaces

Modern web user interfaces are optimized on-the-fly. Can we make better tools for UI designers to manage hundreds of variations of a UI?

Algorithmic Information Theory and Machine Learning

Algorithmic Information Theory gives us a quantitative way of thinking about intelligence. Can we learn new things by bringing this view to bear on machine learning? Example research project: Define a programming language with boolean strings as values, do learning by highly-optimized program generation.

ESE

I find it easy to come up with ideas in Empirical Software Engineering, so there’s a disproportionate number of these below.

Tool-aware development

We’re all familiar with software quality attributes like performance, readability, security and so on. And we’re aware of good coding practices like mnemonic variable names and short functions. There’s a new quality attribute in town, though, and as far as I know, nobody’s talking about it yet.

Modern software engineers use a variety of tools, such as version control systems. In the presence of these tools, certain constructs become worse.

For example, in C, you might see a construct like

#define some_flag_1 0x0001
#define some_flag_2 0x0002
#define some_flag_3 0x0004

Nothing wrong with this on the surface, but in the presence of concurrent development, version control and automerges, this code is a hotspot for a merge error if two programmers add flags.

As another example,

y = f(x);
if(y < z)

is more friendly to someone stepping through a debugger than

if(f(x) < z)

because most debuggers only let you step through statements, not expressions.

One last example: On some teams, everyone uses the same tools. On others, everyone uses different tools. Some coding practices are annoying to deal with in certain development environments. Homogeneous tool environments call for different practices than heterogeneous environments. I believe research is warranted into the ways our coding practices should change based on the development context.

Tool-aware languages

How do you design a programming language differently when you know the developer won’t just have a text editor, but will have a debugger, static checker, syntax highlighter, unit test suite, doctests, version control system, code reviews and more?

Software Development Practice Interactions

Nobody uses code reviews or unit tests or pair programming or whatever in isolation. And not all bugs are equally important. Which practices find which bugs? And how do they overlap?

Empirical Bug Prioritization

Modern software is shipped rife with known bugs. Project managers prioritize bugs and optimize for “good-enough” quality in a largely ad-hoc way. Can we offer something better than “estimated number of affected users * expected annoyance” for prioritization? Are there unpublished best practices to be discovered and optimized?

Technique Drills for Programmers

Technique drills are used in just about every other skilled human activity. Why not programming?

Bug introduction in detail

How far can we push Ko’s framework on error introduction? Can we do a better job of putting programmers under the microscope and really zoom in on what happens when bugs are introduced?

Syntax Pragmatics

I’m pretty sure from my work on DSLs that syntax matters. Can I drop another level of abstraction and find out why? This would be an investigation of the connections between semiotics, programming languages and information visualization.

A Language for Empirical Programming Language Design

If we want to learn about the usability of programming language features, we’d like to be able to turn features on and off. Most languages are designed to be as good as possible for real-world use. What about a language with dozens of syntactic and semantic knobs just for experimenting on features in isolation?


What do you want?

November 6, 2009

I was asked today what I wanted in a job.

It was surprisingly difficult to answer.

I like achievable challenges. That’s obvious. But—getting some CSS to display just right on Internet Explorer 6 is an achievable challenge, but it’s not work I’ll enjoy. Crushing a hard bug is fun, but debugging code that should never have made it through review is not. Writing efficient code is fun. Dealing with low-level memory management, not-so-much. Type errors in loosely typed languages feel preventable. Not fun. Designing a good API: Fun. Dealing with legacy constraints: Not fun.

These days it’s popular to filter software engineers: Front-end or back-end? Applications or systems?

But this isn’t a key distinction for me. It doesn’t capture the essence of what I care about. I could be happy working on front-end or back-end code. I could be unhappy working on front-end or back-end code.

Now, moments after my interview ended, I’ve managed to figure out the answer…

Accidental complexity: Not fun. Intrinsic complexity: Fun.


On Mobile Phones and Driving

November 5, 2009

Worth repeating, from Jakob Nielsen’s excellent newsletter:

In an opinion poll, the New York Times asked whether Americans wanted to outlaw mobile phone use while driving:

> http://www.nytimes.com/2009/11/02/technology/02textingside.html

80% of respondents said that using a HAND-HELD cellphone while driving should be illegal.

But almost 90% said that it should be legal to talk on a HANDS-FREE cellphone.

Completely OPPOSITE INTUITIONS about the danger of these two ways of using a mobile phone. This despite the fact that all studies show that it’s EQUALLY DANGEROUS to use hands-free and hand-held mobile phones while driving.

Research has found that the danger comes from the cognitive distraction of carrying out a conversation with somebody who’s not in the car. The problem is not holding the phone with one hand while driving with the other. The problem is the conversation and the way it lays claim to limited cognitive resources.

This finding is completely counter-intuitive: how can it endanger your life to carry on a simple, everyday task like a conversation? The survey clearly demonstrates that people’s perception of danger is completely divorced from the actual danger.

When driving, you are piloting a power plant, and a single mistake will cause human beings to die. This is a task worthy of your full attention.


Job Interview Notes

November 4, 2009

A message I sent to the students of CSC 290 (Communication for Computer Scientists) following our class with practice job interviews.

Alexey said: “I wish I had not used `you know`, `er`, and `well` that often. But these words come out instinctively, as they give me time (a second or two) to think of what I am going to say next. Still, there must be other ways.

Here is a golden phrase to memorize when you need time to think about your answer for a question:

That’s a good question. Let me think for a moment so I can give you a really good answer.

You can also buy time by paraphrasing their question:

Just so I know exactly what you’re asking—Are you saying <your interpretation of their question>?

Of course, if you use one of these on a question that should be easy, you’ll seem dumb. And you probably can’t get away with using either more than once.

Yanshuai mentioned that he should have prepared a pitch for his computer vision project. In fact, you should prepare a pitch for every single item on your resume. You should also prepare pitches about your experiences in overcoming challenges or conflict, working in a team, dealing with difficult people, disagreeing with a superior or with your team, and so on.

You shouldn’t memorize your pitch, though. Instead, think about and jot notes about the importance of the project, the transferable skills you learned, and how it might relate to work at X.

Lots of interviewers also ask, “Tell me about yourself.” “Why do you want to work for X?” “Why should we hire you?” “Where do you see yourself in 5 years?” There is no excuse for stumbling on any of these questions. To answer them, remember: They are asking you to tell them about a personal quality or skill set. Lil gives an example: “I can multitask and meet difficult deadlines.  For example, when I was taking X course, I was also working on project Y, and had deadline W at work.  I was able to complete all these tasks by ___ and ___ resulting in ___.

George mentioned doing mock interviews with a friend. This is a great idea.

Leon said, “I practiced answering questions rather than exploring my experiences themselves. If I had another chance, I would have prepared differently by studying past experiences and situations carefully.”

This is an important point and applies to more than just job interviews. Once you have developed good foundational speaking skills, your best preparation is not canned answers or prepared words. Your preparation will be about becoming deeply comfortable with your material. Then the words will flow.

Reza asked, “Also knowing that the interview is short should I let him ask more questions?

While it is important to give complete answers, you should always leave the interviewer in control. In fact, you should carefully listen to the interviewer to get a sense of whether he or she wants you to take charge and talk a lot, or whether he or she would prefer to move things along.

In an interview, it may feel as if you should talk a lot, but in fact a big part of the game is listening to your interviewer (deeply listening—not just staying quiet while they talk.) You should listen actively—for example, paraphrase them and ask questions. Another one from Lil: “So you’re saying that the researcher wants you to organize data on 10,000 irradiated mice and you’re looking for a way to automate it:  Is that it? What are the resource constraints?

I should probably explain “deep listening” better. Here’s an attempt.

We learn as children that “listening” means not interrupting the other person.

“Active listening” is a skill that involves engaging the other person in a conversation to gain a clear understanding of what they are saying.

When I say “deep listening,” I mean listening with all your brainpower. It’s hard work. You’re not just trying to understand their words. You’re also analyzing: What are they saying between the lines? How does this person feel? What’s going on in the back of their mind? What are they like as a person? What’s important to them?”

Actually, if you do this, you won’t need to worry about eye contact or eager posture since it will come naturally.

Taking a step back, the best way to prepare for an interview has nothing to do with interview questions, practice, listening or public speaking skills. To prepare, you must build your resume. By that I don’t mean putting words on page. Build your resume means actively seeking out new experiences. Then you can put them on your resume. Joining and contributing to team projects boosts your leadership and teamwork credentials. Writing open-source code outside of class is one of the best ways to get new technical experiences.

And of course,

  • Smile
  • Make eye contact
  • Shake hands firmly
  • Sit up
  • Judo: Turn weakness into strength
  • Give complete answers
  • Demonstrate enthusiasm and confidence
  • Be specific

Most importantly:

  • Prepare
  • Listen to your interviewer

If you have other important comments that I’ve missed, please let me know.

Your loquacious TA,

Aran


Units 0.03 is out

October 31, 2009

Units 0.03 is on PyPI. It includes a bug fix (A litre is a cubic decimetre, not a cubic centimetre!). It also has patches for PyPy that let you run a Python interpreter with built-in support for quantity literals. With these patches you can type 239 cm * cm * cm + 0.502 L and it will do what you expect.


Improve your Java: Restrict public methods to interface implementations

October 29, 2009

Good programming is all about restriction and constraint. Most possible programs do nothing interesting. Type systems, unit tests, code reviews and all that jazz are just ways of throwing out uninteresting programs.

Here is a chart view.

There are many more broken programs that good ones.

Notice the thickness of the blue slice.

This realization is what makes me feel comfortable proposing that we, as programmers, should mostly be thinking about new ways we can restrict ourselves.

Here is one way you can restrict your Java (or other classical Object-Oriented) programs to make them better.

Aran’s Public Interface Implementation Rule: All public methods on a class should be implementations of some explicit interface.

See, Java is tricky, because interfaces are interfaces, but so are classes. When you expose public methods on a class that are not part of an interface, a user of the method must specify the class name on the left hand side:

YourClassThatsAlsoAnInterface p = new YourClassThatsAlsoAnInterface();

That means their code is now glued to your implementation. They might not like that.

It would be better if you let them code to an interface and substitute implementations as desired. Thus, don’t bother putting public methods on a class that aren’t implementations of an interface.

YourInterface p = new yourClassThatsJustAClass();
YourInterface p2 = new theirReimplementationOfYourClassThatsJustAClass();

Incidentally, this rule totally enables Joshua Bloch’s Effective Java, Item 34: Refer to objects by their interfaces.

As Zak points out, the tradeoff is that you may hurt some compiler optimizations. If you have benchmarks to prove that following this rule causes unacceptable performance degradation, you have my permission to ignore it. Thanks for asking.

Leave your thoughts in the comments.


A Hack for “Unknown or expired link”

October 28, 2009

You’re using a web site, you fill in a big long form, and, upon submitting, you get “Unknown or expired link.” Why does this happen? The short[1] explanation is that the web site gave you a hidden code to submit with your form, and while you were typing, your code expired. If you hit “Refresh” to get a new code, your browser will probably throw away the contents of your form. You’re lucky you can hit “Back” from the “Unknown or expired link” page.

What to do?

Choice number 1: Copy out your form contents, refresh the page, and paste the contents back in. Slow, boring and painful.

Choice number 2: Get a new code and edit your current page to use it. Fast and fun!

How to get a new code: Open a new browser window, go to the page with the form, use “View source”, find the form you were filling in, find the hidden field in the form with a weird value, and copy the strange value.

How to edit your current page to use it: Go to the window where you’ve filled in your form, pop open your DOM editor, find the weird hidden field, and replace its value with your new code. Now when you submit your form, it will be using a fresh code!

OK, so maybe it isn’t easy, but at least it’s fast.

[1]: The long explanation is that the web site is probably using a continuation-passing style for managing client-side state and it garbage-collected your form submission continuation. I didn’t think you wanted to know.


Follow

Get every new post delivered to your Inbox.

Join 3,342 other followers