Getting Hired – Part 2

I’ve done technical hiring for some years, hundreds of CVs and interviews. There is no magic in getting hired. There are techniques, some preperation and then hiring is a number game – given that your skills are in any demand. But some people – especially fresh from university, do not know some very basic things.

This is the second part of the series, the first part can be found here and contains:

  1. Where to Work
  2. Job Applications
  3. Survive the HR Filter
  4. Is your CV ok?
  5. Code samples

6. Do I really want to work there?

Do you really want to work at that company? Many people see this as a given. But you need to check out the company especially during an interview. The company does present itself to you as an employer, not only are you presenting yourself as a potential new employee. Ask questions (see below) which will help you decide if the company is right for you. Money is not as strong a motivator - especially long term - as you might think at first. See what I wrote in Developer Motivation and Satisfaction and what might get you demotivated:

Technical reasons like no recent hardware, inadequate tools and a frustrating enviroment. [...] Micro-Management and drowning creativity

I've been doing hiring for quite some time now and I'm still astonished how few candidates want to see their work space and colleagues. You will spend more time there and with them than at home. Are there windows? Is lighting nice? Two 24" flat panels? Decent computers?

It's also not fair starting to work at a company and then walk away if the environment doesn't fit you. The hiring manager probably took quite some time to recruit you and has sent off other excellent candidates. Decide before you sign the contract if the company is the right thing for you.

7. Things to know about software development processes

One of the biggest impacts on your job, your satisfaction, your day-to-day work is the software process the company has installed. There basically are two process models to follow: Waterfall or Agile (this is an over-simplification). Waterfall has larger time spans and iterations, there is a focus on up-front planning, writing project plans and execute those plans. Agile is about smaller iterations, usually two weeks and getting things done in micro steps.

From my experience Agile works more often than Waterfall works and is easier to do. Most Waterfall environments I've worked in failed in a spectacular way, meaing no deadlines were held, long working hours, unsatisfied customers, product mangers and developers, the second half of a project being very often in firefighting mode. Agile I've seen more often working. There are many Waterfall and Agile processes, the most important to know for Agile is Scrum. Scrum is easy to learn and easy to implent (at least to get 90% right).

As said before, the chosen process will have a very large impact on your work, so you need to decide if the process the company has implemented is right for you. To give you a small insight into Agile I wrote in "What Developers Need to Know About Agile" what Agile means for a developer:

  1. Much less crunch time
  2. More working on features
  3. Less meetings
  4. Pull not push
  5. Be a critic
  6. Agile makes you happy
  7. Responsibility as a team
  8. Agile is about working, high quality code

Agile does expect something from you though: As stated above it demands being a critic and taking responsibility. This often means teamwork and a high level of communication. Agile teams communicate a lot, many of those communications outside of the team. So if you want to get your work items and write some code and don't be bothered, then agile is not the right thing for you. You will be more happy in a waterfall environment. Agile is not for every developer I've learned.

8. Interviews

There is one thing not to forget about interviews: The company needs to hire someone. It's not only that you want a job. So the company presents itself the best way possible. This is not a one-sided beauty contest for developers. The company needs to sell itself to you. And you as a developer need to decide if you buy.

The second thing not to forget: Interviews are a number game. Even if you're very good, the company probably has more comparable candidates. As they often need to decide on one candidate, and you're out, this does not mean you did not make a good impression. So even if you're good you need to take several interviews. This is a number game.

If you have several interviews, go to the dream company first or last? There are points for each, when experience with interviews I would go to the dream company first. If unexperienced I would go last. Last means you can gain interview experience but it also means you need to keep some companies at it until you get hired by your dream company. And if they do not hire you and the others lost interest, then all options have vanished.

What to expect in an interview? Many HR types will ask questions about your teamwork ability, how you solve problems, how you interact, what you expect from your job. Technical managers or developers will mostly ask three kind of questions: Algorithm questions (Google style of interviews), manhole cover questions (Microsoft style of interviews) and practical programming and technical knowledge questions. You can find them all over the net, I've wrote about Java questions here, here and here as I prefer the third type of interviews.

There is a simple test called FizzBuzz. It goes like this:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

I also use this test or some form of it during interviews. The astonishing thing is this: Many candidates are not able to write this simple program. If you do not understand what happens there or are not able to write a similar simple program, please don't apply for a developer position.

What also to expect? During my interviews candidates need to read code on their own, around 20 classes, understand and document the code with simple UML. Then we go through this code and the candidate explains what happens there. What bugs are in the code? It also delivers many starting points for discussions on code design, code quality, design patterns, Java APIs and many more. Why do I do this? Because reading foreign code and understanding what happens there is a crucial skill for developers - even more the older the company is and the larger the code base.

9. What to ask a startup

There is only one question: How long will the money last you currently have? If they do not answer you, dance around are say something along the lines of less than 6 months, don't join. Beside that there is Guy Kawasaki’s 10 Questions to Ask Before You Join a Startup which is a must read if you plan to work for a startup. Don't be shy to ask this hard questions!

10. Money

Money. Obviously an important topic, most of us wouldn't go to work if they would get no money for their work. During an interview the hiring manager will probably ask how much you want to earn at the job. Should you answer? There are different theories if it's better if you give a number first or the company gives a number first. There are benefits and problems to both outcomes.

Most hiring managers - especially in smaller companies - will press you to produce a number. This means you need to know what you want. And you need to know what you're worth. You should ask around, look on the web for comparable pay etc. Then should you take some risks to demand more? It's up to you but getting a raise later is much more difficult. As I wrote in Top 10 Tips (+1) to Get a Pay Raise there are more rules which apply to a pay raise later on that do not exist during an interview:

There are some general rules when asking for a pay raise, like companies giving out raises only once a year. [...] My general rule: If you did not change in any way in the last year, it’s not very probable you get a pay raise and more money.

Simply the easiest way to get more money is when starting a job. If you start too low, you will always stay too low because many companies have a upper limit on the percentage a pay raise can be. There is a book I suggest you read, it's called "How to Make $1000 a Minute" and deals with the issue of money during interviews.

Hope you enjoyed this second part for it's the last. As always I'm interested in opinions and additions, please leave a comment.

The Dark Side of Virtualized Servers and The Cloud

Virtual servers and the cloud both abstract on hardware and commoditize hardware. Both have benefits and good reasons to use. But both have a dark side, mostly noone talks about. This is a dissonance I feel for some years, people only praising the cloud and virtual servers, while my own experience with those technologies shows significant down sides. To solve this dissonance I decided to write this blog post. After the NoSQL dark side post it seems I run into the dark side of things more often.

Virtual Servers

There is a trend towards virtualization. Most companies change their hardware setup to a setup running their servers in virtual machines on an abstraction layer across their hardware (like VMWare). There are many benefits of using virtual machines:

  • Easier to setup, faster to setup
  • Better utilization for low performance services
  • You can put many servers on the same hardware
  • Easier to provide 24/7
  • Migration to new hardware without downtime
  • and some more

But there is a dark side to virtual machines: Cost and performance. As I've seen many times, everything is put on virtual machines. But virtual machines are not as powerful as running native, especially I/O intensive servers run much slower. From my own experience high traffic application servers running with XEN are 20% slower than running native. So you will need more hardware for IO heavy servers to achieve the same, which means more cost. Also if you do not use an open source setup - which few people do for windows servers or in the enterprise - you will need to pay a lot for licenses. The marketing machine runs full steam and promises nearly no impact when virtualizing servers. This simply is not true. The Riak server configuration description writes:

Like most datastores, Riak will run best when not virtualized. Virtual machines (VMs) can suffer from poor I/O and network performance, depending on how they are configured and the environment in which they run.

Also some admins think they magically can put more VMs on the same hardware without adding resources. Seen this over and over again, admins putting more and more VMs on the same hardware, often to go green and reduce power consumtion, and users complaining more and more about performance. This fails as all VMs will run slow. It gets worse the more VMs share the same memory or CPUs. It is possible to put several low resource VMs on one piece of physical hardware instead of putting them on their own hardware. Also if you have VMs which need the most power at night (e.g. map reduce) and VMs which need the most power during the day, then you can easily share them. But VMs are not a magic bullet to reduce your hardware costs. You need to balance the benefits of virtual servers with the costs. And never put more VMs on physical hardware than it can take.

The Cloud

Everyone seems to move to the cloud, Reddit is one example:

Last week we also decommissioned the last of our physical servers. We are now operating our entire website "in the cloud" as the kids would say. Specifically, we are using Amazon Web Services. If all went well, you didn't notice a thing. If you want to, you can Ask me Anything about the move or our servers.

There is a deeper discussion on Reddit with some numbers about their move:

218 Virtual CPUs 380GB of RAM
9TB of Block Storage
2TB of S3 Storage
6.5 TB of Data Out / mo
2TB of Data In / mo

and says about the costs - which sound rather expensive for 156M cachable pageviews:

Right now about $15K/mo.

and

Yes, it lowered the cost by about 30%, and with their new lower prices, should make it even cheaper still.

which made me curious.

It's cheaper, it's cheaper the CIOs, CTOs and other IT managers chant in unison with cloud providers. But the dark side of cloud is the costs, for most users. The cloud is more expensive.

So I wanted to compare the cloud, in this case Amazon EC2 (there might be cheaper offerings from Linode and Rackspace) with a provider I use. The hoster sells i7 machines for $95 or $120 per month. According to a HN thread, one commentator estimates an i7 to be 12 - 15 CU. Comparing

  • EQ6, i7-920, 12 CU, 12 GB, 5TB traffic, $95 month with $200 setup costs
  • EQ8, i7-920, 12 CU, 24 GB, 5TB traffic, $120 month with $200 setup costs
  • L, 4 CU, 7.5GB, 4TB OUT, 1TB
  • XL, 8 CU, 15GB, 4TB OUT, 1TB

For comparing the costs, I've calculated three models. 5 servers 100% of the time, 5 servers on demand, and 15 servers on demand with a short peak.

5 Application Servers Example

Model 0
5 app servers, 100% usage on EC2.

Model 1
5 app servers, which get you quite somewhere as a startup from my experience.

Distribution 5 for 5 hour peak, 2 for 10 hours, 1 for 9 hours which means

  • 2 server 42%
  • 1 server 100%
  • 2 server 21%

Chart with 5 servers

15 Application Servers Example

The third model (Model 2) is adding 10 servers for a 1h peak (5%).

Chart with 15 servers

Comparing all prices get us this (no load balancer etc taken into account, no storage, different payment models):

Table with different pricings

You can see that if you utilize the servers 100%, then EC2 is between 2x and 3.3x more expensive than renting servers (Model 0). Additionally looking at the CUs the EC2 images are less powerful than rented hardware, so you probably need more of them. If you run a diverse utilization setup (Model 1), then the costs are between 1.75x and 2.6x higher. But the comparison also shows (Model 2), if you have extreme peaks (500% normal operations, 15 vs. 3 servers) then adding those 10 servers only costs you $1400 more per year and for the L version is much cheaper than renting 15 servers. But the margin is much smaller with the XL setup, it's only around 3% cheaper (but with more flexibility). Only if you have even more extrem models, running in the cloud gets significantly cheaper than renting servers. And perhaps you need less people, so TCO is lower with the cloud - depends on how many OPS you do not need. And you need to take databse servers, load balancer and others into account which need to run 24h, so 1 server might not be enough for 24h service. The same when you run a world wide business, as you need the power mostly all the time, 24 hours.
(and some claim, buying servers and colocate them is the cheapest option, but with the biggest upfront costs).

If you grow fast, from 5 to 10 to 50 servers in one year, it's much easier to add capacity if you're in the cloud, instead of on rented servers. Most providers need some days for your hardware to be set up - which can work for you with a partially predictable business model and a little bit of planning.

And perhaps Joel York is right when he writes:

Let’s face it. CIO’s don’t win awards for saving money. CIO’s win the praise of their companies, their colleagues and their user communities when they deliver better capabilities faster than the competition. It is time savings, not cost savings that is driving cloud adoption.

Conclusion

Calculate hard what you do and if it's cost effective for you. For many companies the cloud is the future due to the benefits. Don't lie to yourself, virtualization and the cloud are no magic bullet. If you do not need it, don't buy it. Do not go to the cloud just because it's hip.

If you have corrections, find errors in my calculations, have different calculations, can explain the 30% Reddit cost reduction, have different opinions or insights, I would appreciate if you leave a comment. Thanks.

Getting Hired As A Developer – Part 1

I've done technical hiring for some years, hundreds of CVs and interviews. There is no magic in getting hired. There are techniques, some preperation and then hiring is a number game - given that your skills are in any demand. But some people - especially fresh from university, do not know some very basic things. I try to clear some of those up.

1. Where to Work

It is of utmost importance that you know what you want.

IT is a very big field. You need to know what you want. Otherwise you will not look determined during interviews and will become unhappy later. Perhaps you need to experiment. Working as a developer, system administrator, devops? Choosing a management or a technical career? Working in a startup, small company or in the enterprise. Additionally there are three main kinds of work in the IT industry:

  • Consultancy
  • Products
  • Projects

There are pros and cons for each of those and there are mixed work modes. As a consultant you will earn a lot of cash, get around a lot, learn many things, see many projects and technologies. But you're on the road a lot, living in hotels, always being the outsider and nowhere near sane working hours. Projects are between consultant work and products. You will see new technologies, it won't become boring and there is a lot of excitement. The downside? A lot of pressure, deadlines and customers who seem never to be satisfied. Products offer different things. Steady work. Sane working hours. Sometimes deadlines but often not as pressing as in projects or consultant work. You will see the result of your work used by customers which is very satisfying. You see your work evolve over time which is a nice feeling. You can learn more about software processes in product development hatn in projects and consultant work. But technology change will be slow and payment usually is lower too.

What company to work for? Startups, small companies, large ones, Fortune 100 companies, international mega conglomerates? There are trade offs. Most often the larger the company the more money you can earn. The more secure is your job. Access to larger projects, more influental products, big brands and bigger resources. But often the larger the company, the larger the bureaucracy. Change won't happen fast. Things are the way they are.

Smaller companies offer more freedom, change can and will happen. You will get more responsibilty faster, perhaps job descriptions are written especially for you. There is energy everywhere. But your job may be at risk in a startup, your pay is lower. What's the right thing for you is for you to decide.

2. Job Applications

In many companies there is a candidate filter which is human resources. This HR filter will filter candiates for various reasons. The right for existence being the promise to reduce the workload on the hiring technical manager. Additionally if your CV goes into HR it lands in a queue.

The fast track is around this HR filter. Find someone who you think could say YES to your application. Where to find those? Listen to tweets on twitter, read blogs from hiring managers like team leads, heads of development, VP of engineering or CTOs. Directly contact those on networks like LinkedIn or XING. Ask if it does make sense if you send her your resume and if they are interested in good - or excellent - developers. After you get a yes, send your resume. Even if you need to go through HR, add the name of the manager you've got the yes from. This will pull your CV through the filter.

3. Survive the HR Filter

If not jumping over the HR filter, you need to get through it. Important here: Keywords and Buzzwords. They most often just filter for buzzwords. I always suggest to adapt your CV to the company you apply for (see next point). This is especially important with skills.

  • Read the job postings of the company, what skills do they want?
  • Look at the company and their projects, what skils do they need?
  • Talk to HR what they are looking for

Go through your professional life - or university life - and see what skills match. Put those skills up in your skill list and also provide them in the cover letter. But do not overdo your skill section. John Fuex writes in Your resume. It’s the little things that hurt:

One of the most effective ways to portray yourself as a novice or one-trick-pony is to pile on the trivial details when describing past jobs or projects. [...] but remember that a resume is a brochure, not a biography. The prime objective of a resume is to get you booked for an interview, not to close the sale.

What skills are similar to the skills the company wants? Put them up too. If it is a Java job, do not put your PHP skills to the top. Think about what Java frameworks you have and put them into your CV. This will probably get you through the HR filter. Think hard about what skill to put on the top. Put the disruptive ones on top, not the 'me-too' ones. Whitney Johnson says:

Translating this to our careers, when we proffer to the marketplace a disruptive skill set, focusing on our distinctive innate talents rather than 'me-too' skills, we are more likely to achieve success and increase what we earn.

And I do wholehearly agree. But do not lie, this will surface during an interview, or worse later during the job when you are supposed to do things you have no clue and they fly in your face. As Lee Miller writes in Lying on your resume today may hinder your career in the future:

Career coaches advise the individuals they work with to market themselves in the most positive way they can. That should never, however, include lying or exaggerating one’s accomplishments, skills or experience.

4. Is your CV ok?

If your CV lands into my inbox - please use one PDF, no zip, no word, not 20 files, although all applications will be processed - it should not contain the obvious problems. If your resume looks like a fit, you will get a call, irrespective how bad your CV is formatted. That said, typos are annoying, let someone proof-read your resume. Gaps which are too big are suspicious, but I do admit those are not very important to me. The same goes if you're too long out of jobs.

More convincing are your skills. But I do look where they come from. If your resume doesn't explain in experience where all those impressive skills come from, it looks fishy to me. Large skill lists and no experience (job, open source, ...) are a warning sign.

Are your past engagements too short? Unless you are a consultant or have specific skill for a special company phase, lower than 2 years looks also fishy, once is ok, twice looks dubious, more than twice: Are you a job hopper? How long will the recruiter be able to hold you? This might not be an issue if you're hired for a specific project, change or transformation like mergers.

5. Code samples

If someone requests code samples, send them. If noone requests code samples, send them. They give the best impression of your work and if they are good, put you at the top of the other candidates. Even better if you supply a link to one of your projects on Github (or similar service). As Matt Biddulph writes in Algorithmic recruitment with GitHub:

When I’m hiring, one of the things I always want to see is evidence of personal projects. Over the last two years, GitHub has become an amazing treasure trove of code, with the best social infrastructure I’ve ever seen on a developer site. GitHub profiles let the user set their location, so I started with a few web searches for Berlin developers.

Slate writes:

In a hiring climate in which companies find talented workers by seeing how they already perform, the RethinkDB founders turned to sites like Github.com and stackoverflow.com, where programmers collaborate and work on special projects. "You can see the code being written and how technically accurate they are," said Glukhovsky, who inhabits a world where 95 percent of coders can't complete basic computer-science tasks.

I often hear candidates complain about the work they need to do to supply requested code samples. I'd assume everything up to 4 hours of work for a job you really want is ok. If you do not want to invest that amount of time into your dream job, why should the person hiring you think you will commit yourself to the company? The submitted code should be bug free, be well documented (The why, a little bit of how but never the what) and have unit tests attached (or BDD). Reread the code, make it the best you've ever written.

That's it for the first part. The next part will include process, what to ask a startup, what to ask a company and some tips. What tips would you give for getting hired? I appreciate all comments.

Why Diaspora will FAIL

I think Diaspora will fail. What is Diaspora?

The privacy aware, personally controlled, do-it-all, open source social network.

I should back up my bold statements with some arguments. First, the code quality seems to be very bad and the developers seem not to be top notch - something I assume is necessary for such an ambitious project. Steve Klabnik writes on his blog:

Basically, the code is really, really bad. I don't mean to rain on anyone's parade, but there are really, really bad security holes. And they're there due to things that any professional programmer would never dream of leaving out of their code. [...] But then, the more I read, the more bad things I found. They're going to need a complete overhaul to fix this. Go over every last piece of code. And don't even get me started on their encryption code."

Although Steve wrote the post to rise awareness and wants to help

"I'll be submitting another patch or two, but it needs much, much more than I can give."

I'm not so sure this is the right way. I think there are deeper and more fundamental problems with Diaspora.

Diasporas deeper problems

When I first heard of Diaspora, I imagined a decentralized , P2P system running on every computer. Then when the iaspora developer release was posted and I took a look at the FAQ I was astonished. It would only run on dedicated servers (or your desktop should it be a dedicated server):

We think most people will use some sort of hosting provider to host their seed. This could be a traditional web host, a cloud-based host, an ISP, or a friend.

Which is a shame, because I assume 99% of users will not have such a system accessible.

I would have imagined Diaspora as a Peer2Peer system based on software running on local computers which gets replicated and encrypted. Or is running on a phone. I was disappointed when hearing it was running Rails - which is hard to scale when you do not control the system or stack - which happens when people download the software to their own system. It also makes Diaspora available only for a very small minority of Facebook users. Some suggested using virtual images to achieve this, but from my interactions with VirtualBox and VMWare, this is way beyond most users.

Another point is interaction and communication: Inventing their own protocol could be good, because they can adapt to their usecase. But protocol design is hard, so this has a high probability of failure. Why not use XMPP? We will see how fast it can evolve and if the developers make the right decisions.

Why not use CouchDB and run a CouchApp? Store data local, replicate to your other computers. Or replicate it to phones. I'm sure phones will be powerful enough to run a P2P Diaspora version in the future when traffic costs are no longer an issue. Phone CPU power and memory haven't been an issue for quite some time now.

Perhaps I'm sounding harsh and negative, but I'm just really dissapointed. When we wrote the SnipSnap wiki software 10 years ago we envisioned a completely decentralized P2P version running server less on every computer. We were not bold enough to implement the vision, and tools weren't ready. So perhaps I envisioned Diaspora fulfilling this, which it doesn't.

Final Words

Taken together I'm dissapointed and do not think Diaspora will succeed. There was so much potential, a Rails application does not fulfill it. Identi.ca has the same fate - it might be a sucess as a niche communication system for some users and the creators, it failed as a Twitter replacement. Also on a note: Why did Appleseed not succeed? Is Diaspora better than nothing? I'm not sure. For now I'll stay on Facebook.