Recruitment - A different take

Growing as a company could sometimes be difficult.
You need to be able to recruit people (Or outsource them, which will not be handled in this post), train them and get them to be productive as fast as you can.

For a small startup, this is even harder - Every position counts, and every worker might be responsible for great success, or miserable failure. This can make the recruitment decision a very critical one.

For our next recruit, which should be a tier 3 support engineer, we've decided to handle the process a bit differently.

First, we decided to describe the typical workday for the position. What the person would do when he comes to the office, which would be his tasks, how would he work. We write that down.

After that analysis, we focus on what he (Or she) needs to know in order to perform his tasks. It could be deep knowledge of our product, SQL know how, MS Office skills or whatever. Divide those skills into skills he would need to know "From home", generic skills that could be taught, and specific (Our product) know how.

Once we know that, we can actually start looking for the right person. The search would be much more focused, as a lot of skills which you might consider as prerequisites will be shed during the process.
We would also have a clear training plan for that person.

In the end, I love to say that I'm looking for excellent PEOPLE - As most skills could be taught.

Happy hunting!

School yourself!

The tech world is all about tech fashion. Buzzwords come and go, new OSs, frameworks and stacks come and go, but sometimes, instead of learning the 'framework of the moment', you would want to learn some completely new fields and skills.

Luckily, this is really easy to do these days.

Udacity, founded by the head of Google X (Google's futuristic project lab), offers plenty of courses, all of them free. From web development to parallel computing, it's all there, neatly packed, with tests, certificates and all.

General Assembly offers video courses, some free and some paid, and focus more on design and entrepreneurship.

10gen, creators of MongoDB, have 3 great courses on database, from programming to scaling and maintenance (Of course by using mongo...)

There are plenty of other resources online - Just pick what you want to learn, and go there.

Spending 2 hours a week expanding your horizons and skills - It's worth it, even if just for the fun and challenge.

Want to get rich by creating a killer app?

Well, you most likely won't.
There aren't many companies making direct money from selling app in either iOS or android devices.

Let's do the math.
Suppose your app costs a buck per user.
Now suppose your app has a million paid downloads.
This means 1000000$ in revenues.
An average app would cost you 100000$ to make. (Most cost more, some less)
Now take out Apple's 30%, your of making the app and taxes, and all that's left is ~300000$.

While no small change, this isn't exactly retirement money.

However, if you could sell your app to 1 million users, you're probably doing something right - and get the attention of some big companies, or easily fund your next app.

Still not convinced? Let's do some simple math then.
Apple has given app developers (Up to now), ~4 billion dollars in revenue share. Divide that by 4 years since the store exists, and assuming that the cost of a developer is 100K$ per year, this means that in average, 10000 people (A year) are making their living from this revenue.

The others are losing their (Or other people's) money.

But now let's think of a different strategy:
Make it free, and earn from... well... um...

Not everyone could make lots of money from apps. Actually, except for high end games or the occasional hit, no one does. Most companies have app driven services and value, which generate revenue - That's a more probable model.

So the next time you've got a brilliant idea for an app and want to consult the techie that would invest 6 months of work for 50% shares, think what you're really offering him, and don't be offended if he politely says 'no'.

;-)

Of programming and expectations

We all have a lot to learn.
My first programming job was a 'lone' programmer in a group of testers, writing telephony test simulators.
The activity was successful, and after two years I found myself with two workers, making wonderful stuff happen, and changing the way my company works.
After trying, unsuccessfully, to be a beta program manager (Too early for a 25 year old kid...), I was given another programming job, this time under a guru.
The first two months were looking quite good. Re-brushed my c++ skills, got my confidence back, made some stuff happen.
Then came the evaluation talk.
And I got my ass handed over to me.
Seems that I wasn't quite that good, according to my boss. Messy, hard to control, over confident, lots of bugs etc.
I was quite angry after that conversation. Felt like kicking his ass. Luckily for me, I had the whole weekend to relax. And then I understood something. This was actually my first job programming. In the phase before that, I had no one to tutor me. I got great results, but I was the one setting the expectations, as there were none...
So instead of explaining how wonderful I actually am to my boss (Who obviously thinks a bit different), I need to give up my ego, and start learning from him. He was not the one they would fire if I'm not up to par with his expectations...
So I've asked him to accompany me in my next mission, step by step, and make sure I will not fail.
Break down my mission, set expectations and success criteria for each mission.
I know how to write code. I just need to align myself to his methods. And who knows, I might even learn something.
In that particular case, I've learned a whole lot. Both professionally and personally.
The past year I had to give up on a good programmer which chose the other way. After he got handed over to another group, he decided to quit, in the middle of a version.

There are many types of programmers. But the ones team leaders like the most, and are most likely to promote, are the effective ones: The ones who can make the biggest impact, not necessarily the most efficient ones, the hard working, or the more thorough ones. These are great qualities, but they are not enough.

I will elaborate more on how to be an effective programmer from both the manager and programmer perspective, in my next posts.

y.