Sample Interviews

by Miguel de Icaza

Some folks have been asking what kind of interviews we conduct over email for hiring in the Mono team. We allow people to work remotely. To find out how well they can work independently away from our office we came up with some tasks that we give out on job interviews.

In my experience with hiring people at Ximian, the face-to-face interviews did not yield as good results as reviewing someone's existing track record and contributions or these programming exercises.

A resume, plus an interview when you ask the candidate to "implement XX on the whiteboard" and some trick questions have too many problems which are probably worth discussing some other day. In my experience these kinds of interviews that have been popularized in the industry are bad. They evaluate developers on all the wrong dimensions that you need to produce software.

Am posting here two of the interviews that we used in the past to hire for positions into the Windows.Forms group and the Mono VM engine. These interviews are typically conducted over two to three weeks.

A story that I find funny was when we did the Windows.Forms interview. Once I emailed back the applicants with the 2 week deadline, Andreia Gaita replied to me within 2 or 3 days. She was the first to reply, but thought that she was the last, and her code was great, did everything I requested (and if she gives me permission I can post her submission).

Andreia turned out of course to be a superb hacker, see her recent work on Mono/Mozilla integration.

The interviews follow.

These are not the interviews that we will use for Moonlight, but it will give you an idea of what kind of thing we do ;-)

Windows.Forms Interview

Remember: these interviews are designed to be answered at home during your afternoons when you get back from school/work and would usually take a few days.

* The Widget

    You must implement a small rendering engine for a small
    XML-inspired markup language, the language accepts:

    <p>...</p>    To start paragraphs.

    Paragraphs in turn can contain the following:

    <b>...</b>    Where the text ... is bolded.

    <i>...</i>    Where the text ... is italicized

    <link>...</link> Where the ... is rendered as a link

    <blink>...</blink> The text should blink.

        The control must expose one property:

        string Markup { get; set; }

    Which allows the developer to programatically set the markup
    language, for example:

          m = new MarkupControl ();
          m.Markup = "<p>Hello <b>World</b>!</p>";

    The control must also expose an event, so I can hook up
    whenever someone clicks on a link:

    delegate void LinkClicked (object sender, string link_text);

    So I can use it like this:

          m.LinkClicked += my_clicked;
      ...
        
      void my_clicked (object sender, string link_text)
      {
        Console.WriteLine ("The link {0} was clicked", link_text);
      }
                
    You must also provide a complete program that will run when I
    run it in Linux, and you must also exercise the property and
    the event, this would be nice to have:

      void my_clicked (object sender, string link_text)
      {
        Console.WriteLine ("The link {0} was clicked", link_text);
        ((MarkupControl) sender).Markup = "<p>This is the new text after clicking</p>";
      }

    Extra points: when I use blink, you will have to refresh,
    bonus points if you avoid flicker by using double buffering, or
    by only repaining the area that has changed. 

    I want a small and succinct implementation, but this is your
    opportunity to show that you can write *robust* code, so impress
    me.

* Trick Question

    In our corlib implementation, in System/DateTime.cs we have a
    suboptimal implementation of the method "TryParse", we basically
    call Parse inside try/catch.

    Explain:

        * Why do I say that our solution is "suboptimal"?

        * What would it take it to make more efficient?

        * Why did the maintainer that wrote that code not do
          the more efficient thing?

    The trick question is: Why was the faster process not done in
    the first place.

    Explain.
    

JIT Interview

This interview was constructed by Paolo Molaro when we were hiring folks for the JIT. The developers that joined us have been fantastic, Mark and Rodrigo. They are working in adding the CoreCLR security (I blogged about Mark's work before) and the verifier to Mono (which we will need for Moonlight) and have also been doing many other needed tasks on the VM.

    This interview should take a week to complete in your
    afternoons.  Between 8 to 16 hours for someone not familiar
    with Mono.

    We figured that not everyone has time to allocate to this
    immediately, so we will wait until March 30th to review the
    applications.

    All of this can be answered by using the officially released
    Mono packages from:

            http://www.mono-project.com/Downloads

    Get the mono-1.2.3.tar.gz source code download.

    Feel free to ask any questions privately or in any Mono public
    forums.

First Task: Extending the Mono VM

    Given the following program, change the mono JIT to intercept
    the Datum.Add () function and implement it internally with a
    SSE instruction so that the additions happen in
    parallel. Datum.Add () is to be treated like an intrinsic:
    this means that the JIT knows exactly what it's supposed to do
    and doesn't need to actually compile the IL code in it.

    Ie, you catch early on the call to Datum.Add (), there is no
    need to do any advanced compiler optimizations.  The current
    implementation here will be ignored once you have this
    implemented.

using System;

struct Datum {
    float f1; float f2; float f3; float f4;

    Datum (float val) {
        f1 = f2 = f3 = f4 = val;
    }

    void Add (ref Datum b) {
        f1 += b.f1;
        f2 += b.f2;
        f3 += b.f3;
        f4 += b.f4;
    }

    void Print () {
        Console.WriteLine ("{0}:{1}:{2}:{3}", f1, f2, f3, f4);
    }

    const int count = 100;

    static void Main ()
    {
        Datum[] array = new Datum [count];
        float f = 0.1f;
        for (int i = 0; i < count; ++i) {
                array [i] = new Datum (f);
        }
        for (int i = 1; i < count; ++i) {
                array [i].Add (ref array [i - 1]);
        }
        array [10].Print ();
        array [count - 1].Print ();
    }
}

Second Task: 

     Pick one of two:

        * GC Analysis

        * JIT and Generic Analysis

* GC Analysis.

    Given the description in:

        http://www.mono-project.com/Compacting_GC 

    and the implementation in 

                mono/metadata/sgen-gc.c

    describe briefly 3 changes to the GC code and/or JIT-GC
    interface that would provide a significant performance
    speedup. 

    Explain the changes, the reasons it will improve performance
    and provide rough speedup numbers with a benchmark of your
    choice.

* JIT and Generic Analysis

   Mono supports generics in its compiler and VM, this means that
   code like this is supported:

       class MyStack<T> {
               T [] storage;
               int top;

               MyStack ()
               {
                       storage = new T [10];
               }

               public void Push (T datum)
               {
                       storage [top++] = datum;
               }

               public bool Empty {
                       get {
                               return top == 0;
                       }
               }
       }

   If the above code is used like this:

       MyStack<object> object_stack = new MyStack<object> ()
       MyStack<string> string_stack = new MyStack<string> ()
       MyStack<int> string_stack = new MyStack<int> ()

   Explain:

       * When a generic class is instantiated, what pieces of
         code are shared?

       * Why they should be shared?

       * Are they shared in Mono?   

       * If yes, why?   If not, why not?

       * How could this be improved?

    

Posted on 05 Sep 2007


Microsoft/Novell Collaboration on Silverlight.

by Miguel de Icaza

Update: I have updated this post addressing some questions that people have raised over email and the group. The updates are flagged with an Update label.

Update: Scott Guthrie at Microsoft blogs about the news: updates to Silverlight 1.1, organizations adopting Silverlight 1.0 and links to various tutorials.

Today we are announcing a new collaboration with Microsoft around Silverlight. The Mono team at Novell will implement open source versions of Silverlight 1.0 and Silverlight 1.1.

Our implementation of Silverlight is Moonlight.

We have had a cordial relationship with many developers at Microsoft for quite some time. Scott Guthrie and Jason Zander provided us with informal advice on how to implement Moonlight, and we also have good relations with the open source teams working on IronPython and IronRuby.

Today we are formalizing a collaboration between Microsoft and Novell with the explicit purpose of bringing Silverlight to Linux and do this in a fully supported way. The highlights of this collaboration include:

  • Microsoft will give Novell access to the test suites for Silverlight to ensure that we have a compatible specification. The same test suite that Microsoft uses for Silverlight.
  • Microsoft will give us access to the Silverlight specifications: details that might be necessary to implement 1.0, beyond what is currently published on the web; and specifications on the 1.1 version of Silverlight as it is updated.
  • Microsoft will make the codecs for video and audio available to users of Moonlight from their web site. The codecs will be binary codecs, and they will only be licensed for use with Moonlight on a web browser (sorry, those are the rules for the Media codecs[1]).
  • Novell will implement Silverlight 1.0 and 1.1 and will distribute it for the major Linux distributions at the time of the shipment. We will offer some kind of one-click install for Linux users (no "Open a terminal and type su followed by your password..." as well as RPM and DEB packages for the major distros and operating systems.

This is an historical collaboration between an open source project and Microsoft. They have collaborated with other folks on the server space (Xen and PHP) but this is their first direct contribution to the open source desktop.

Microsoft benefits by making Silverlight reach the Linux and BSD spaces. We benefit by ensuring that users of open source operating systems get access to sites that adopt Silverlight to deliver content or spice up their web apps.

[1] Currently Moonlight video support has been prototyped using the fabulous and LGPLed ffmpeg engine for video and audio. We are unable to redistribute this code commercially due to licensing conflicts. Update: This means that individuals that want to use a 100% pure free software setup can do so. We are unable to redistribute this edition though.

The binary codecs will initially support x86 and x86-64, with other platforms supported on an as-needed basis. Update: The full list of codecs supported in Silverlight 1.0 are listed here (scroll down a bit).

Update: Some comments indicate that people would like to use GStreamer as the media backend (as GStreamer already has licensed codecs and some people might have purchased them already). We would be glad to merge any patches that people send us (copyright assignment required) to add support for GStreamer.

Update: Some folks are asking whether they could use OGG for the video rendering in Moonlight. Today this is already possible because the media engine we use to prototype is ffmpeg which has support for this. From the standpoint of a desktop developer this might be enough, but for the web, the problem becomes an issue of compatibility with the Microsoft Silverlight implementation.

We will bring up with Microsoft the issue of adding a new codec, but I suspect that since they are pressed to minimize the download size this might be difficult. There are other competing codecs though that people on the Silverlight groups are fairly vocal about and my eclipse our request. If you want official Ogg support from Microsoft, please bring this up on the Silverlight.net forums, Microsoft does listen to user feedback.

Update: The "Silverlights"

Update: There are two versions of Silverlight. The version released today (1.0) is basically a canvas that can be programmed through the browser's Javascript engine. ie, you can use "View Source" on your browser to see how everything is done.

The upcoming version (1.1, a year from now) extends the browser plugin with a embedded CLR runtime. This is what got us in the Mono team interested in the technology was precisely this.

Moonlight was originally designed to only implement 1.1, and only later we noticed that it was forwards compatible with 1.0 and that we could deliver both 1.0 and 1.1.

For developing 1.0 applications the only tool you need is either a text editor or a programming language that supports the "print" command. Designers are useful, but not mandatory (on Windows Blend supports Silverlight, and there might be others). We are building an open source designer ourselves for using on Linux.

If you want to take advantage of the features in 1.1, you will most likely want a .NET compiler and the Silverlight 1.1 libraries to link against. Our next release of Mono (1.2.6) contains a C# 3.0 compiler as well as the Silverlight 1.1 libraries that you can use to target Silverlight 1.1 using Mono on your favorite OS. Of course, with this setup you lose the ability to "View Source" as it now features compiled code in binary form (although if you really want to, you can just use Lutz's Reflector to look at it).

Today our plugin depends on Mono on both cases (1.0 and 1.1), but we are exploring our options to remove Mono from the 1.0 case as it would simplify our profiling and valgrinding of our C++ runtime (valgrinding Mozilla + Mono + Moonlight + a web site is a bit slow).

Working Well With Others

We will be supporting Firefox and Linux initially (that is our first goal).

But we are looking forward to work with developers from other operating systems (BSD, Solaris) and other browser (Konqueror, WebKit and Opera) to ensure that Moonlight works fine on their systems.

Thanks

Getting this collaboration in place took a lot of work on both ends: both the business and legal teams in both companies as well as various people inside Microsoft that endorsed the idea of having an independent implementation of Silverlight endorsed by Microsoft.

Special thanks to Bob Muglia at Microsoft and Jeff Jaffe at Novell for getting the official collaboration rolling.

Scott Guthrie, Bill Hilf and many members of his team that are transforming Microsoft from the inside out and have championed approaching the open source community. Brian Goldfarb made sure that the clock ticked and we got the agreement in place and Marc Jalabert invited us to demo Moonlight at the Paris ReMIX, which led to our 21-day hackathon. And everyone that has so kindly answered our questions on .NET and Silverlight and have championed us from the inside.

In the Novell side, Frank Rego, Denzil Harris, Patrick McBride and Guy Lunardi worked around the clock to get everything in place for this launch.

And of course, none of this would be possible without all the members of the Mono team that made our original proof-of-concept possible on June 21st and that have continued to work on all the various pieces that make up Moonlight possible.

Oh, by the way

We are hiring.

If you are a talented software developer with experience in C#, C++, graphics, fonts, audio, Mozilla, Opera, WebKit, QA, packaging or Gtk+ and you do not mind intense and grueling hours of work to produce something millions of people will see and use, send me an email.

Interviews with the Mono team are usually conducted over email and usually include a complicated and completely useless programming exercise that you complete at home.

Watching Moonlight in Action

If you are attending the IBC2007 conference in Amsterdam you will be able to see Moonlight in action at the Microsoft booth. Hacker extraordinaire Rolf Bjarne (of Mono's VisualBasic.NET fame) will be demonstrating Moonlight running on Linux at the show.

Alternatively, if you want to try out Moonlight yourself, you will need to follow the instructions on our Moonlight page. It currently requires users to compile code from our Subversion repository, we will try to put together in the next few weeks a VirtualBox/VMware image for people to try it out easily.

If you try it out, please report bugs here.

Recently we have been fine tuning Mono to render the Halo3 site:

Halo3 Site on Linux.

You can see more screenshots of Moonlight in action here.

Posted on 05 Sep 2007


Steve Jobs on Jon Stewart

by Miguel de Icaza

From Engadge's coverage, Steve Jobs apparently just said today:

"I love Jon Stewart, I hope all of you watch his show. It's the best place to get the news every day."

People living outside the US can watch Jon Stewart on the web. Highly recommended.

Posted on 05 Sep 2007


Mono's WebControl

by Miguel de Icaza

As part of the work that we are doing to implement Windows.Forms in Mono we needed to provide a WebControl that applications could use to embed a Web browser.

We needed a bit more control than the control that gtkmozembed offers. Zac Bowling started the work to wrap Mozilla and Andreia Gaita completed it:

See Andreia's post on wrapping Mozilla for use in Windows.Forms.

The public interface is Mono.WebBrowser which currently only provides access to Mono.Mozilla, but we envision that we will have other providers as time goes by (in particular our users on MacOS X with Windows.Forms).

Posted on 04 Sep 2007


Michael Hutchinson

by Miguel de Icaza

Michael Hutchinson who co-created during the first Google Summer of Code Project the Mono ASP.NET designer has started work at Novell in the Mono team.

Michael will be joining Ankit Jain, Lluis S├ínchez and Mike Krüeger on improving MonoDevelop.

Michael started working today from the UK, but will be joining the enormous Mono team (all two of us) in Cambridge (USA) in October.

I hope he likes sushi. He looks like someone that would like it:

Posted on 03 Sep 2007


Diary of a Web Media Player

by Miguel de Icaza

On Scott Guthrie's blog I found out about Jose Fajardo's journey on learning Silverlight.

Jose decided to write an iTunes-like media player using Silverlight. He has documented his development in about 20 blog posts here.

His application looks like this:

His exercise is aimed towards pixel-similarity with iTunes. Joe Shaw took a more Web-by approach at playback on the web.

Posted on 02 Sep 2007


Am Becoming Chubbier

by Miguel de Icaza

I just noticed that I can barely fit in a shirt that used to be my favorite two years ago. It must be the large amount of fat in those carrots:

	miguel: I think am becoming chubbier
	snorp: it's your part-time veggie diet
	snorp: carrots are high in fat
	snorp: stick to cow
	

Posted on 31 Aug 2007


Nice Unity Interview

by Miguel de Icaza

An interview with Nicholas Francis from Otee, the makers of the Unity game development system.

The Unity folks have been reusing the Mono JIT engine as a game engine, here is a nice blurb about what Mono got them:

If I have to pull out a specific feature it would be our scripting interface: We use Mono to get C#, JavaScript and Boo languages in there for gamecode. This means you get a scripting language running incredibly fast (*footnote: Initially, we used Python for GooBall. With that we were spending 50% of the CPU time inside scripting code. When we switched to Mono, the same functionality dropped to 1-2% CPU usage - we were completely blown away with how fast it is.) so this is what you make your games in (we also have C++ plugins for people who are passionate about C++ or need to use an existing library). When you make a Mono class, all public variables show up in the inspector for easy modification. So basically, Scripts are 1st class citizens of Unity. We're also using Mono for extending Unity - It really is that good.

Hopefully, when I have some spare cycles (hahahaha) I would like to assist the Unity folks in porting their game engine to Linux.

Once we have a port to Linux, we could run most of the games unmodified (the only exception would be those that require C++ plugins), educational software, architecture and advertising software that is being built today with Unity.

Posted on 31 Aug 2007


Moonlight Designer

by Miguel de Icaza

Alan McGovern who worked with us last summer as part of the Google Summer of Code to build a BitTorrent API for Mono called MonoTorrent joined us at Novell this summer as an intern.

When Alan arrived in Cambridge we had just decided that we would start our hack-a-thon on Moonlight to demo whatever we could get done in 21 days to show at the Mix Paris event.

Alan worked in the summer on a XAML designer for Silverlight that he called "Lunar Eclipse":

Ok, do not make fun of it. The important stuff is the engine, not the looks. Am sure Christianism has a quote for this, but I would not know how to google it up, but something like "look at the heart, not at the look". And if not, it is probably on one of those self-help books that I got at a discount price on that bookstore in Newbury St before they shut down.

The idea was to write the Silverlight designer in Silverlight itself. Currently our designer uses Gtk+ for its user interface plus a Silverlight surface for the designer. We felt that we could also build a web version of it and hence tap into the MacOS crowd that would not have access to the Blend designer either.

He started when we barely got anything working, it was quite challenging, because every few hours the code would be in a completely different stage. He reported more bugs than anyone else as he was our first "native" user of Moonlight.

The designer is able to serialize the designs into XAML, it is possible to hand-edit the XAML and go back to the rendering surface and is also has a timeline editor for creating animations.

Some videos for your pleasure created by Alan:

Of course, our long term goals would be to polish this up and create a Mono Add-In for MonoDevelop to offer a complete Silverlight development stack on Linux.

On the development stack side, we have most of the bits to have a Silverlight development stack for Linux, Unix and MacOS ready. Sadly this will not be part of Mono 1.2.5, it will be part of our next release: Mono 1.2.6 scheduled for sometime in October or November. The adventurous among you can already use this by using Mono from SVN (for full instructions, see this link).

You might notice that LunarEclipse lacks file loading and file saving. This was because Alan insisted that file loading must use the Bittorrent protocol (his argument was that XAML files one day could span multiple gigabytes), but he did not know how to save files with Bittorrent.

For the time being, you can use cut-and-paste to load and save your XAML files. Either that, or send us a patch ;-)

Working with Alan this summer was a pleasure. It was my first time working with an Irish that considered the idea of a "seven course meal" to be a six-pack of Guinness and potatoes. The good news is that we turned him around, and by the end of the summer he was an avid chicken-quesadilla consumer.

Posted on 31 Aug 2007


Gtk+ on OSX

by Miguel de Icaza

Michael Natterer posts on the work to integrate the Gtk+ menu with the OSX menu:

A video is available here.

Congratulations to the folks involved in getting Gtk+ running on OSX.

Update: Replaced the ugly screenshot with a beautiful one from Mikael Hallendal from Imendio.

Posted on 30 Aug 2007


« Newer entries | Older entries »