Look at the decorations in the room and the lack of enthusiasm in the crowd…

Hope you all enjoy these fights. As you lay back and munch on some popcorn, Google also serves up a few ads in the video for “Meeting Japanese Women” - because all those pheromones sure put me in a mating mood…

(click image to view fights… )

Be interested to see how your browsers clock in… let me know…

Results:

Systems Used

Total Benchmark Time (ms)

Detailed Breakdown

Actual Screenshot of Test Results

Update: So I’ve heard that the SunSpider Benchmark test is designed to make Safari look better… My actual browsing experience tells me that Safari & Firefox 3 runs about the same. On websites with lots of widgets and embedded content, Safari seems to have a slight edge…

We’ve been sharing a few documents at work lately and I stumbled upon a security “flaw”. It’s actually not a flaw but more of a misleading and not easily accessible feature if you’re trying to achieve complete confidentiality of the shared documents. Recently I noticed that some docs shared in GoogleDocs are viewable by anyone as long as they have the link Google sends your collaborators in the notification email. If you click the link without being logged in, you can view the full document with the following message at the top of the screen:

Although the link GoogleDocs sends out to your collaborators is somewhat encrypted with a long string of scrambled letters & numbers, it doesn’t make me feel safe knowing these shared docs are accessible by anyone with the link.

After some brief experimentation, here’s the solution:

There’re 2 ways to share a doc in GoogleDocs, I’ll call these the “quick share” and the “extended share”.

Quick Share (not secure):

1. In the ‘all items’ view, you can check a number of documents and then click the “Share” button at the top to share.

2. Next, a popup appears promption you to enter emails of those you wish to share with.

3. Then you click “Send Invitation” and the invites are sent with a URL to the document. Notice there are no privacy options here besides adding a user as a “Collaborator” or “Viewer”.

4. The link sent in the email doesn’t require users to be signed in to Google to view the document - the Collaborator/Viewer option is fairly misleading since all non-collaborators have viewer privileges.

Extended Share (this is the secure method):

1. Once you have a specific document opened in GoogleDocs,  there’s a Share button at the upper right corner of the document view. This is the “extended share” button.

2. When you click “Share”, it takes you to a new page with more options than quick share.

3. Under ‘Advanced Options’, you have to uncheck the 2nd box ‘Invitations may be used by anyone’ to have truly secure document sharing. When this option is unchecked, URLs sent in share notification emails will redirect you to the GoogleDocs login screen if you’re not logged in as an approved collaborator/viewer.

Unfortunately the ‘Invitations may be used by anyone’ box is always checked by default and there isn’t a global setting to change the default. Not sure why Google doesn’t have this global setting option or at least put these advanced options in the ‘quick share’ window. The down side to using “extended share” is you can only securely share one document at a time since you have to open each document first before you share. Hopefully Google will implement a fix soon…

This is a continuation of my previous post on recruiting & hiring in a startup. In Part 1, I shared my thoughts on recruiting tactics – Part 2 will focus more on what I believe are qualities to look for in a lead developer for an early stage startup. Unlike recruiting in a large firm, hiring the right people in a startup is critical – there’s no one to carry someone else’s dead weight and everyone plays a vital role in the success/failure of the company. I came from a boutique consulting firm and had the opportunity to be a part of the recruiting process. We had a very stringent system that tested for 3 primary characteristics in a candidate: intelligence, ethics, and fit. These were the same metrics we used to look for in a lead developer.

Our approach to recruiting a lead developer:

1. Find someone that loves our idea

• It’s no secret that we’re better at what we do when we love the work. When we were looking for our lead developer, we wanted to make sure he/she loves the idea, believes in the idea and is excited to work on the idea. If they’re a fantastic developer but not into our idea, they won’t make it good.
• What closes the deal for me is when the developer comes up with ideas on how to improve your product during the interview. They don’t have to be phenomenal ideas now, but I know they will keep innovating in the future as opposed to just building what you tell them to build.

2. Someone who knows what they don’t know

• One of the most valuable pieces of advice I’ve gotten in recent years is that “a part of being smart means knowing what you don’t know”. As I developed my professional career in the past 2 years, I’ve learned a lot about business, analysis & structured problem solving. In addition to that, I’ve learned that even the things I’m good at, there’s a lot I don’t know.
• Relating this to recruiting, we’ve came across a few developers who thinks they know a lot about the business side of thing but were dead wrong on issues and too stubborn to see that. Definitely not someone we wanted to work with. (don’t get me wrong, not all developers are business idiots, I’ve met several business savvy ones)

3. Ability to deal with disagreements & move forward when a decision is made

• In a startup, decisions need to be made quickly and work needs to get done even faster so you can’t afford to have disgruntled, stubborn teammates who refuse to do things another way.
• Disagreements will arise, we wanted to make sure whoever we hired is able to handle disagreements and quickly move forward even if decisions are made against their preference.

4. Ability to not take things personally

• Again, disagreements and arguments will occur & stress levels will be high – everyone is trying to do what’s best for the company so we wanted someone who won’t take things personally when their ideas get shot down.

5. A good fit for the culture of the startup

• At a small company, there’s nothing worse than having someone who doesn’t fit in with the culture. Before we started recruiting, Adam & I sat down and discussed the culture we wanted to build: young, fun, work hard/play hard, high on initiative, low on rules, always do what’s right.

6. Integrity & sincerity

• This is harder to explain since I’m not a psychologist but we judged this based on their responses to questions. Whether it’s a question on how they like to work, how they handle disagreements or asking them to estimate time needed to complete the project, we looked for people who gave us honest answers rather than what we wanted to hear.
• Checking references and asking the same questions you asked the candidates is also a good test.

7. If you’re not a technical founder, get a technical person to help you interview

• If you’re not a technical founder, it’s definitely challenging but not as big of a road block as some make it out to be, just a bit more time consuming. Adam & I share some knowledge of programming languages, website design, IT infrastructure and other basics but we’re not developers. We can’t accurately assess the technical capabilities of a developer so I got a friend of mine who had spent several years as a lead developer at another startup to help us interview.
• However, we did the initial interviews ourselves to make sure we have someone who is a good fit for the culture of our startup.

8. Give the developer equity & don’t be stingy

• Regardless if you’re able to pay a developer at their market rate or not, give them a fair share of equity because it’s a big risk to join an early stage startup – especially one that doesn’t have a single line of code written in our case.
• We came up with 3 different scenarios for a salary/equity mix and allowed our developer to choose the comp package he wanted.
• If the developer prefers a high salary and no equity, don’t hire them. Anyone who believes in the idea should prefer equity.
• Don’t be stingy. Do the right thing and offer a salary/equity mix you would personally accept if you were on the receiving end.