I'm moving this blog to tumblr

I'm tired of blogger. It hasn't really improved since I started using it. You can now find my blog at:

http://blog.simonmathieu.com/

All the old posts have been imported.

New Job for a New Year

I've recently decided to leave my current position at VLAM Inc. where I was doing mostly computer vision related stuff in Python and C++.

My new gig is actually a contract that should last a few months for Yardstick Software. They are based in Edmonton, Alberta, but I'll be working remotely from Montreal. Yardstick specializes in testing and training software.

What I'll be doing

One of the best thing about this job (aside from the pay :p) is that I'm going back to Web development. I'll be working on adding new features to their next generation app which is written in Ruby on Rails.

I've been more or less out of the ruby scene for the past year, so I'm super excited about diving back in, see what has changed and reconnecting with the community.

So stay tune for future updates on Ruby, Rails, JavsScript, jQuery and other fun stuff.

Links to personal projects

It has been an eternity since I've updated my blog, so I decided it's time for an update.

I'll try to update more regularly from now on, but keep my posts short.

For now, I thought that posting links to two projects I'm currently working on would be a good start.

The first one is PyAlpha. For now, it's only a Python interpreter in your web browser, but it has numpy and scipy integrated. We're planning for more awesome features.

PyAlpha was started at Startupifier and won the first prize.

Easy Metric gives you the ability for keep track of any metric collected from your continuous build. We're talking about things like lines of code, code coverage or whatever else you need to track. Easy Metric gives you statistics and graphs about whatever you're keeping track of. All you need is a simple GET request to push more data to the Easy Metric server and you're done.

More to come on these projects as they mature.

The Google interns recruitment process

This is something I've been meaning to talk about for some time now. As I mentioned in a previous post, I'll be interning at Google this summer. I have been recruited by the JavaScript minimizer team for a 3 months internship in Mountain View.

Google is well known for their overly complex recruitment process. I think full times employees have to go through 6-8 interviews before being hire. I've seen detailed description on the web of the process for full timers, but never for interns. The most annoying thing about it was not knowing what is coming next. The recruiters seem to keep you in the dark and the engineers you talk to aren't really aware of the process for interns. So this is the story of how it happened for me.

Before I start, I need to mentioned that I applied twice before being selected. The first time, I got selected for the technicals interview but did not make the cut.

Applying

The first step is obviously applying. You need to do that online here. You are asked for a resume, a motivation letter and a transcript of you grades. This part is pretty standard, but keep in mind that Google receive tons and tons of resume. Yours needs to stand out. One of Google recruiter I talked to told me that he spends around 15 seconds on each resume on the first cut.

One thing they seem to insist on is Linux experience. Most of their developments are on Linux, so you should probably try to put emphasis on your Linux experiences.

Also, the "officials" Google programming languages are C/C++, Java and Python. If you have experience with any of those, make sure they are easy to spot on your resume.

The other thing you need to consider is when to apply. Google's recruitment is painfully slow. If, like me, you have fixed internship period set but your university, you need to apply at least 4-6 months before that period.

First Contact

Now, if you've done things right and, lets admit it, if you're lucky, you'll be contacted by a recruiter. The first time I applied, I had a screening interview where the recruiter asked me a few technical questions and asked me to grade my knowledge of Java, C++, Python, Algorithms and few other things from 1 to 10. The second time around the interviewer just scheduled me two interviews with engineers.

The technicals interviews

You'll have at least two technical interviews over the phone. The content of the interviews varies from interviewer to another, but here's a few tip. Google engineers love algorithms and data structures. Be ready for in depth questions about queues, binary trees, heaps, stacks and every other possible data structure.

You will also get at least one question where you will be require to code. Yes, over the phone. There first time I did it, I had to actually read my code out loud and the interviewer would type it on his end to test it. That's the interview that killed me. I wasn't ready for it and took a lot of time writing everything down before verbalizing the code. I wanted to be sure of giving a correct answer the first time around. That was a mistake. You only get 45 minutes per interviews, so if you spend 30 minutes on a single question, you won't have enough time to finish the interview.

Don't be afraid to discuss your solutions with the interviewer, they are interested to see how you think and how well you can communicate. They'll ofter lead you toward the solution. Also, don't over-think the problem. If there's a simple solution to the problem, give this one first. Sometime it will be enough, sometime the recruiter will ask "How would you optimize that?".

The second time I had to produce code was much better. The engineer shared a Google Doc with me so I could write the code in it. I don't know if it's standard practice now, but it's much easier this way.

I can't really go into details about the interviews because they asked me to keep the content confidential. Anyhow, I don't think knowing the exact questions I was asked would help you, just be ready for anything.

More interviews

After the first two interviews, I did not get any feedback for a couple of weeks. After this period, my recruiter contacted me via emails and scheduled me a third interview. Her email basically said to be ready to answer technical questions and questions regarding my past experience.

Now, you need to understand that interviewing at Google is a very stressful thing. I spent a lot of time reviewing algorithms and data structure for this third interview thinking that if I had made it that far, I really did not want to blow it. It turns out that wasn't really needed.

The interviewer was my future boss. He basically started the interview saying "Somebody probably told you already, but you have pretty much a guaranteed job at Google". Nobody had. I wish they had, it would have save me from a lot of unnecessary stress.

The third and subsequent interviews are, from what I understand, basically just a way of finding a team you'll fit in. You'll be asked questions about you interests and evaluated on things more specific to the team. My interview was mostly Java, JavaScript and compiler questions. The interviewer described the team and left me plenty of time for questions.

I said I was interested by the team and got a job offer within a week.

Getting ready

This is the boring and tedious part of the process. I needed a J-1 visa to work in the United State. This mean plenty of unclear government form to fill in, a background check and various fees to pay to different authorities (Google will reimburse me for those).

Google don't pay for a plane ticket or moving expenses directly, but they give you a very generous relocation package (I mean REALLY generous). The most difficult thing was finding a place to live, but I managed to find something that seems really good on Craigslist.


Last words

This is how it happened for me. I hope this prove useful for future interns and interesting for the rest of you. I'll be starting my internship on May 4 and will keep you posted on what it's like working for the big G.

Auto-completion for IRB

As it turns out, it's really easy to add auto-completion to IRB. Just add the following lines to your ~/.irbrc file.

require 'irb/completion'
ARGV.concat [ "--readline", "--prompt-mode", "simple" ]

I wonder why this is not on by default.

JavaScript: The Good Parts

I recently watch a very interesting Google Tech Talk by Douglas Crockford, an influential JavaScript evangelist and writer. For all of you JavaScript devs out there, I strongly suggest you spare an hour to listen to this really amazing talk.



The talk, JavaScript the good parts is basically an excerpt of the speaker's book.

Although Crockford admits there are problems with JavaScript, even very annoying ones, JavaScript is still a very powerful programming language.

Some of the bad

One of the several shocking example of what 's wrong with JavaScript if the following snippet of code:

return
{
  ok: false
};

Now, consider the very similar code:

return {
  ok: false
};

One could expect that the two snippets would do the same thing. In most traditional language, the position of the curly brackets is simply a mater of personal preference. In JavaScript, it is not.

The fist snippets simply returns without doing anything. This is because JavaScript has the annoying habit of automatically adding semicolons under some circumstances. This is one of them. The second snippet returns a block of code. A simple new line changes completely the execution of the code. Thanks JavaScript...

Some the good

Despite all its faults, JavaScript is just another dynamic languages. So it comes with all the standard dynamic languages goodies like:

• Lambda
• Dynamic Object
• Loose Typing
• Object Literal
• Prototypal Inheritance

Those are the same constructs used by the dynamics languages we all love. Prototypal Inheritance is pretty unique to JavaScript, but Crockford argues that it is as powerful as classical inheritance.

The jist of the talk is that your should go with the grain when working with JavaScript. This mean actually learning the language and take full advantage of it while avoiding the bad parts. JavaScript is a very powerful language to write nice dynamic web applications. It has its faults sure, be there are way to navigate around those.

There's a lot more in the talk, I hope you enjoy it as much as I did!

Test Driven Development: The Benefits

This is the first part of a series of post regarding TDD (Test Driven Development), how it works, why YOU should use it, how to do it and how not to do it.

How I got started

As part of my final year of University, I've started working on a Ruby port an executable specification framework called GreenPepper.

My team and I decided to develop the entire thing while sticking religiously to the TDD methodology. Two months into the project we have over 98% code coverage.

TDD Simply Put

Very simply put, here are the 3 easy steps of TDD.

1. Write a test that fails
   
2. Write code to make it pass
3. Refactor

Those three steps are essential, they must all be done and in that precise order. In a future post, I'll give a more concrete example of how to apply these three steps. But for now, understand that if you're doing TDD, you cannot write code unless a test is failing.

The Benefits

The benefits of TDD are all tied to those three easy steps. The obvious benefits is that by following all those steps, the near entirety of your code is covered by your tests.

Also, by writing the tests first, you're forcing yourself to write code with easy and simple APIs. Lets face it, you're gonna be the one calling your code, might as well make it easy to use.

Another key benefits of writing test is that you are in fact writting an example of how to use your code. In a project where everything is properly tested, if you wish to learn how to use a class, you simply need to locate the tests for this class and you'll have a very complete example.

Now, the biggest advantage of unit testing is easy refactoring. When working of code that is not automatically tested, developpers are understandably frighten of huge refactorings. I myself worked in projects where features were abandon because it was too likely implementing it would break something. If everything is tested, you can change whatever you want without worrying about regressions.

A Real World Example

A testimony to easy refacoring with TDD is my last change to GreenPepper Ruby. We were using the standard Ruby XML library REXML for all our DOM parsing. This turned out to be a bad decision for several reason. REXML is sloooow, poorly documented and the API is simply awful. A much better choice was libxml. We didn't originally go with libxml because the OS X version was broken at the time. Recently the libxml team released the 1.0 version that fixed OS X. I decided it would be a good time to jump ship before the cost of changing library was even greater.

So I went in and change every class that used REXML. GreenPepper uses DOM extensively, so it was a huge change, several class had to be heavilly modified. It took me less than 5 hours to completly replace the parser.

I am 100% confident I did not break anything in the code. Why? Because EVERYTHING is tested and every test still passes!

There is no way in hell I would have dare change that parser if it wasn't for TDD.

The Bottom Line

TDD makes you more confident your software works at any given time. You can refactor without fear, thus creating much better code. If you plan on writing software that will be maintainable, you absolutely need unit testing and the best way to achieve that is thought TDD.

You should do TDD.