Target your prospective employees

This is the fourth installment in the Interviewing series. The first three can be viewed here.. Part 1, Part 2, Part 3

How do you target your prospective employees? The answer is.. the way you target your customers.

Go where they are most likely to be..

Are you looking for good programmers to join you? By good programmer, I mean one who can code. No.. not just write code, write code which is readable, maintainable, well tested and easy to change.

Where are you looking?

Job site

If you think job sites would provide you with such people, all I can say is keep trying.. someday you will find them. Its just too much effort to find one good programmer from a herd of resumes. Too painful and not very rewarding. And by the way, good programmers have started to remove their resumes from those sites. Thus your chances of finding one is made even more difficult.

Recruitment Companies

All I can say is.. well.. I can say nothing. They’re supposed to find you a good resume. I’m sure if you close your eyes and pick a resume from a pile, your chances of that being a good one will be equivalent to the ones filtered by these companies. And bonus.. it won’t cost you anything.

Go look at..

1. Technical conferences

2. Programming community (online/real-world)

3. Open source code bases. (github,, and so many)

4. Gaming channels/forums (well.. atleast 50% are into virtual reality)

5. Twitter and stackoverflow. (There are some serious folks out there..)

Once you’ve found a few developers who you would like to have in your organization, what do you do?

1. Torment them with joining calls from your HR/calling staff.

2. Send them endless emails about sending their resume to you.

Well.. enough. You’ve already lost him. Now, let’s try something else

1. Have a chat with him about his interests (in programming and other things..) whenever you meet him.

2. Host a session on programming and invite them for a talk/session. They’ll respond willfully.

3. Host a session that matches their interest (gaming/social networking meet/others..) and invite them to participate.

4. Have an open-office day. Invite people from outside to come and visit your office. Let them have a look at how you work.

5. Constantly seek feedback from them. What do they like about you? What they don’t like about you..

Believe me.. you won’t need a formal interview after all this.

Its not easy. Certainly not. But the chances of finding a good programmer are much better this way. Certainly better alternative to a 1-hour interview session.

Why I did not build my first product..

Couple of years back I was at this job at a software company building stuff for large enterprises. Regular day included writing large modules of software with no vision of who’s going to be the final user of the system. We would mostly be provided with a spec and all our development would be centered around it. This would get fairly mundane fairly quickly and then starts this long wait for the project to end and next one to begin. In all likelihood, the way outsourcing projects work, the new project would be similar to the last one, except for different people.

All the time, there were few ideas growing in my head to start a software product on my own. It gained constant momentum and in few months I had two more people interested in one of the ideas. There started this journey of my first startup.

The Idea

The initial idea was to make a platform for fashion designers to showcase their talent and share it with the world. This would be a part of community where people would visit profiles of different fashion designers and choose among them. This would enable even middle-class citizens to select designs and accessories, helping the budding fashion designer community too. Sounded a great concept. With this in mind we started our research. I was still in job when we started this.

The Research

We needed to get the opinion of fashion designers on this concept and also of the potential buyers or middle-class fashion enthusiast. We started with the fashion designing community. This led us to different parts of our country and to some really odd/funny looking fashion designers too.. We figured few things from our research:

1. Fashion designers won’t put their stuff up on the web easily.. since there’s lot of plagiarism in their industry and they do it themselves too 🙂

2. There isn’t really a community of fashion designers. Well at least, as far as we knew.

3. From the buyers side, one always wants to touch and feel their clothes before buying them. so they wouldn’t really buy online (unless it’s from a brand)

4. We really sucked in the skill required to talk to those fashion designers. Just two different worlds.

(This was just our assessment of the situation from our limited research. The inferences may not hold true for all people, I may add. )

This just meant, we had little interest from suppliers (fashion designers), consumers (online buying market) and we totally did not understand their language. Nothing was going for the idea.

Guess what.. we dropped the idea.

During the Process

There was this other thing that was happening while we are at the whole research thing. We were meeting lot of business people and we were getting exposed to lot of real-time problems that they were having. Some went like managing their demand and supplies, working out their cash flows, working with illiterate people, and handling their sales team effectively. Hang on.. lets zoom on the last point. Handling their sales team effectively.. Wasn’t that problem solved already by all these super Sales Management applications? Apparently not. They themselves are a problem most of the times.

So during our research for our first idea, we came across all these things and ignored them first. Once we dropped our initial idea, we looked at an alternative and there was this interesting situation.

The first idea, we were passionate about, but we did not know our customers or consumers. We lived a different world. The next set of ideas came directly from the customers (or people/companies with problems).  We figured that the best way to go about was to solve the problem that we knew about and had a customer to help us out in testing the solution.

The Product

So, out came Lead Simplified. A platform to help manage your sales leads. And in next few months, we had the product out in the market and implemented with a dozen customers. Now Guess what.. It worked. It solved the exact problems that they were having and did nothing more. It started growing and people started referring our product to their friends and circles and we started getting many enquiries and suggestions for more features to be included. We were pretty overwhelmed with the response.

This was the product  in its 5th month and we started getting inquiries from the biggies of the country. Not something that we were prepared to handle.

This concludes my point and rest of the story is for later. The point is:

The Conclusion

Our first approach started with an idea in head and then doing the research on that. The second started with some research already done and the product was based on a problem communicated by the users themselves.

Both these approaches have something in common. ‘Knowing your Customers/Users’.  The first one, we did not. The second one, we did.

Are you able to draw the characteristics of your users correctly.. absolutely to scale?

Do you know the pitfalls of the industry you’re targeting?

Is there really a problem that you’re trying to solve?

Never guess.. Just ask them.

The key is to just go out there and listen. Talk to people. Listen to them talking. Try to solve problems that people actually have.

Also, while solving it, constantly keep checking with them if you’re in the right direction.

Now.. go out there. Talk to your customers.

working for vs. working with Customers.

[tweetmeme source=”snarayan” only_single=false]

Customers are always right.

Customers know what they want.

In my career with customers ( and I’ve met a few), I’ve concluded that both our previous statements are not entirely true.

One thing that is true is, Customers have a problem to be solved. And When they hire consultants or vendors, their plain expectation is that they’d solve it.

Most of the times, customers can define their problem fairly clearly. Other times, they don’t. But lets ignore the latter ones for this post.

Ones who’ve managed to define the problem, also seem to have an idea of a solution. A solution that would work, not necessarily the best solution to the problem.

This is where consultants/vendors come in.

There are two approaches that are possible from this time on.

1. Consultants can try to reach the actual problem, and propose multiple solutions either supporting or contradicting customer’s idea.

2. Consultants can just help in executing the conceived solution for the customers.

This is the crux of the title of this post. First point is what I would like to call “working with” and the second one as “working for”.

I’ve always believed that if you have a part in designing the solution for the problem, it becomes dear to you. The level of dedication goes up a notch. This doesn’t necessarily mean that your design has been chosen as the one, it’s just that you’ve been part of the process of arriving at a solution is the key. You tend to relate to the problem better. You tend to feel a part of the solution. End Result, you perform better.

I’ve not been totally convinced with the second part. Its like a Hit-man at his job. He gets a phone call.. a picture of the person to kill.. and he goes kills him.. done. Engineering doesn’t work like that. There are many things that go into executing a solution. Morale and Passion are a big factor. If you lack that in you or the team you’re working with, be ready for mediocrity. That is what it would result in.

So you decide what you want to do.

Work with customers and relate to their problem. Deliver a solution to their actual problem (which may be better than they had thought. Exceeding expectations) or

Work for them. Deliver the solution they asked for (which may not be a solution at all). In this mode you’ll be doing great if you match expectations. Most times you’ll fail to do that too..

Modern organizations, work with customers. They’re much more concerned about customer’s investments, and most importantly.. they believe in delivering a solution that actually works.

Pluggable products.. competing by collaborating.

[tweetmeme source=”snarayan” only_single=false]

A while back, I wrote about competition and collaboration being tied to each other in today’s market place. That was directed towards organizations collaborating with right partners and competing in the space. Recently, I’ve been looking at a similar trend in software products. Its very difficult to separate collaboration and competition. In fact, as ironic as it seems, collaboration has become an essential requirement in today’s competitive environment.

We need applications that integrate seamlessly with other web services like twitter, facebook, flickr, etc. A standalone application is just not good enough.

We need applications that expose themselves through apis, so we could build plugins over them. Few years back, it would have sounded totally absurred to have applications which expose themselves to the outer world.

Think about it this way. You have a product. Of course you’d like people to use it. That’s the reason why you have a product at the first place. Now think about what would make it more interesting for your users.. More features. Well.. not necessarily extra features, but some improvements on the existing product. As a single provider, it’d take you enormous cost and time to try and deliver all by yourself alone. You’d need an additional hand. Expose apis and allow people to lend you that hand.

Its almost like outsourcing some of your development to external developers for no cost. You don’t just get some of your features done, but you also get another perspective on your product, which in certain cases can really change your product itself.

There are certain products like Mozilla Firefox and few other who have created a certain sticky-ness just because of their plugins. Lot of people don’t migrate to other browsers just because they don’t have the plugins that they’re used to in firefox. There are also products that are adding all sorts of new integrations to lure their users. Google Maps, Twitter, Facebook, Flickr, iPhone, Android, and the list goes on..

Ok. So the message is.. if you’re building a product, think about pluggable architecture right from the initial phases instead of building it later.

Sometimes Strength is their greatest weakness..

[tweetmeme source=”snarayan” only_single=false]

Its odd, but true. Really. Many companies suffer because they did not evolve their business models at the right time.

We’ve heard of companies that fail very early on, in the startup phase, because of lack of a strong business model primarily. But, in current day and age, it is not enough if you’ve made through that phase. In the face of competition, first mover advantage is restricted to very few domains. Certainly not software.

Its essential that company evolves its business model, considering the state of economy, political structure and basically the environment. Many companies make the perennial mistake of sticking to their assumed strength for too long. Yes, I don’t mean to say that one should not value their core value proposition, I’m saying that one needs to continuously keep evolving it.

It’s about continuing to innovate in every means possible, and building that innovation around your core abilities.

When companies get bigger, they tend to be more focussed on their core abilities, simply because it is difficult for them to innovate and grow at the same time. Hence we see a trend that most innovation come from smaller players, who have little to lose and are willing to go that extra mile to build something that breaks the predefined rules. And naturally, bigger companies are found wanting.. playing the catch up game in the competition.

Recently, there has been lot of movement in this space. Many companies have tried to redefine themselves. Companies that have always been very traditional about their business models are getting out there and trying newer things. It is for the benefit of everybody. Those who are not doing it, they better have a very good reason for not doing so.

Coding. Interview as a Service – Part 2.

[tweetmeme source=”snarayan” only_single=false]

This is a continuation of the Interview as a service series. You can visit the part 1 here, where I talk about some of the common shortcomings in recruitment process of IT organizations.

Well.. to jump directly onto the subject, Coding. How many organizations have coding as a standard practice in their regular interviewing process? To your surprise, not too many. It is absolutely mind-boggling to how one can recruit programmers without actually testing their programming skills.

Programmers are supposed to program. Code. In any language, but Code. That is a absolutely non-negotiable. Any concept, any theory, if it is not demonstrated through code.. it is not correct. It is not good enough if one talks well, is well dressed and knows few technical buzzwords/jargons floating around in the industry. We’ve seen such folks struggle to write even the simplest of programs. And for all the referral process fans here.. these folks have lot of friends like themselves. They will refer everyone. No doubt about it. So you end up having a fantastic team of programmers who can’t program. Not program even if their lives depended on it.

This decision has to be made by the organizations. Do you want such posers in your system? If your answer is we’re fine with it, you can stop reading further. This one is not for you.

Ok. If you’re still here, I believe you understand the importance of recruiting right programmers. One of the important exercises to be done immediately is add 1 or more coding exercise in your recruitment process. Start with a simple problem, one  that requires some of the programming constructs and ask them to write code for it. Not pseudo-code. Actual program. Make sure the problem contains atleast 2-4 constructs like conditional logic, looping, modularization, data structure, etc.. as one sees fit. An example could be, from a list of numbers give me all numbers that are divisible by 3. As simple as that.

Look at how quickly one gets to solve the problem. In my experience, good programmers would be solving this the minute you’ve finished your question. Speed is not necessarily a measure of quality but can be treated as an indicator.

This is fine if you need just programmers. How about requiring good programmers? Do you need them? Yes.. ok lets go about doing it then.

Present a problem that involves more programming constructs and add a bit of design into it. You’d like to see how one goes about arriving at a solution. What are the approaches he takes. What are the approaches he doesn’t take, and reasons why. It can be a really exciting experience when you carry this exercise with a real good programmer.

I’d suggest doing this on premise and actually going through the whole process of arriving at solution. Thats the best way to do it.

One of the other approach I’ve seen is sending the problem to the programmer and ask them to submit the code. After submission, on premise, discuss with them about their choices and practices.

If you go with this approach, I’d rather suggest submitting code katas, screencasts.. This would give a nice idea of how a programmer goes about doing his job. How comfortable is one with his editor. What shortcuts does he use to get the job done. What classes he comes up with, etc..

To summarize, to build a good or even decent software organization, you need to focus on the kind of programmers you let inside. Better the programmers, better the kind of services or products you provide.

Going to office or going to work?

[tweetmeme source=”snarayan” only_single=false]

Really, where are you going?

I’ve been thinking about this for quite a while now..

I spend about 1 hour 15 minutes to reach my office from home. That makes it about 2 and 1/2 hours daily.  On a five-day week, this sums to 12.5 hours (equivalent to 1.5 days of work). So as per figures, I lose 1.5 days of work time per week for a totally non-productive thing.

Now add money into the equation, if my per-day salary is about 2k, i’m losing 12k on a monthly basis (which is 1/4th of my overall salary). Thats significant money and time. Quite significant.

Ok. Enough of numbers. So.. why do we then go to office?

I’m of a firm opinion that it is absolutely essential that we utilize this time more effectively. And, it’s not just me. I see more and more companies are realizing this and are offering a alternative plan to their employees. Some even feel that offices would be “history” in few years to come.

We need to make some major changes to our mental setup to change this..

1. Need to identify better ways to measure work.

2. Communication facilities need to improve

3. Need better planning

4. Need to be sensible about collaboration and utilize time more effectively

5. Need to get more self-organized and self-employed style.

Of course, I agree that all nature of work do not permit this. But especially in software, its absolutely perfect. Infact, there’s a whole industry which works on remote communication. It certainly can work and work well..

Let’s stop going to offices. Let’s start going to work.