Monday, 28 January 2013

Tuesday, 15 January 2013

The A Team has A players

I think, we all know that universities' programmes do not conform well to  industry requirements. I would be even tempted to state that computer science and IT are the most vulnerable subjects, in terms of coherence between what is taught and what is required. Basically, teaching too much science can affect industry skills. What I mean is a proportion of industry to science skills (I/S). To my mind, it should be close to 1:1 proportion. In fact, we often observe much higher contribution of science, comparing to industry one. My guess, based on my private research, would be that nowadays the ratio is floating somewhere between 1:4 to 2:3.

To be clear, I have nothing against science. I am even extremely keen on science from my childhood. What's more, I always saw a huge value in being open minded and having analytical skills. 
On the other hand, some knowledge of current, top industry technologies, approaches and tricks is of at most importance. These are your tools. You will be using them on a daily basis. You have to know how to use them!

Okay, rather than grumbling and ranting, let's go straight to the definition of set of requirements and skills necessary in industry. Incidentally, these might be things necessary in science, as well. 
Below requirements were initially defined and put together by Wojtek Seliga, but then enriched in few places by me:

Basic programming skills:
- java.util.concurrent package
- GC (how it works, types)
- Socket programming and threads
- TCP/IP, HTTP (Basic Auth, Cookies, Session)
- Scalability - how to build scalable apps
- Performance - how and when to pay attention for performance
- Transactions - types of transactions
- CAP rule

Java Core:
- interface, class
- composition, inheritance
- collections
- complex types, algorithms
- hash code, searching complexity, putting complexity
- concurrency (thread, monitor, synchronization different approaches, semaphore, cyclic barrier, latch)
- streams
- immutability (thread safe, object pools)
- reflection, AOP, byte code manipulation, generation, dynamic proxy - it explains how dependency injections frameworks, testing libraries work
- Web technologies stack: Struts, Filter, Servlet, Server socket (socket bind accept)

Libraries:
- JDK a lot of classes, on the other hand, not so many to scroll down and eyeball check
- Guava - very good library
- Apache Utils
- Yoda Time - don't use Date and Calendar
- Spring, Nano, Pico, Guice - as dependency injection frameworks

Tools:
- know some IDE (keyboard shortcuts, IDE shouldn't slow you down)
- debugger (not System.out.println all over the place)
- profiler (bottleneck, deadlock)
- internet traffic analyzer (WireShark, Fiddler), FireBug

Books:
- Effective Java 2nd edition (Joshua Bloch) - after reading you think you know everything
- Java concurrency in practice - after reading you think you know nothing


Personality:
- intelligent, smart, active
- willing to change and go out from his comfort zone
- looks for new technologies, experience, A players are not worried to suggest something new, because even if new idea wouldn't work they learn on their own mistakes
- they have high self esteem (often times it's correct)
- they can often find a job
- pragmatic
- there is some 'public track' of them in the internet (forums, blogs, conferences, twitter etc.)


So these are things and topics required by companies from people they are hiring. Now think, how many of these you were taught at university and how many of them you were taught and you know on a decent level. 

Good Recruiter
We were talking about proper set of skills for new joiner. Now let's think about person I call a good recruiter and let's analyze his approach to a candidate. A good recruiter is somebody, who is able quickly and honestly estimate the level of developer. So how they think?
First of all, small companies pays attention for knowledge. Secondly, the most important language in IT is English. It is a sort of must be nowadays and at least good command of English is essential. The candidate should also have a correct financial self esteem and knowledge of market trends at his work. A good recruiter should also check skills, which developer will be using all the time at work i.e.:
- naming variables and methods,
- IDE knowledge, 
- way of writing tests
- refactoring

These are things, which new developer will be coming across on a daily basis and these sort of things should be checked. Please, give me a break with intelligence tests and questions about falling bulb from the skyscraper etc. It's all pointless! Check real skills, which will be used in real life, not some artificially invented questions to show off to the recruited person.



The best boss is the most stupid person in company
There is also a concept of A players. Companies should hire only A and A+ players. 
A players have rightly high self esteem. That's why the best boss is the most stupid boss, as he knows that only by hiring people better than himself, he will be able to build valuable company.
B players are scared a bit. They don't know what other will say. They are a bit lost. B player is hiring weaker, than himself.
C players - misery.

People tend to blindly repeat that developer is the most precious asset of the company. 
If yes, why companies are rising salary when precious developer is quitting?
If developer is so important, stop your most significant project and put the best people (A and A+) to interview, because you can loose cool guy, who is waiting for his turn out there. He will pay off 100 times anyway.

What we see in reality is that companies are sending whoever to interview new, fresh blood to the company. Is it the right move? Is it how it should be done? Definitely not.
If company really truly believes that developer is the most important asset for them, they should use their best people to recruit others. 

Remember: The A team has only A players.