Perhaps the most important ingredient in the success of a software development team is the raw talent of its team members. This is supported by the so called 10x rule, which states that the strongest developer is about 10 times as productive as the weakest. This huge variation in productivity has long been observed among development managers and is also backed by a significant body of research [1].

The 10x rule supports the view that no other decision is as important as who you hire. While you can nurture talent and help the good become great, transforming poor performers into coding rock stars is completely impractical in a development team with deadlines and deliverables. And all development teams have deadlines and deliverables.

The 10x rule also supports the view that you have to filter out many of those on the low end of the 10x spectrum to find the gems, or even the 5x supporting players. How can this be done? One of the best ways to know if someone has mastered a skill is to have them perform it and evaluate the results. If you need a musician, there’s the audition. If you need a chief, there’s t he taste test. If you a need a software developer, there’s the coding test.

Coding tests are nothing new and have many variations: simple paper exercises, whiteboard algorithm problems, or mini development projects that can be completed in an hour. More recently, startups like HackerRank, TestDome, and Codility offer cloud-based testing solutions that have the potential to make pre-interview testing faster, easier, and more effective.

This post reviews Codility from the CTO or software development manager’s standpoint. It’s based on my experience using Codility to evaluate the performance of a software engineering team I’d been brought in to manage, improve, and expand while CTO of a large digital marketing company. I began by testing existing team members and then tested prospective new hires.

Codility is a cloud-based developer evaluation tool that:

• Allows development managers to create online coding tests in most popular languages by combining carefully designed standardized programming tasks.
• Provides developers with an online test environment to read the task, code a solution, and run that solution much as they would in a standard code editor.
• Automatically evaluates test session results for correctness and performance against multiple test cases.
• Compares results with those of thousands of other test-takers that have completed the same test.
• Reports test session results to the development manager and optionally provides feedback to the developer.

Ten years ago, Greg (Grzegorz) Jakacki was facing a problem that many development managers struggle with: only a small proportion of applicants for programming jobs could actually program to a level even close to what he required. Using principles inspired by coding competitions like the International Olympiad in Informatics [2], where he had won a bronze medal, Greg and his colleagues developed automated testing software that filtered out 90% of applicants, allowing Greg to focus his interviews on the better skilled developers who passed the test.

Greg then pitched the idea of a web based version of his software at the 2009 Seedcamp competition in London. He won, and Codility was born. Today, Codility has offices in London, Warsaw, and San Francisco that support 200 corporate customers in over 120 countries. Since 2009, Codility has run over 2 million tests, which provides a significant dataset with which to compare new test takers.

Codility is primarily used as a pre-interview test for software developers. It can also be used to evaluate performance of an existing software development team in order to facilitate professional development or restructuring.

For Developer Recruitment. Codility is not intended to be a one stop evaluation tool. Rather, it filters out poorly performing developers so the hiring manager can focus on strong candidates. Additional interviews and evaluations are required. However, Codility can greatly reduce the number of interviews you must perform to build your team, it’s not uncommon to filter out 80% to 90% of applicants in the initial testing. And because you can compare a candidate’s performance to thousands of developers worldwide, test results are more meaningful than if you can only compare to the developers within your organization.

For Development Team Restructuring. Imagine that you’ve been brought in to fix a poorly performing software team. You find issues with product definition, development process, team tooling, etc. The team may also have some underperforming members who are reducing overall productivity and impacting moral. But, given the less than optimal work conditions, it’s hard to be sure if they simply don’t have the support they need to thrive, or if they don’t have the raw talent. Testing all team members can help you understand the team’s talent landscape and take action to improve it. It also helps you understand how test scores translate into actual developer quality and productivity, providing a meaningful metric for new candidates.

Criticisms. The primary criticism of Codility and controlled testing of software developers in general is that the tests are too academic and do not measure what’s needed to succeed as a real life developer. In real life there is teamwork, Internet resources, and time to mull things over. In real life you might do it differently than what you learned in school, as long as it works and works on time.

While all this is true, it does not diminish the value of testing. Remember that the purpose of testing is simply to create a short list of candidates to interview and further evaluate, not to rank all candidates. While a candidate with a score of 85% may or may not be a better choice than one with a score of 75%, ones that do not pass at all are almost certainly a bad choice. They are unlikely to contribute more to the team then they require from it, so even if they are nice people, they will not be good team members.

I’ll walk you through the basics steps in using Codility, and later give you some pointers of how to make it work for you.

1. Name your test and select the language or languages you want in which developers will code. Choose any combination of C, C++, C#, Go, Java, JavaScript, Lua, Objective-C, Pascal, PHP, Perl, Python, Ruby, Scala, and VB.NET. If you choose more than one language, the test takers can select whichever they prefer.
   

   
   

2. Select a few tasks for the test. Three is the most common number for a test, since it allows you to vary the type of tasks without exhausting the test taker. Tests are categorized by difficulty (Easy, Medium, Hard) and type (coding, algorithm, bug fixing, and SQL). Each task typically requires the developer to write or modify a short program (usually 10–20 lines).
   
3. Administer tests sessions. These can be done onsite or emailed to the test taker for offsite completion. The test-taker reads the problem and initial code, then works in the provided online editor (or optionally in their preferred editor, pasting it in when complete). They run the code and if it compiles and provides the expected result for the example test case, the system says “OK.” However, in order to get a 100% score, the code must run correctly and efficiently against all possible inputs. Test takers can run their solution as many times as required and submit the task when they are happy with their code.
   
4. Review task results. You’ll be notified when the test is complete and can then review the score for each task and see the actual code submitted as well as the total time spent working on it. You can run a screen-cast video of the code as it was typed to get an idea of how the developer arrived at the solution.
   

   You can also see the pass/fail results of each correctness and performance test:
   

5. Review test results. Each task is graded for correctness, and some for code performance. These task scores are averaged to produce a composite test score.



6. Compare results to all test takers. What does the test result mean? You can compare individual task scores with the scores of all test takers, usually thousands of developers. The results are displayed when you select a task. Some tasks are very easy, for good developers they are more of a warmup round. For example, 73% of test takers got 50% or more on the SqlDepartments task, while 71% got 100%.
   

   Other tests are much more difficult with almost everyone failing:
   

Here are some pointers to get the most from Codility:

1. Try the free trial to help you understand how Codility works and what the tests are like. The trial allows you to test up to 50 candidates in a 14-day period, but unfortunately you can only draw from a pool of six tasks to develop your tests. I found this to be insufficient for testing existing team members and new recruits. Additionally, since anyone can sign up for the trial without paying, developers could practise the six trial tasks before you test them. Therefore, I suggest using the free trial only for an initial walk through and for a complete evaluation pay for a month's subscription.
2. Test your existing team to better understand its strengths and weaknesses and to provide a metric against which to measure new candidates. You'll want new recruits to meet or exceed test scores of your top developers.
3. Select relevant test tasks. Test tasks should be similar to the kind of work your team does. This ensures the testing is relevant and not simply an academic exercise. A typical test will include two to four tasks and last an hour or two maximum.
4. Blend test task difficulty. Test task results on the easiest or hardest end of the spectrum are somewhat binary, with almost everyone passing the easiest tasks and almost everyone failing the hardest ones. If you choose only these, most test-takers will have the same score which will not help you choose between them. Instead, use published results to select tasks at varying levels of difficulty which can discriminate between varying talent levels. Getting the right combinations of tasks may take a few iterations of testing with your team.
5. Encourage test-takers to try a demo test. Codility publishes lessons, challenges, and demo tests for developers. Taking a demo test and reviewing the developer FAQs is a great way for developers to get comfortable with the test environment and process. This makes for more accurate test results since test anxiety will result in scores that do not reflect the test taker’s full potential.
6. Review the results. Compare task scores with Codility’s published results and against your team’s scores (if you're testing new hires). For a more detailed understanding review the analysis section to see which test cases passed or failed and to review the code. You can even play a screen video of the code as it was typed to understand how the developer arrived at the solution.
7. Passing the test is important, the exact score is not. The exact passing score you choose will vary with the position, the candidate pool, and the tasks selected. Run the same test with your team and come up with a passing threshold which you can adjust up or down if required, depending on candidate performance. For borderline test results you can review the code to make a final decision. While a minimum level of competency is vital, slight variations above the threshold may or may not be meaningful. The best developer may not be the one with the highest score, so move to other evaluation methods like the interview to determine suitability before making job offers.
8. Provide feedback, or not. Codility can optionally share complete test results with test takers. If you’re testing your team, I recommend sharing the results with individual team members and perhaps discussing them in a one-on-one. However, I don’t like sharing more than the test score with the external candidates since the detailed feedback could be shared with future test takers and give them an unfair advantage.
9. Test onsite if possible. I prefer to test onsite to ensure test takers don’t get help from a more experienced or competent friend. I’ll make an exception if a candidate is out of town, in which case a simple phone conversation about the coding choices they made during the test will reveal if the code submitted was theirs. Allowing online references can be OK, since time limits will prevent a test taker from using them for more than a supporting resource.
10. Answer questions about the tasks. I’ll make a senior developer available to answer questions during the test. Obviously, questions like “how do you solve this problem” will not be answered, but those that help the test-taker understand what is being asked of them are OK. This is especially important when testing developers who are not native English speakers.

• Free Trial: Up to 50 tests during 14-days created from 6 tasks.
• Startup Subscription: 199 USD monthly for up to 30 tests created from 86 tasks.
• Enterprise Subscription: Custom pricing for unlimited tests created from 136 tasks
• Per Test Package: Starts at 17.50 USD per test with discounts for volume.
• Discounts: One time 50% discount for startups that purchase a Per Test Package.

Used as the first step in a comprehensive strategy, Codility can increase both efficiency and effectiveness of your organization’s software developer talent evaluation. Given the importance of talent acquisition in a software team’s success, using it to find those 10x developers is a smart choice.

1. Productivity Variations Among Software Developers and Teams: The Origin of 10x. Steve McConnell, March 27, 2008
2. Application of Olympiad-Style Code Assessment to Pre-Hire Screening of Programmers, Olympiads in Informatics, Grzegorz Jakack, Marcin Kubica, & Tomasz Walen, 2011, Vol. 5, 32–43<

I recently attended the Society of Pharmaceutical and Biotech Trainers (SPBT) Annual Conference in Orlando, which featured many interesting presentations, including one by Dr. B. Price Kerfoot. Dr. Kerfoot led ground breaking research in spaced education and has recently explored game mechanics in learning. I had the pleasure of chatting with Dr. Kerfoot, Harvard Medical School professor, edtech researcher, and Qstream board member. A rough cut of our interview follows and a feature article entitled "Spaced-out learning" appears in the March 2014 issue of Training Journal.

Dr. Kerfoot’s research began by exploring two well documented effects and their influence on learning:

1. The spacing effect has been studied as far back as the 19th century by Ebbinghouse. The spacing effect shows that if you present information and then reinforce it over spaced intervals of time, it increases the acquisition of knowledge and encodes it so it’s better retained over the long term.
2. The testing effect, which shows that the act of testing increases retention. Testing in not just for evaluation, the retrieval required during testing can itself dramatically improve long-term retention.

In this video we discuss the limitations of traditional “bolus” elearning [1] and how Dr. Kerfoot’s research demonstrates that the spacing and testing effects can improve online learners’:

1. Information retention, knowledge transfer to related topics, and learning efficiency [2].
2. On the job performance [3].
3. Identification and remediation of underperforming learners [4, 5].

Video 1 of 2. B. Price Kerfoot on Spaced Education

[spaced-ed-ad]

More recently, Dr. Kerfoot studied the combination of spaced education with certain game mechanics (rules intended to make games engaging). In this video we discuss how game-like spaced education increases knowledge retention and test performance while being associated with improved course completion rates and motivation to participate in future spaced education programs [5, 6].

This video covers three main game elements:

1. Rewards. Gabe Zickerman SAPS model: Status, Access, Power, and Stuff as well as balancing intrinsic and extrinsic motivation.
2. Teams. Rewarding teams can be more effective than rewarding individuals [7].
3. Leaderboards. Designing leaderboards for create a shame-free, safe environment that motivates and engages learners.

Video 2 of 2. B. Price Kerfoot on Game Mechanics in Learning

Dr. Kerfoot’s research is part of the body of knowledge demonstrating that, while intensive training can produce a short-term spike in learning, the learning degrades over time. This forgetting curve is so consistent and predictable that it likely has a biological basis. Learning designers need to begin with the assumption that learning is forgotten over time and therefore performance based on that learning will also decline.

The spacing effect and the testing effect are powerful mechanisms to offset the forgetting curve. These principles can be designed into any learning program either by spreading out the initial learning/testing over time or by supplementing intensive training with spaced education. Game mechanics can also be integrated to enhance learner engagement and motivation.

The spacing and testing effects blended with game mechanics are well suited for mobile learning. Spaced education works best when small nuggets of information are offered over time. Small nuggets are also preferred in an mlearning context, where learners may not have more than a few minutes to study. Game mechanics will help motivate learners to engage in their mlearning, rather than having their attention captured by other temptations on the mobile device, whether Angry Birds, Facebook, or Twitter.

1. A Multi-Institutional Randomized Controlled Trial of Adjuvant Web-Based Teaching to Medical Students, Academic Medicine, B. Price Kerfoot and Harley Baker et al, March 2006.
2. Online Spaced Education Generates Transfer and Improves Long-Term Retention of Diagnostic Skills: A Randomized Controlled Trial, American College of Surgeons, B. Price Kerfoot and Yineng Fu et al, September 2010.
3. Durable Improvements in Prostate Cancer Screening from Online Spaced Education, American Journal of Preventive Medicine, B. Price Kerfoot and Elizabeth Lawler et al, November 2010.
4. Online ‘Spaced Education Progress-Testing’ of Students to Confront Two Upcoming Challenges to Medical Schools, Academic Medicine, B. Price Kerfoot and Kitt Shaffer et al, March 2011.
5. An Online Spaced-Education Game to Teach and Assess Medical Students: A Multi-Institutional Prospective Trial, Academic Medicine, B. Price Kerfoot and Harley Baker et al, October 2012.
6. An Online Spaced-Education for Global Continuing Medical Education, Annals of Surgery, B. Price Kerfoot and Harley Baker, July 2012.
7. Individual- versus Group-Based Financial Incentives for Weight Loss: a Randomized Controlled Trial, Annals of Internal Medicine, Jeffrey Kullgren and Andrea Troxel et al, April 2013.

The Experience API (xAPI) specification, also known as the Tin Can API, will move from version 0.95 to 1.0 on April 26, 2013. Once this version is released, expect support from LMS and elearning tool vendors to extend beyond the current group of early adopters.

The xAPI defines the next generation of SCORM which was originally released in January 2000 with support from the US government’s Advanced Distributed Learning (ADL) Initiative. The xAPI is built on standard Web Services and allows much more flexible tracking of a learner’s experience than SCORM. Support for mlearning is greatly enhanced and software development simplified. Most importantly, the xAPI can provide a granular view of a learner’s actions that will enable instructional designers to improve course quality based on real-world data.

Here are some excellent resources to get you up to speed on the xAPI:

• For a copy of the latest specification, see the Experience API on GitHub.
• For interviews covering both technical and pedagogical elements, see Project Tin Can.
• For an overview of its impact on instructional design, see Should Instructional Designers care about the Tin Can API?
• For inspiration about how learning can be enhanced with more data, see What we're learning from online education (TED Talk).

Stanford Research Institute’s Roy Amara had it right when he said "We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run." In line with his caution, I imagine the immediate impact of the xAPI will be minor but the long term impact will be significant. Most organizations have significant investments in the existing standard and will take time to adopt a new one, despite its immediate potential. However, as mobile devices reach near ubiquitous market penetration, corporate Cloud computing gains greater acceptance, and training professionals push for a better understanding of their learner’s experience, the xAPI will become widely implemented. When this happens learning professionals will have a richer understanding of the learner’s experience that will make training more effective at enhancing performance.

“Wow, this is some Minority Report level stuff” said one marketer who tried the Microsoft PixelSense table at Code Crew’s development center. I didn’t know it at the time, but in fact director Steven Spielberg acknowledged that the concept for Minority Report display technology came from consultation with Microsoft during the making of the 2002 sci-fi classic.

The marketer’s reaction is typical of what happens when people see PixelSense, and it’s precisely that quality that has me excited about PixelSense as a social marketing device. It attracts attention, provokes engagement, and gets people talking, all without really trying.

Code Crew recently had the opportunity to develop a branded app for Microsoft PixelSense (known as the Surface until June 2012). Six developers worked to produce the app in under a month. And while our NDA prevents us from providing project and client particulars, the platform impressed me enough that I’ve decided to write an introductory blog on the topic.

PixelSense is an interactive tabletop device with platform software provided by Microsoft and hardware, called the SUR40, provided by Samsung. Here is what one form of the device looks like:

Fig 1. Microsoft PixelSense 2.0 running on the Samsung SUR40. It’s a lot more fun than this picture suggests.

It might look like an oversized tablet computer on legs, but it’s more than that for the following reasons:

• It’s social. It responds to as many as 50 touch points at once, so multiple users can interact with the same device, and each other, at the same time. So it’s social in the old fashioned sense because it encourages people to interact with each other as well as the device. A bit like playing a board game with your friends or family.
• It can see. Its surface is light sensitive so it can perceive not only touch, but all manner of physical objects placed on it.

[pixelsenseblogsad]

PixelSense apps are custom coded and run on a 64-bit version of Windows 7 Professional for Embedded Systems. Applications for PixelSense are written in Windows Presentation Foundation (WPF) or XNA using Microsoft Surface 2.0 Software Development Kit (SDK). While the development techniques for PixelSense are similar to other Microsoft products such as Windows Phone or X-Box, the special SDK has its unique requirements so previous experience with PixelSense development will make for a much smoother project. We were lucky enough to have one developer familiar with the SDK who could advise other members of the team.

The hardware part of the PixelSense equation is the Samsung SUR40. It is a table that features a 40-inch wide LED back-lit interactive screen. It is only 4 inches thick, which allows it to be used as a tabletop with the supplied legs, embedded in some other piece of furniture, or as a wall mounted display (like a whiteboard).

The screen can provide HD video at 1080 lines of vertical resolution and progressive scan. It has an aspect ratio of 16:9 and a 1920 x 1080 pixel resolution. It is covered with Gorilla Glass to protect it in public spaces.

The SUR40 hardware runs on an AMD Athlon II X2 Dual-Core CPU at 2.9 GHz, AMD's Radeon HD 6700M Series GPU, and a 320 GB hard drive. That’s enough power to run PixelSense apps.

PixelSense allows the device to see what users are doing without using an actual camera. It sees via infrared sensors that come out of each and every pixel on the screen. Unlike the touch screens we use in tablets and phones, this device can register information from hand gestures and physical objects on up to 50 points on the screen at the same time. And it can be programmed to respond to what it sees, whether that’s a fingertip, a hand, or a beer bottle.

Fig 2. PixelSense UI

This provides plenty of room to build highly interactive and informative content that can be accessed and absorbed in a tactile way by multiple users. The highly interactive nature of the interface, and the ability to intuitively move, throw, and manipulate virtual objects, is just plain fun. And the fun is infectious which draws people to the device.

PixelSense can also be used to enhance discussions by providing information, discussion points, and tools to visualize and “tactilize” conversations. For example, PixelSense was used by MSNBC on air during the 2008 US Presidential Election to display election maps and illustrate trends.

PixelSense is a lunge forward from the now familiar graphical user interface (GUI) to the Natural User Interface (NUI) The idea is to remove the artificial access points to digital content, like the mouse and keyboard. Instead, touch interaction in a social context makes the digital environment feel less constrained. PixelSense is designed to make the control side of the user experience virtually invisible.

What table can tell you what’s on it? Besides the rich graphics, video, and touch interaction, PixelSense provides an added new feature. Since it has as many “eyes” on its screen, it can recognize and be programmed to respond to different types of objects you put on top of it. This starts from our hands, and an almost endless range of hand-gestures and positions. But objects can also be seen.

Fig 3. PixelSense can see physical objects and printed patterns, and be programmed to respond.

A credit card could be put on it to run an automatic transaction. Place your drink on it and if the shape of the glass that contains it is unique, or contains a printed image called a “blob,” PixelSense could figure out what you’re having and show you some interesting facts connected to that drink. That could be great to discuss with the people you’re sharing the table with.

I see three main limitations for PixelSense:

1. It’s light and heat sensitive. The ability of PixelSense to “see” is also the source of its biggest limitation. Light shining directly on it, especially warm light with a high infrared component, confuses the system and will cause windows to open and virtual objects to move. Having a bright light shining directly in our eyes is disorienting for humans and is also disorienting for PixelSense. The solution to this problem is indirect, soft lighting. Samsung publishes the “SUR40 for Microsoft Surface Venue Readiness Guide” which documents how to set up the SUR40 to avoid this problem.
2. It’s design paradigm requires some adjustment. PixelSense offers a social user experience with direct manipulation of virtual objects. Most designers have experience ether with a single user looking at a smallish screen and manipulating objects with a keyboard and mouse, or, in the case of mobile, a single user directly manipulating virtual objects on a small screen. A responsive tactile and broad visual environment like the one provided by PixelSense is in danger of being dumbed down to a plain, unexciting solution because it is unfamiliar. Microsoft publishes the “Surface 2.0 Design and Interaction Guide” to help designers exploit the potential of PixelSense.
3. It’s not free. Although costs vary by market, the current retail price of the SUR40 is $8,400 per unit in the US. Add to that the cost of app development and, while the price is not exorbitant, deploying multiple units is expensive enough that the opportunity to generate buzz, attract customers, and leave them with a positive customer experience needs to be likely enough to justify the investment. In other words, don’t just do it because it’s cool, do it because it addresses your marketing objectives.

From a marketer’s perspective, I see three main advantages that PixelSense offers:

1. It’s a digital product that engages people in the physical world. You can put it in a retail environment, an office, or public space of any type and customers and prospective customers can and will engage with it.
2. It’s fun. The highly intuitive, visually attractive, and tactually engaging nature of the interface makes it fun to use. It generates consistently positive customer experiences and some of the magic rubs off on the sponsoring brand.
3. It generates buzz. When people hear about it they want to see it. When people see it, they want to try it. When people try it, they can’t help talking about. It’s a magnet for attention, customer engagement, and word of mouth buzz

PixelSense is worth considering as part of any marketing campaign that needs to reach out to customers in the physical world.

Samsung SUR40 for Microsoft Surface Venue Readiness Guide

Microsoft Surface 2.0 Design and Interaction Guide

Microsoft PixelSense Web Site

I was catching up with a creative director friend of mine yesterday in her favorite French bistro, when she paused to reflect on the last few years and said “I never would have imagined you’d be doing what you’re doing now when I met you four years ago.” She knew me as a technology analyst for Info-Tech Research Group, covering mobile/web design, development, and outsourcing. We were discussing a significant change in my career that I want to share with you, since it may also provide an opportunity for some mutual benefit.

As an industry analyst, I’d noticed the following marketing trends:

• Marketing budgets have been steadily drifting towards digital approaches and now also towards mobile.
• It is sometimes difficult for agencies, whether digital boutiques or full-service shops, to get the technical talent they need, when they need it, at the price that keeps their pitches competitive.
• Some agencies responded to this challenge by outsourcing digital and mobile development. In some cases it’s been very successful. In other cases it’s been problematic, with problems often related to communication difficulties or cultural misunderstandings.

In the same time period I covered app/web development outsourcing to offshore locations like Latin America, India, and the Philippines. During field research in the Philippines I was surprised by the high caliber of technical talent, strong English communication skills, and cultural affinity with the West. It occurred to me that these resources could be used to provide agencies and media teams the talent they are looking for. So after consultation with ad industry leaders, and drawing on extensive research and my hands-on experience in software development, I launched Code Crew.

Code Crew is a mobile and digital development shop offering a white label service to ad agencies, media teams, and creative boutiques. Our development center is in Manila and we use local production analysts to help define requirements and manage projects. Services include the production of mobile and digital marketing materials such as branded mobile apps, mobile and conventional web sites, HTML5 ads, kiosk apps, PixelSense apps, etc. We already have a substantial portfolio and a solid team with deep experience (see Code Crew).

Moving from Canada to Manila to launch Code Crew was certainly not something I’d imagined doing back then. But it’s been a fascinating experience and I’d love to talk to you about it, and the benefits it could bring to your agency or media team, either online or face-to-face during our roadshow.

We’ve organized a roadshow to meet clients, colleagues, and prospective clients. It’s a chance for me to learn about new ways people are using mobile and digital marketing technology, share the market intelligence I’ve collected, and find opportunities that are mutually rewarding for Code Crew and our agency partners.

Below is the schedule and I will also attend Advertising Week in New York, so that’s another opportunity to connect:

• London: Sept 3–6
• Toronto: Sept 24–28
• New York: Oct 1–5 (at Advertising Week), Oct 8–12 (office meetings)
• San Francisco: Oct 15–17

If that sounds like something you’d like to do, please contact my Communications Director, Anton Estrada with a few times and dates that are convenient for you in the time frames above and he’ll organize a meeting.

Anton Estrada, Communications Director

1 800 334 4904 ex 800