I've put some new photos up: Dan's birthday and leaving drinks at Boltblue. Speaking of which: yesterday was my last day at Boltblue, which means I can finally announce that my new job is with the fine people at Yahoo! Europe. For those who've not heard how it all went down yet, here's the story, in excruciating detail...

At the end of August I received a call from Spencer Rose, a job agency (and my new best friends), saying they had a job that I might be interested in from a large, undisclosed Internet company, whom my agent strongly hinted was one of the biggest, and in search, and not Google. So, uh, that'd be Yahoo then. (Or Yahoo!, although I have been assured that I am under no contractual obligation to spell it that way). The job originally offerred was a very high-paid permanent role that required four years of experience in mobile web technologies. Mathematics fans will note that four years ago it was 2001, when almost nobody had a phone with any sort of sensible Internet access. So there aren't loads of people with four years of mobile web experience -- and they do exist, I've met some now -- and most of them already work for Yahoo or Google. So they had widened their search, and were reducing both the salary and the requirements -- so I, with my 1 year of mobile web at Boltblue and four-plus years of everything else, was a candidate. Would I be interested, they redundantly enquired, since I'd have to be brain-dead not to be.

So they sent me through a big 14-question essay-style interview, where they asked some fairly detailed questions about my opinion on various technical matters. For the truly geeky (and, I guess, for people who want a job like mine), my answers to that questionnaire are at the bottom of this post. The week I had to answer the questionnaire was also the week I had that really bad flu, so on a Friday when I was home sick from work I spent four hours in a fevered delerium coming up with answers to these questions, and sent it back to them.

Apparently being half-dead from flu is a good state for answering questions, because they came back again about a week later, saying that Yahoo were very impressed with my responses and would like to do a telephone interview the following week. They described it as a technical interview, so I should carefully review my answers to the questionnaire. The date rolled around, and I spoke to Matt, my new boss, who was at that point in California. Matt said the interview would in fact be an informal, get-to-know-you type of interview, so I sat in Finsbury Square park, and he sat in his office in Sunnyvale, and we chatted about what it's like to work for Yahoo, the joy of a company that encourages you to regularly visit its US campus in Sunnyvale, California (outside San Francisco), development processes, the importance of testing, my third-year project (predicting three years ago what everybody is doing now, which impressed, and the fact that I had missed the major aspects of how it would be implemented was conveniently overlooked), and why the web is shit and needs to be improved. It was all very cordial, and I thought it went well. Matt said the next steps would an in-person, technical interview, and a final interview with his boss, Paul.

The feedback from the telephone interview was good, and they said they'd like to do an in-person interview: this one would be technical, so I should carefully review my answers to the questionnaire. Of course, I was off to New York that week, so it was arranged for the Wednesday after the Tuesday I got back. So, jet-lagged and exhausted from an action-packed week in NYC, powered up by two bottles of lucozade and a cup of tea, I arrived at their offices on Shaftesbury Avenue on Wednesday morning, in full monkey-suit. There I met (consulting notes now) Jon and David, manager of testing and a front-end developer respectively. They said that actually, it would be an informal, get-to-know-you interview (are we spotting a pattern here?). So we spent an hour chatting about my employment history, what it's like to work at Yahoo, my opinion on PHP versus Java, how the company is structured, and a bunch of other topics. This went very well, I thought, and as we wrapped up they said they would get Paul, who was originally supposed to be in the first part but had been too busy to make it.

Paul turned up 3 minutes later, looking stressed-out and harassed. He asked me to summarise my career history in 10 sentences or less (I got it down to five), and had one other question: "you're very young. I wasn't expecting that. You'll probably be the youngest person on the team. How do you think that will work?" I explained that I have always been the youngest person at every company I've worked at, and that I've been doing the web since 1996, so any questions about whether my age affects my ability dries up pretty quickly after my first few weeks. Immediately after I answered this, he said "right, I've got a read of you. They say you should get the read of someone you're interviewing in the first 30 seconds, and I've got it now. So that'll be all." As he walked me to the elevator, he said "so, we might call you in for another interview, or we might just make a decision".

I had no idea what to make of this. Was 3 minutes to get a "read" a good or a bad thing? Was "make a decision" code for "decide against" or could it be a hire decision as well? Paul also promised that I would hear by the next day.

That was a Wednesday, so I spent all of Thursday on an absolute knife edge, jumping every time the phone rang, checking for messages every 15 seconds, and generally pumped full of adrenaline, pestering my agent with phone calls to see if she'd heard anything yet. This turned out to be pointless, as I got no news that day. I took this to be a bad sign -- people are generally quick to say they've hired, but take ages to break bad news to you, as they no longer care about you. To take my mind off of things, I went out to Miss-Shapes that Thursday night until late, so on the Friday morning I was on 4 hours sleep and hence could not be anything but relaxed, or at least comatose, when I got a call on my mobile from an "unknown number" -- always a sign of an agent calling.

I ran to the abandoned office to take the call, and sure enough it was my agent. "I have some feedback for you from Yahoo," she announced in a sombre tone. My heart sank further -- "feedback" is what you get after they decide not to hire you. "Yahoo were very impressed with your performance at interview," she continued, as I braced for the "but", "and they've decided to make you an offer".

And that was it, all over bar the goodies: a chunky pay rise, health insurance (which I already had), life insurance (which I didn't), stock options (woo!) and a pension. And of course, a job at Yahoo, one of the world's biggest Internet companies, and a place I fantasized about working at back in 1996, when I got a modem, saw the Internet, built my first web page and realised that this is what I wanted to do for the rest of my life. At the time, I remember trying to visualize working for Yahoo or Amazon (Google wasn't around back then), and thinking "but dammit, they don't need anybody new. They've done everything." Luckily, that particular prediction was wrong. The plans I've heard at interview for the stuff they're, sorry, we're planning to do in the next few months and years make me sure the job is going to be interesting, and I'm going to be working on genuinely new and interesting stuff that nobody is doing yet. This is, and has been for nearly a decade, my dream job, the one I thought I would never be good enough to get, and I've got it. Woo!

And yes, in case you're wondering, I can indeed blog about all of this: Yahoo has a sensible and reasonably straightforward Corporate Blogging Policy. I still don't intend to blog about work regularly, but when exciting new stuff happens I'm sure I'll let you all know :-)

Geeks only beyond this point

Now, for those who wondered what Yahoo's interview questions are like, here's the questionnaire I got, and the answers I gave. The original questionnaire was 14 questions, I've snipped a few that related to personal details.

1. What developer tools do you prefer to use to do front-end coding? What do you like about them?

   I do most of my development using the Eclipse platform. At work I use the free PHPeclipse plugin, while at home I have been trying out the MyEclipse commercial add-on and found it quite useful. Eclipse is invaluable for project work in our team, as it lends itself to packaging up code as a project, including automated building with Ant for JSP projects. I also like its easy integration with CVS, which encourages developers to commit often and branch when necessary by taking the hassle out of doing so.

   I also make extensive use of two text editors: Crimson Editor and NoteTab Pro. Crimson I use for doing "spike" coding, i.e. a single-page proof of concept to show that a particular feature can be implemented as planned. I like it because it’s very quick and has extensive syntax-highlighting libraries for nearly every language I’ve ever used. NoteTab Pro is just a simple text editor that I use primarily for its powerful search and replace function, which is great for completing repetitive text processing tasks.

2. What technical books or web sites do you reference most in your daily job?

   The most frequently visited sites on my documentation bookmarks list are the PHP manual, the core JavaScript 1.5 reference, the Java API docs, and the JavaScript DOM, as well as the CSS 2 properties index. When coding mobile content I make extensive use of the Openwave Mobile Profile and CSS Reference.

3. Which standard of HTML do you prefer to code and why?

   For web development, XHTML 1.0 is my standard of choice [Please ignore the hypocrisy that is this blog. I'm working on replacing it sometime Real Soon Now™ - Ed.]. Older browsers handle it without significant trouble, and the extra rigour in terms of document structure that XML demands leads to more easily maintained code and fewer render bugs. There are also numerous well-documented technical reasons, such as the ability to transform it with XSLT, its greater accessibility, and "future-proofing" code for future development as all web development will eventually be in some flavour of XHTML. However, even without these reasons I prefer XHTML for pragmatic reasons, since fewer render bugs save me time.

   For mobile applications, XHTML + CSS is pretty much the only sensible option to be rendered across multiple devices with any degree of control over presentation. At the moment most sites produce a fallback WML version, but the majority of WAP users in the UK are XHTML-capable. I expect WML development will eventually stop being cost-effective, although for a very large customer base such as Yahoo’s that might take a very long time. [I have since discovered that international markets, e.g. India, are huge areas of WML development.]

4. How do blind people use the web? What can web developers do to help?

   Users who are partially sighted tend to use magnifiers, large fonts, and contrast-enhancing colour schemes. For these users, using XHTML and CSS carefully means layouts will be able to gracefully handle enlarged fonts (by using em instead of px units, when possible) and colour schemes can be more easily overridden with an external style sheet set by the user’s browser.

   Users who are entirely blind may use a screen reader or Braille converter. For these users, the internal layout of the code itself is very important, for instance placing the important content first in the source code, and moving navigational content lower down, using CSS to place the content more appropriately for sighted users. Using the semantic nature of XHTML correctly can also help these users, since screen readers can recognize text in an H1 tag as being important, text in UL as being a coherent list of items, etc..

   For both these types of users, it is of course also always important to make sure any text that is contained within images is also available as plain text, either within ALT or TITLE attributes or simply repeated. It’s also vital to make sure that any features of the page that rely on JavaScript are also available through ordinary navigation. However, both of these guidelines are general rules that also apply to sighted users who may have images or scripting turned off.

5. Name a few ways that web developers can help to improve page rank in search engine results?

   Many of the same rules that help users with vision problems are also useful techniques for increasing page rank, as search engine spiders cannot read text within images, usually ignore JavaScript, and place more weight on text within the TITLE tag and the various H* tags, as well as text that is closer to the top of the source code. So again: make sure all text in images is available as text, make sure no vital information is hidden behind JavaScript, and lay out your source code in order of importance rather than order of display. In addition, it can help to use links with meaningful text rather than just image links or links that say "click here", as search engines place a lot of weight on the content of links.

6. What are the pros and cons of using CSS vs. tables for page layout? Which do you use most and why?

   Unless you have a major requirement to support very old browsers, you should always use CSS for page layout. Table-based layouts were a hack, a clever way of getting around the lack of powerful tools to control page layout in early browsers. The major advantage of a table layout, therefore, is that it is more likely to work in older browsers. The major disadvantage of table layouts is that they wreck the semantics of the page and hence diminish the accessibility of the page for those using screen readers. They also make life difficult for users of devices with unusual form factors such as mobile devices, as the content cannot be easily converted into another layout, leading to tedious horizontal scrolling or simply being unable to display the page at all. CSS was designed from the ground up to be a way of controlling presentation and layout of a page. This means it is a much more powerful and flexible way of laying out a page, which is an advantage in itself. It also does not interfere with the semantics of the code. The disadvantage of CSS is that support across various browsers has in the past been unreliable, and older browsers do not support it. This means that only a subset of the full capabilities of CSS can be used with confidence and that if you have a requirement to support older browsers (5 years or more), you cannot use CSS.

7. What are web standards good for?

   Web standards improve the user experience by making development easier. The existence of a standard means web developers can work to that standard and be more confident that their designs and layouts will be competently handled by a wide range of browsers across devices and operating systems. For developers of browsing applications, it gives them a sensible development goal to achieve. This creates a virtuous circle in which web developers produce more pages in that standard because it works on more devices, and device developers support the standard because most web pages are written in it. This improves the user experience, since more web pages will display correctly, and more web applications work correctly, for more users.

8. What trends have you seen happening in the web development world recently?

   The big, underlying trend in web development has been the shift away from the development of web sites to web applications instead. Users are getting a lot more than the static information of a collection of pages and are instead beginning to use web applications as tools to get work done, organize information, or communicate.

   There has been a trend more recently of sites that exploit network effects amongst their users to provide extra value to all. Flickr, for example, is not just a site for storing photo albums but also a community for showing them off, and during recent world events such as the Boxing Day Tsunami and the London bombings it became a popular way for people coming to terms with the situation to get pictures of what was going on. Audioscrobbler (now Last.fm) allows users who share their music-listening habits to find and communicate with people who share their own taste, as well as discover new music through automatically-generated recommendations. These effects are of course nothing new – eBay exists thanks to network effects, and Amazon has been doing automatic recommendations since the mid 1990s – but the trend is now more widespread. Yahoo itself has ventured into this territory with My Web 2.0 beta, which builds on bookmark-sharing functionality made popular by del.icio.us.

   Most recently, there has been a sudden surge of interest in Ajax-based technologies. This blanket term for a combination of XHTML, XML, and JavaScript (in particular the XmlHttpRequest object) is used to refer to a new breed of web applications, most famously Gmail and Google Maps, that truly deserve to be called applications. In their level of responsiveness and the general behaviour of their user interfaces, these applications do not act like a series of pages with the typical request-load-render cycle, but instead create a single interface which then seamlessly displays information retrieved as XML via a series of asynchronous background calls to the server without re-rendering the entire page. This is the most exciting development in the web space for a long time. [Since this interview, Yahoo has launched the really very sexy new Yahoo Maps and started beta-testing a new version of Yahoo Mail based on the work of the excellent Oddpost people.]

9. Are you aware of how Mobile Billing works?

   My curent job is based around premium-rate reverse-billed SMS, as well as more conventional billing methods such as premium-rate phone calls. I have developed several mobile billing and content-delivery applications. This has mainly been via third-party interfaces, so I am not closely familiar with the details of the protocols and technologies involved, but I am very familiar with the concepts involved such as MO billing, MT billing, retrying, recharging and network querying, and the general flow of user interaction with mobile billing services.

10. What does Mobile Device Management mean to you?

    Mobile Device Management is an emerging set of techniques and software tools produced to handle the enormous variation in the capabilities of mobile devices when attempting to deliver mobile content and services. Unlike the web market, where there are a handful of browsers, which are substantially similar across multiple platforms, the mobile device market is extremely fragmented, with big variations in functionality between devices by the same manufacturer, and even between firmware versions on a single device. Technologies including the WURFL are beginning to emerge to provide a way to centrally discover the capabilities of any device, and software such as the WALL are providing a way to seamlessly adapt content to match these capabilities. In addition to these open-source solutions, there are a large number of emerging commercial solutions.