How to choose the best software engineer?

October 15th, 2014

Ok. It’s interview time again. And another candidate sits on the opposite side of a table.

What qualities are you looking for? My guess that you want it all and you want it now. However candidates which satisfy all of your requirements doesn’t come too often.. As result, you will have to prioritize what’s important to you.

My take on it is following. I want to see three qualities:

Smart

Frankly, if person isn’t smart enough then anything else just doesn’t matter. A person can be hardworking, experienced and so on, but at the end of the day he or she will be just a liability (decreasing the value of a company vs increasing it).

Passionate

it’s unbelievable luck If you found somebody who is passionate about your cause. Such person will move mountains for you. However, there is a pretty good chance that there won’t be too many people who are truly passionate about cause of your company (especially, if you are classical enterprise b2b). And I believe it’s better to hire a person who is passionate about something (vs non passionate person).

Passionate person is used to spent each free minute on something interesting to him and as result he is used to get into “zone” really fast and be super productive. Getting into “zone” is a skill and I would rather get a person who continuously trains this skill and can apply it at the work.

Get things done

If I had a penny for each smart software engineer who can’t complete straight forward task I would be rich by now. It amazes me how many software engineer have attention span of 1 year old jumping on anything new any shiny.  Each company need some level of jumping and fire fighting but the core of the company should belong to people who move needle forward whether it snows or rains.

That’s kind of it.

I hope at this moment you say: “Hey, how about experience?”

Frankly, experience is overrated (especially very specific experience). I saw smart/passionate/get thing done engineers figuring out new stuff within couple of month way better than seasoned veterans. Way too often companies choose experienced person with dull eyes who just want to get their paycheck and get out of build over less experience but way more passionate engineers.

I would say, it’s important that person had some overall experience but specific area experience is just a cherry on the cake.

 

 

Self-organizing teams – reality or myth?

October 13th, 2014

A lot of agile methodologies (including Scrum) relies heavily on a notion of self-organizing team.

First of all, everybody talks about it but nobody puts a good definition what is self-organizing team. As I understand self-organizing team notion was introduced as an opposite  to a team which is organized externally (a.e. by manager). The main idea behind it was that smart people tend to find the best way to work together (vs being told how they should do their work).

Good in theory. Bad in practice.

Let say we have have a team. Most likely, couple of members of this team will be quiet introverts who don’t want to organize (rather they would prefer to be organized). There will be several more junior team members who may have not enough experience to organize effectively. As result so called “self-organization” is done by one or couple opinionated (and usually experienced) persons on the team who drives the team in one direction vs another.

On top of that, there are couple of interesting questions (specifically related to Scrum):

– Does a team decides what it should do? The answer is No (Product owner does)

– Does a team defines an overarching process? The answer is No (Scrum is well defined process and usually Scrum master enforces it.)

– Is there a person in a company which can override team decision? The answer is Hell yes. The company is paying money to the team, so if the team goes in a wrong direction there will be a person (ultimately CEO) who can override any decision.

What do we have as a result? 

We have a team which doesn’t define what to do, doesn’t define major backbone of the process, can be overridden and driven by one or several opinionated persons.

Frankly, it doesn’t sound as a self-organization to me. It sounds like these several active persons are doing team lead job (without having official title).  I am not saying whether it’s good or bad, all I am saying that the name (“self-organized team”) doesn’t match to the content.

Real agile

May 1st, 2012

I heard about agile about five years ago for a first time and  I started practicing different agile methodologies (mainly SCRUM based) about four years ago.

Just as a side note. “Agile methodology” is an oxymoron. If it’s methodology and you have to follow it whatever happens then you aren’t agile and if it’s agile than you shouldn’t try to define rules written in stone (methodology).

And only now, after 4 years of doing different Agile But, I finally started to work in a real agile environment.

I believe there are two core reasons, why company practices Agile But:

– A company does agile just because it’s a new cool thing and the company wants to get another boy stout badge for being kind-of Agile.

– Some engineers are frustrated that releases are always late and their buts got kicked as result of that.

These are WRONG reasons to do agile. In both cases it’s seen as just another initiative. A lot of people thinks – “oh… well. if it help that’s fine, if it won’t help – not a big deal”. As result, most likely no resources will be allocated to it, no serious changes will be done.

I think,real agile can come only from the top of the company. As soon as owners of the company understand that

– The world is complex thing and any assumptions needs to be checked (the faster the better)

– Resources are very limited and it’s absolutely critical to do most essential stuff first

They formulate very simple idea – being Agile (especially for a startup company) isn’t just another initiative, but rather live or die decision.

Immediately as soon as you decide that’s critical you will know the answers to questions like  why do we need short releases, automating testing, automation builds, get functionality to real Done state, constant prioritization, fighting technical debt and so on. It just sets number of additional positive constrains which pushes you  into correct direction.

Looking for a Android open source developer

April 19th, 2012

SpydrSafe Mobile Security Inc. is developing a solution to make Android more secure and to enable the use of employee-owned devices in the workplace.

We are looking for a senior programmer to conduct research and develop prototypes related to Android security at all levels of the Android stack.

You must have the following skills to qualify for this job:

– Passionate about solving complex low-level problems (any OS platform)
– 1+ year of Android development
– 3+ years of Java experience
– 3+ years of C/C++ experience
– 5+ years of overall software development experience

The following skills are not required but are considered a plus:

– Knowledge of Android operaint system source code (AOSP) – big plus
– Experience with open source
– Experience with Linux internals
– Experience in mobile development (e.g. iOS, Symbian, Windows Mobile)