Wednesday, November 23, 2011
Thursday, November 10, 2011
Tuesday, November 08, 2011
- The screen has better colors than the Nexus S. The iPod Touch screen is brighter and crisper.
- The iTunes integration is perfect. Musically, I live an iTunes life. doubleTwist is an inconvenience versus staying in iTunes. I've never synced a podcast to my Android devices - I have no clue how.
- In the same vein, automatic conversion of high bitrate songs to 128 kbps AAC is convenient.
- The iPod Touch is thin. Sure, the iPod Touch lacks phone hardware, but darn, every time I pick it up I notice its thinness.
- The touch responsiveness is better. Every once in a while, I need to lock-and-unlock cycle my Nexus S to have it recognize when I lift off my finger. No such issues on the Touch. (Maybe I haven't dropped the Touch as often as I've dropped the Nexus S!)
- Software consistency. It sucks that carriers put their own layer over Android - software I think doesn't make user experience better. It sucks that carriers and manufacturers don't upgrade older devices quickly or often.
- Availability of third party devices for iPods is high. (eg: iHome, hotel alarm clocks, in car integration, Garmin ANT+ adapter)
- Many applications are iOS first or iOS only. (I wish Android had a Chipotle app.)
- The keyboard always displays capital letters, even when shift isn't selected. (I miss Swype a lot too, which isn't native Android, but replacing the keyboard isn't possible on iOS.)
- Lack of turn-by-turn directions in Maps.
- When an app loads, and it has multiple prompts, I see the first prompt, then immediately see the second. I have to respond to the second prompt before I see the first prompt again. It's a jarring user experience; the prompts should be serial instead of going over each other before a user can react.
- Prompting users for permission for push and location services on first app load is distracting. I'd much rather do that on app purchase/download like on Android.
- The iPod connector insertion is awkward. I keep thinking I'm breaking something.
- iOS presents the ability to sync with Gmail and Google Calendar from the phone, but not Google Contacts. (This is way better than it was on the 3G, where I had to do IMAP and iCal syncing manually, but still sub awesome for the legions of Gmail+Calendar+iOS users)
- Calendar and Gmail didn't background sync by default. They're pull systems - I understand that they could be push if I dug deeper, but that's annoying.
- At some point, the home screen instructed me on how to rearrange the apps. However, I'd already done that a few times.
- To change settings on some apps (and most iOS apps), you have to go to the Settings application. Why do I mentally have to context switch do change settings in the app I'm already in?
- I miss the hardware back button. Each app seems to have its own convention about how to go back. (On the other hand, at least in iOS it's clear what back goes to.)
- The screen doesn't get bright every time I turn the display on.
- The address bar / search box differentiation on the mobile browser is silly. Apple: please steal that from Android or Chrome.
- I need to authenticate repeatedly. I had to type my password to download a free app.
- There was no way to discover what "iTunes Match" was from the settings dialog asking me if I wanted to turn it on. (Much of the iCould stuff seems slapped on)
- I miss widgets - desktop items that aren't simple app launchers.
- Apple charges money to take songs you've already purchased and crop them to ringtunes.
- App store policies and platform rigidity / control. Why can't I replace the keyboard? I wish it had deep Google Voice integration.
- Where's Siri? Why is Siri iPhone 4s specific?
- Fanboys. Actually, that could be true for both iOS and Android.
Friday, October 28, 2011
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems.It's not a perfect test of an engineering organization, but it's a great minimum. It's great for being over a decade old - but at a decade old, some of these seem painfully basic to me now (source control and bug database).
- Do you use Google Apps, or at least Gmail and Google Calendar?
- Do you deploy at least once every other week?
- Do you love your and respect your designer?
- Do you have a Twitter account that replies to users?
- Do you have design docs for major components that resembles reality?
- Do you have a wiki that employees use?
Thursday, October 27, 2011
- Ability to translate a problem into components.
- Ability to reason through a problem and feel the solution.
- Ability to keep trying and go deeper on problems unlike ones she's seen before.
- Ability to translate these solutions into code.
- A bag of tricks (data structure knowledge, technical knowledge) and the intuition that says "I bet there's a better way to solve this problem, I just don't know it yet."
- Ability to build stuff.
- Technical flexibility (can a SQL expert adapt to NoSQL? Can a Java person learn Ruby?).
- Attitude. Is the candidate going to mesh with the team? Are they going to make coworkers' days better or worse? At Google, this was "Googliness".
- Simple set up. The question needs to be intuitive and you can't spend 15 minutes for the problem set up.
- Bounded solutions. There's probably going to be one or two efficient ways to solve it.
- Non-esoteric solutions. Priority queues are awesome, as are tries, but they're rarely used outside of algorithms classes and algo interviews. Questions mostly come down to: divide and conquer, dynamic programming, hashing, merging, binary search, sorting, and iteration.
- Find a way to have candidates build something during the onsite. I don't have the answer yet, but the closer to real work candidates are doing, the better the interview will be.
- Ask design questions. Not design patterns esoterica, but problems that almost beg the candidate to say "This is like something I did before! We solved it doing ..." and then asking about the other tradeoffs the person has made.
- Ask questions that speak to grey (technical) issues. Ask when they'd choose between GWT and jQuery. Ask when they'd take their HashTable and throw it into MySQL, and when they'd go from MySQL to NoSQL and MapReduces. See if they've gotten the feel for products they've developed before instead of simply hacking at them.
- Get a feel for the candidate. See if it's someone you'd enjoy working with when the server's been down for 3 hours and you still haven't figured out why.
- And yes, still ask some algo questions. See if the candidate has the gut feel of when to use HashSets, or if they're only into brute force solutions. Ask for the runtime - if someone really gets the solution, runtime is trivial.
Wednesday, October 26, 2011
- Visit the Frank Lloyd Wright houses Fallingwater and Kentuck Knob. (I've never been to Kentuck Knob - it's a shame since it's 7 miles from Fallingwater)
- Visit Kennywood. It's the best old-time amusement park in the United States. Their halloween evenings ("Phantom Fright Nights") are great.
- Visit Sarris Candies in Canonsburg. The ice cream parlor is old timey and the milk shakes are fantastic.
- Visit Phipps Conservatory. Heck, go several times. They do a great job changing the flowers for the seasons - I love the Christmas poinsettia display, I love the butterfly exhibit - I pretty much love it whatever they do. And I'm not a flower guy.
- Go down by Heinz Field at night - preferably when there's nothing going on across the river. The city by night across the river is serene.
Tuesday, October 25, 2011
You may have read Steve Yegge's Google-sucks-at-platforms rant. I have no real opinion on it since platforms are not my forte. And I agree with him on a lot of positive things he says about Google in the run-up to the rant bit. It's easy to write about what Google does poorly because of the huge number of things they do well.
This isn't meant to pile on, but I do have criticisms about the way some things work at Google.
- One product, many leaders: Product teams usually are functionally aligned instead of product aligned. The PMs report to a PM VP and the engineers report to an engineering VP. The eng VP and PM VP have different priorities. And there are other roles: marketing, communications, support, design. There won't be a clear, unified product vision that management and employees are on board for - so teams can't be nimble and push forward. (Google has always had YouTube as a "business unit" where people across roles report up to one VP/GM/Director, and they've expanded it to other products, but it's not universal.)
- Too many cooks in the kitchen: The New York Times wrote an entire article about this: The Auteur vs. the Committee. Google does a great job of listening internally - every employee is encouraged to give feedback on every product. But at a certain point, a product needs to do some things well and figure out, in the future, what next to add. And that hurts feelings - employees often felt unseen and unheard when a product goes in a direction they don't like. I believe that before a decision is made, employees should work to make sure the best outcome happens and after a decision is made, employees (from CEO to individual contributor) should fall in line behind it.
- Managing out poor performers: Google is too easy to remain at. If you're a bottom 5 percentile performer, why would you chose to leave? You probably got in through a mistake in hiring, and you're probably not going to get as good a paying or perked job elsewhere. So you're going to milk Google until you can't milk it any more. High performers, who could go anywhere, hate working with low performers. Google knows they do a poor job managing people out, but is timid about getting rid of people. There's a delicate balance - cull the herd too hard and employees start getting stressed.
- Industry isolation (technology): There's too little knowledge of what else is going on in the industry. This argument and complaint has been made by many Googlers before - most Google internal technologies are a generation behind what the industry has come up with in terms of features. C++, Java, and Python are Google's 3 big languages. But none turn on the 20-something startup-bound engineers. Sure, Google infrastructure can scale, but it can't replicate the speed at which engineers at other companies can add features.
- Industry isolation (products): It's a company with hundreds of products and 31,353 employees (pre Motorola). It's hard to keep up with what's going on just in the company - and many employees don't have the energy to figure out what the trends are in the rest of the industry.
- Good but not great products: Google products are guaranteed to have many users. That's keeps new products from having tons of users. The PMs and management are playing it safe - trying not to fail - instead of making pure products that might win and might crash and burn. Instead of building intuitive, simple, useful products that do a few things, they're making products that do many things without engaging the user. Yelp, Foursquare, Strava, Gmail, and Google Search all started by doing one thing extremely well. What did Hotpot or Plus launch doing extremely well? On the other hand, Google is doomed by high expectations and high attention in this space - launch early with few features, and users may be disappointed. Those users won't give the product a second chance.
- Listen to their own support people: maybe this is because Helen is in consumer operations at Google, but I still think it's true. If Google's billion users all had one customer service request every three years, and each request took 10 minutes, Google would need over 20,000 support employees. But the issues that Helen deals with are the same issues, day in day out. They're fixable if the engineering will were there to fix recurring customer issues. But product people generally don't like blending engineering resources across new features, bug fixes, and customer enhancements. I love working at engineering centric companies, but I love more having happy users and customers.
- Hiring (employee side): Each interview took about an hour and a half - 15 minutes of set up (read resume, tweak questions), 45 minutes of actual interview, and a half hour of feedback. Doing full interview feedback on someone who bombed the interview was painful and demoralizing - at one point, I was allowed to write two sentences about why the person was a poor fit and moved on. Eventually, I was asked to do full feedback even for the worst candidates - I saw no benefit to it, and boy was that sucky.
- Hiring (future employee side): Want to pick what you work on? Nope. You'll get slotted. Start at Google, wait 12-18 months, and hope to transfer projects. I hate most ads (Google text ads for products usually excluded). I'm not working to put more ads out there. Ads are distracting and dehumanizing. During the recruiting process, candidates often don't know what's going and probably feel like a number. I recognize hiring at scale is a hard problem, but why isn't there a JobScore equivalent where candidates can log in, see whether they're waiting on recruiter communication, interview scheduling, interview feedback, hiring committee, etc?