Graphics Engines in Firefox

One of the key goals for the Firefox Layout & Rendering team is to improve performance for web applications. Web apps nowadays push the graphics rendering stack in ways that rival console games. To that end, our existing rasterizer was hitting its limits in terms of the sheer volume of data we now push through it on a a regular basis. Switching out a shipping application’s raster engine is a big deal that requires a lot of scaffolding. When I was working on the Flash Player, I saw how much work goes into integrating a new graphics engine into a shipping product. Sometimes, you have no choice but to tack it on top of (or in Flash’s case, behind) the existing rasterizer.

For Firefox, the scaffolding involves the addition of the new rasterizer initially for the  <canvas> API’s. This was ideal because it was fairly localized, and backwards-breakage risk was manageable. In the next phase, all CSS layout styling will use the new engine. The lessons learned from <canvas> make this a much less risky phase but it’s still fraught with peril. The benefits will be worth it, especially when we get page-draw and responsiveness metrics cranked up.

I’ll be posting up more details on Layout & Rendering internals as I dive deeper into it. It’s quite exciting to work on the guts of the Web with passionate engineers.

Shipping already? I just got here!

Firefox 7.0 shipped today. While I can’t take any credit for any of it, my team deserves all the praise. They’ve been hard at work on reducing memory all over the product. I’ve had a few people complain to me about “pork” in Firefox and we’re making some big changes to cut the fat. It’s interesting how getting a new job just means new complaints from the same cadre of “stakeholders.” Let me know via the blog comments if Firefox is working better (or not) with all these optimizations.

Interviewing in Silicon Valley

I spent a fair amount of time interviewing for jobs before landing the one I have now. Sitting in the interviewee chair was a learning experience after many years at the same company—it had been a long time since I was an external candidate. This post might help others sitting on either side of a Silicon Valley interview.

I’m a Software Developer who manages other Software Developers. This is an important point because I was interviewing for management and non-management roles at the companies I visited. I wanted to lead a team with a strong engineering foundation. From my experience, effective teams inevitably grow to require new leaders and I would much rather be an engineer on a strong team that will grow to need (me as) a leader than to come in to lead a weak team. I also wanted to learn how a company hires its engineers as it is a good indicator of their other business practices.

There’s plenty of evidence that a manager can have an unfairly significant influence on a team or company’s culture. Hiring managers should therefore take more time and care than hiring an engineer, but what are the differences in interviewing for either case? Management style is a key indicator of culture fit, which can be the difference between success and disaster. Good interviewers asked questions that invite dialog:

  • Did you ever fire anyone? Why/how?
  • How do you find/manage poor performers?
  • Tell me a success story and a horror story at your last job. (Very telling, but allow enough time for both stories.)
  • Describe your management style.

In general, the non-technical questions were a good way to learn about a candidates cultural leanings, but were not necessarily a good way to tell if they’re any good at making software. A few interviewers fell into the trap of using the wrong technical questions to determine fitness for this purpose. There was a wide disparity in the quality of technical questions used at interviews. By quality, I mean the effectiveness of a given technical question in determining a candidate’s ability to contribute to your specific software project.

The answers to most technical interview questions can be found on the web. Interviewers need to assume that, if hired, the candidate will have the Internet at work to solve these kinds of problems. For example, any question with “hash table” as a correct answer should be avoided. Questions that have no relevance to real work are just annoying. Don’t ask for code you won’t use. In my many years as a professional developer, I have never seen a need to reverse a text string in a commercial software product.

It’s much more effective to talk about real technical problems with the project that you’re hiring for. A couple of interesting ones I was asked involved real bugs in the actual product. That was cool for me as the interviewee who learned some real-world problems I’ll encounter if hired, and good for the interviewer who may get a free bug fix in the deal. It also got a good dialog going on diagnosis/debugging techniques.

Use caution with coding exercises. It’s important to remember that programmers don’t formulate solutions alike. A whiteboard coding exercise will not be the best way to predict a programmer’s style when a real editor, compiler and debugger are available. What you’re looking for is the presence or absence of key elements in the algorithm–not the syntax. Don’t come with a coding exercise and expect the code on the whiteboard to look exactly like how you’d do it. In one interview, I was asked to implement a 1-bit run-length encoder. Although 1-bit RLE is an awful compression technique for all but the most basic monochrome bitmaps, it tells you if the candidate can understand loops and bit-operations. I’ve posted my code here, effectively reducing this interview question to another one you can answer with a web browser.

Good luck in your search!

New Beginnings!

I recently started working on Firefox. To be more specific, I help run the Gecko Layout Team for the Mozilla Corporation. My team is responsible for everything you can “see” in Firefox. As you can imagine, the team is very busy.

I really enjoy working on software used by hundreds of millions of people. Before I started working on Firefox full-time, I managed Software Engineering for the Adobe Flash Player. Before that, I worked on a bunch of other software used by lots of people. After 13 years at Adobe and Macromedia, it was time for me to make a change.

I started looking for an opportunity that would let me continue working for a global audience and allow growth through new challenges. At Adobe, I had the opportunity to work with all the browser vendors to make sure that the Flash Player worked on their products. I really enjoyed working with the Mozilla people, so I reached out to let them know about my plans. They’re hiring lots of new staff and needed help on Engineering Leadership to scale the organization. After a very rigorous interview process, I started work on September 12, 2011.

In the short time I’ve been at Mozilla, it’s already clear that this place is run by Engineers. I love it! It feels a lot like Macromedia did when I started there in 1998. My first day on the job was at the San Jose Convention Center where the Mozilla employees had their All-Hands meeting. There was far more energy and enthusiasm at the Mozilla All-Hands than at the last event I saw at the Convention Center (which had 10x as many attendees!) Everyone at Mozilla is definitely on a mission and charged up…

  • It’s not enough to not be evil.
  • It’s not enough to be good at what you do.
  • You have to Do Good.