• Google Launches Shopping Tool in India

March 30, 2010

Google has launched shopping tool that enables you to search for product information [like gadgets, washing machine, TV etc] online in a more structured fashion.

the system scans millions of Indian Web pages and extracts product names, prices and images. With the help of this new technology, Google users will receive information from more than 30 thousand Indian Internet sites and be able to research a variety of products online. – blog

Google Shopping Tool

One can also filter search results based on price range (To try out shopping, hop to Google.co.in and select ‘Shopping’ option on the left sidebar).

Interesting product, and we hope Google launches more of such vertical offering [and brings structure to the G-web, which has been badly exploited by 'SEO experts'].

Whats your opinion?

• xkcd: Exploits of a Mom

March 30, 2010

Exploits of a Mom

• Yes, You Can Build a Web Company in India. Here’s How.

March 24, 2010

• How To Answer A Programming Interview Question And Look Good Doing It

March 27, 2010

Rather than continuing to talk about how hardcore developers should have hardcore math fu, I’d like to shift the focus a little to softer skills (although, as I said, I will come back to math stuff often). I believe that technical people should place even more of an emphasis on soft/people skills than non-techies (I mentioned this in one of the comments to my last post). I will expand on my reasons for this in a later post. In the meantime let’s just take it as a given and look at the value of these skills in a technical interview situation.

The thing with a programming interview, or any interview for that matter, is the fact that it is more of a conversation rather than a grilling. The company, and by extension the interviewer, has just as much invested in the process as the interviewee and therefore want to get the most information from the time they spent talking to you as they possibly can. Of course, in a programming interview the main objective is to assess your skills, but people rarely make decisions regarding other people (e.g. hiring decisions) based on hard factual data:

Only 70% of your friends rate you as a ‘nice guy‘ and therefore we will be unable to pursue a friendship with you at this time.

Missing a semicolon on the second line of the last question, clearly puts you below the historical 95-th percentile of all candidates, which unfortunately means we’re unable to hire you.

It just doesn’t happen – people mostly go by how they ‘feel‘ about another person based on what is important to them. They may try to get an objective picture of your skills, but no matter how well you think you did, if they don’t  feel like they want to work with you themselves (i.e. they don’t really like you), you will not get a positive report, at best the interviewer will be ambivalent:

He clearly knew his stuff but was a bit of a cold fish. I guess he was ok overall.

Not really the best outcome, ambivalence usually means – no hire.

This does not at all mean that you can bluff your way through a technical interview just by creating ‘good vibes‘. Most technical people value technical skills highly and if you don’t measure up in that regard you won’t succeed. What it does mean, is that you can be in the middle of the pack as far as pure technical skill is concerned, but still come out as the preferred candidate at the end of your programming interview. Some developers (i.e. highly technical/analytical people) may not like it, but that’s just the way it is, dealing with people is not an exact science.

The Objective Of A Technical Interview

A regular interview is all about psychology – can you leave the interviewer with a good impression, can you ‘click‘ with the person in the short time that you have. A technical interview should be all about technical skill, but people are involved, which means regardless of what you might like, it is still as much about psychology as it is about technology. The objective is to answer the questions to the best of your ability, while at the same time giving the interviewer as much positive clues about yourself as you can, to allow them to form a good overall impression. The impression is just as important as the answers you give. To that end here is the process I would use when answering a programming interview question which will allow you to not only give yourself the best chance of answering the question correctly, but should also give the interviewer a decent feel for who you are and how you work. If you disagree with any of this, or have other tips, do leave a comment.

The Process

The majority of technical interviews onsite, consist of answering a programming question on the whiteboard. I don’t like it either, but we work with what we have, so this process is geared towards that.

1. When you’re asked a question, don’t try and jump straight into writing code unless it is truly trivial. It’s not a race, sit and think about the question for a little bit. This shows the interviewer that you’re not a “cowboy” and don’t go off half-cocked to try and solve a problem you don’t yet understand. To help you understand the problem…
2. Use the whiteboard. A picture is worth 1000 words so use the whiteboard to draw the problem as you understand it. At this point you should be talking to the interviewer to make sure you both have the same view of the problem; the picture will help with this. This also gives the interviewer a chance to clarify the question if necessary. From your point of view, you’re talking and eliciting requirements, the value of this should be self-evident. Don’t fill up the whole whiteboard with pictures, you don’t want to have to wipe your diagram as it may be useful later on for debugging purposes.
3. Don’t be afraid to start over and keep talking. You should be chatting with your interviewer throughout, to keep them engaged and to allow them to understand your thought process. As you’re coming up with a solution you may start writing it up, but if you find that you’ve gone down the wrong path, or come up with a better solution, don’t be afraid to start again. Keep talking, tell your interviewer what you’re going to do – this gives them a chance to point you in the right direction if they think it necessary, or stop you before you waste too much time (if you’re completely off base). All of this should not only demonstrate the fact that you have decent coding skills, but show that you’re a good communicator, can reason logically and can recognise when you’re wrong (and take the appropriate steps). All of it helps the interviewer form a positive overall image of you. If you just stand there silently writing or thinking, you get none of those benefits. Infact you do the silence thing for long enough and it can get a little awkward, which is the last thing you want.
4. Take your time, like I said, it’s not a race. If you’re taking too long the interviewer will let you know, otherwise assume you have all the time you need (this should also help with stress if you’re prone to panicking during interviews). As you’re thinking, don’t forget to do some of it out loud, I can’t stress the importance of walking the interviewer through your thought process enough. When you’re actually writing the code, take the time to consider things like boundary conditions. Many technical interviewers are extremely pedantic about stuff like null checks, I personally wouldn’t be, but it takes little time and better safe than sorry.
5. Don’t be afraid to ask questions or even ask for hints if you’re stuck. The interviewer will often have some prepared anyway and will be happy to give them to you (i.e. you won’t lose too many ‘points’). If you don’t remember specific API details, let the interviewer know, they will either tell you or let you know that it is not important. This demonstrates that you know what you’re talking about while at the same time don’t get hung up on the details.
   

   If you’re stuck (but think you should know the answer), don’t panic. Stressing-out is one of the worst things you can do in any interview, it just isn’t the best image to project. Iterate over steps 2-5 again. It will probably be obvious that you’re under a bit of pressure but equally obvious that you’re taking it well – not a bad thing for an interviewer to know about you. It also shows that you don’t give up easily .

6. When you’re finished, you’re not really finished. Remember what I said about interviewers being pedantic about null checks and boundary conditions, now is the time to make sure you don’t get caught out by this. Walk through your code and find any potential bugs, use the examples you drew in step 2. This demonstrates thoroughness and – chances are – you will find a little bug or two (which even the interviewer may have missed) which looks good. If you’re short on time, at least tell the interviewer that you would have liked to walk through the code.
7. Demonstrate that you know what you’re on about and didn’t just stumble on to the solution by accident. You can do this by telling the interviewer a little more about your code, consider things like, strengths, weaknesses, running time (big Oh). You may also mentioned other potential ways to solve the problem and any improvements you would make if you had more time. Chances are the interviewer was going to ask about this stuff anyway, but preempting displays professionalism (you’re aware of the issues and what is required) and the ability to think about the problem at more than just a superficial level.

Some Extra Tips

• Don’t write too small on the whiteboard, that can be really annoying (too large is usually not an issue, but watch for that too). If you’re writing is of a decent size and you’ve run out of whiteboard while still being nowhere near the end of the solution, you’re probably missing something, go back to step 1.
• If you’re into TDD it may help to think about the problem in a test first fashion. What would you test in order to solve – and go from there, it may help get you into your normal flow.
• Books like How Would You Move Mount Fuji? may be a bit of a cliche, but are worth reading for the insights into the mind of an interviewer (and it certainly won’t hurt to be prepared if someone ever does ask you THOSE questions) and how to leave them feeling positive towards you. Another good one is Programming Interviews Exposed for more technically-minded questions/tips.
• If you don’t know the answer and none of the hints help (in short, if you have no idea), don’t try to bluff it. Just admit it and move on, you can ask the interviewer to explain it later if you have time. As far as I am concerned, it is unfortunate that you couldn’t answer the question, but you get points for being man enough to admit it, after all, noone can know everything. It is obviously not as good as solving it, but is better than nothing and a damn sight better than trying to bluff it, the interviewer is not an idiot (and even if they are, pretend like they’re not) they’ll see through it and that’s an automatic fail.

This is how I would go about answering a coding interview question these days. Looking at it from the other side, if I was the interviewer and someone went through this kind of process I would rate them pretty highly (unless they couldn’t actually answer ANY of the questions ). Doing all this allows you to demonstrate your coding skills, shows that you’re a good communicator, have decent people skills, work well under pressure are thorough and generally personable. Compare that with – “He was ok. He solved all the questions.” – big difference.

Images by urban don, pvera and Sugarmonster

Related posts:

1. The Best Way To Interview A Developer
2. An Interview Question That Prints Out Its Own Source Code (In Ruby)
3. To Code With Or Without Music That Is The Question

• China vs uncensored Google

March 23, 2010

Silicon Valley and India have a cozy relationship, but a big question has resulted in friction, failed companies and millions in losses: When will the Internet catch on in India in a big way?

A few companies have done well and a few more are coming up, slowly but surely. But there are hardly any true breakout hits.

RedBus is pretty close. It’s essentially an Expedia for bus tickets in India. It sells about 3,500 bus seats per day, is the fourth most-trafficked Web site in India and has at least tripled its revenues year-over-year. The company sells seats for roughly half the bus operators in India, and that’s saying something: This is an insanely fragmented market that had next to zero centralization just a few years ago.  All of this has been built in three years on about $1 million in venture funding. (The company raised another $1.3 million in 2008, but it’s still in the bank. Investors include Helion, Inventus and Seedfund.)

I can vouch for the company being cheap. Having spent my morning in the plush eight-acre Infosys headquarters, the offices of RedBus were a marked contrast. They are split among two buildings located in one of those very chaotic Indian neighborhoods where vendors are shouting, cows are wandering and smell of open sewers is not too far off. It feels far from the sanitized, steel-and-glass rows of multinationals.

None of this is intended as an insult– co-founder and CEO Phanindra Sama is proud of his cheapness. (Sama is pictured above, sorry it’s so blurry. My camera was having issues.) We met in a no-frills, un-airconditioned conference room. He didn’t turn on the air conditioning for famed Silicon Valley Indian entrepreneur Kanwal Rekhi, when he visited last month either—and Rekhi is an investor in RedBus.

Despite the sweat trickling down my forehead, arms, legs and back throughout the interview, I didn’t want to leave. What Sama and his two founders have pulled off in a short period of time with little funding in India is impressive.

Background for Americans: There are two kinds of buses in India—those that make stops and have ticket-takers on board and that go to one destination only and sell pre-paid tickets only. There are some 3,000 operators of the latter category and, before RedBus, there was no way to contact them directly. To get a bus ticket, you went to an agent. That agent only had inventory from a few bus lines. To book the ticket, he or she would call one person who was in charge of booking every seat on that particular route. There was a long wait time, and frequently the routes the agents knew about were sold out – meaning you had to change your travel plans, or find another agent who had different sources. Meanwhile there was no standardization on pricing and commissions. The agent simply wrote the cost on a piece of paper and if you wanted to ride, you paid it.

Now, RedBus has a central database that gets seats from half of India’s bus operators. It has done so well that it powers the bus ticket applications for most of India’s more general travel sites like MakeMyTrip.com. It also sells an OpenTable-like software-as-a-service product to help bus companies manage their own inventory and better integrate their inventory with RedBus. In terms of seats, it sells less than 1% of the 750,000 rides taken daily, but with several channels and few other easy options, there’s a ton of room to grow a big company.

Sama didn’t set out to build a company. I know that’s a cliché with startups these days, but it’s a rarity in Bangalore where the glamor of being a Web entrepreneur runs high and plenty of TechCrunch-reading kids save up money, quit for a year, try to start a company, and go back to a multinational if it doesn’t hit quickly. When RedBus’s mentor first suggested the company raise $1 million, Sama gasped. He hadn’t even thought in those amounts. His only immediate thought was: “If I had $1 million, I’d put it in the bank and make interest.”

That mentor was Sanjay Anandaram formerly of Neta, Wipro and other ventures known between the Silicon Valley and Indian entrepreneur communities. Sama met Anandaram through TIE’s JumpStartUp program. Despite the reach, influence and press of TIE—the uber-Indian networking organization started in the Valley— Sama is the first entrepreneur I’ve met in India who gives it this much credit for his company’s survival.

Specifically, he cites Anandaram’s advice. When RedBus was trying to sell software to the bus lines, it was Anandaram who said: Don’t keep trying to sell the same thing, ask what they need and build that. The bus lines needed to sell seats. So RedBus built a site, and bought the inventory itself from the bus lines to list on the site. Once it proved it could move seats, the operators were happy to pay the company a percentage of seats sold.

Once the company could prove results, it was Anandaram who warned them to undersell expectations: Tell an operator you can sell one seat for them a month, even if you think you can sell fifty. If you sell two, you’ll be a hero, not a disappointment. RedBus has carried that over to fundraising, admittedly forgoing higher valuations because it didn’t want to oversell and under-deliver.

That’s harder than it sounds for an entrepreneur, who is usually the single most bullish person on his company. And it is absolutely shocking in India’s startup culture. I had a blog network tell me on my last morning in India – with a straight face – that it would be doing double the revenues of Gawker in a few years. I like to give entrepreneurs the benefit of the doubt, but I also know the media business. Forgive the generalization, but Indians just love to over-sell. It’s deep in their trader heritage. “You have to sacrifice your ego,” Sama says.

But, especially for a startup in India, the most important piece of advice Sama and his co-founders got from Anandaram might have been this: You are not an Internet company. Because the Internet isn’t more widespread in India, there has to be a core mindset that the Net is an important channel, but just a channel. Just under 50% of RedBus’s business comes from the Net, much of the rest is via mobile phones.

And the company invested early in two expensive ways of skirting that Web limitation. The first was building its own network of bike couriers to deliver tickets and take payments, ala the hugely successful Chinese online travel company, CTrip. The second was investing in seven different call centers throughout India, not one central call center. Says Sama, if you don’t localize a call center to local slang, languages, and customs the customer service won’t work.

Seriously? An Indian in Bangalore arguing a centralized, remote call center can’t give good customer service? That has about as much globalization-irony as China’s BYD refusing to outsource any of its manufacturing.

For Anandaram’s part he noted the founders’ willingness to listen and learn from someone who’d been there. He says the biggest mistakes he sees Indian startups making are not seeking advice, being too obsessed with retaining control and not valuing sales, marketing and partnerships.

The RedBus story squares with something I’ve been noticing more in my travels to emerging markets—frequently when entrepreneurs complain about a lack of angel investing or venture capital, what they are really lacking isn’t just the money, it’s the mentorship. This came up in my recent conversation with Pierre Omidyar, whose philanthropic effort, the Omidyar Network, seeks to fund both non-profit and for profit entrepreneurs specifically those in the poorest areas of the world. Omidyar Networks has money it can gives these entrepreneurs, thanks to eBay and the dot com boom—lots of money. But what the organization is increasingly finding so lacking is that horrible buzz word “human capital.”

In Omidyar’s own experience, eBay never touched the $3 million it raised from Benchmark in 1996. But the mentorship he got was well worth giving up 25% of the company. “That’s what is so hard to find around the world,” Omidyar says. “We’re increasingly looking at whether $500,000 worth of human capital could help more than $500,000.”

I know that the idea the VCs bring more than money is ridiculed by most entrepreneurs today, but those are usually entrepreneurs operating in a scene that has had an explosion of startups—both failed and successful ones—in the last fifteen years. Even the shiest, most awkward or most unconnected entrepreneurs in the Valley can find a mentor with little effort. Sometimes we take for granted that that’s not the case in much of the rest of the world.

Lucky for RedBus’s founders, they were an exception.