lifehack Featured

Some advice to the programmers looking for a job

Mac Shifford

• 4 min read
Some advice to the programmers looking for a job

Lately I’ve been responsible for finding programmers for our small team. CVs are coming, people do their test tasks, we communicate. Sometimes it goes well, but more often it goes not so well.

I’ve collected some advice for those who are looking for a new job.

Brush up your CV

You should obligatory include the following:

  • you contacts
  • place of residence
  • links to your code (e.g Github)
  • where you worked previously, which tasks you performed, which technologies you used for those tasks
  • education (it is important if required for your visa application)

Sometimes you don’t have time to contribute to open-source, to have you own pet projects or some interesting code which you could leave on Github as an example. Then you can place on Github your test tasks that you have already completed. Of course before doing that you should ask the company if they allow you to open-source the code. As a rule companies do not mind you doing that. If they do object I would think twice before starting to work for them.

Test tasks

I don’t like test tasks. As they are usually uniform 2-5-hour applications which will later be thrown into a garbage bin. So it might be a good idea to have a piece of code that you can show, thus eliminating the need of the test task.

You should do the test task as if it where the best code in your life and such code you wrote on a regular basis. Do not do the test task half-heartedly, don’t waste your time and the time of other people.

While doing the test task pay attention to the following:

  • the code style (there is code style for all the languages, and there is linters for practically everything)
  • instruments/libraries (do you need each and every library in the project?)
  • code organisation (watch your git commits)
  • git commit message
  • tests (TDD/BDD)

The aim of the test task is to find out how you write and organise the code. I have never thought that there are people who are careless about the code style, unless I saw a couple of examples.

I wouldn’t work for the company where such things are of no value.

Job interview

During the job interview the employer wants to know what you can do and you find out how and what you will be doing.

I think it’s a good idea to note down all the questions concerning your perspective work: where the office is and how you get there, employment conditions (in order not to be surprised seeing an old PC having come to the office), etc. And go through the questions marking what you liked and what you didn’t. A job interview is the process when both sides (you and your perspective employer as well) are being assessed. You will definitely be nervous so don’t forget to write down the questions.

Terms, answers, silence

Terms is one of the weakest points of the programmer. When you are going to do a test task give real terms (double your estimated terms, for example). If you are running out of time or something unexpected has happened, inform the company immediately. Don’t drag it out.

You’ve look through the test task and decided not to complete it? Write back and say that you have changed your mind. Don’t waste time.

Sometime it happens that HR and/or companies do not answer and simply disappear. Don’t think that they do that on purpose. They may have lots of people to deal with or something has got mixed up and the letter wasn’t sent. Write back in a couple of weeks and ask how things with your application are. In 99% of cases you’ll get the answer. If you don't, I wouldn’t work for such a company.

Books, career

I’d like to advice you 2 books which made me look at the career of the programmer from a different perspective:

  • The Passionate Programmer - Chad Fowler
  • The Start-up of You: Adapt to the Future, Invest in Yourself, and Transform Your Career - Reid Hoffman

A piece of advice from Denis Lebedev

Resume
  • export from linkedin/headhunder is a warning bell which can mean that the candidate wants to get interviewed without putting any effort into the preparation for the interview. It should be a neatly organised pdf or a Google doc.
  • iOS example: do not write a bunch of buzzwords under each project in your CV (e.g ARC, CoreData, ReactiveCocoa). If the interviewer comes across the word a lot of times he may assume that you have deep knowledge of the technology and will dig into it.
  • never write in your CV things you have a vague idea about. For example: a couple of candidates with “strong architecture skills” couldn’t decode what SOLID is.
Test task
  • the code of the test task should always look better than in production (we are all programmers and we know that your manager doesn't let us write tests and do everything nicely, but in the test task you can and should do everything nicely at all levels)
  • If you are not sure how to interpret task requirements - try not to ask, do the way you think it should be done. As a rule, you apply for a position of a middle or senior developer, and that is the person who can and should analyse the existing context and make decisions. Important all you assumptions should be described in detail in the attached README file. Not at the next stage of job interview ('cause you may not have it) and not in the letter sent through an HR. README file. Next to your code.
  • if you have completed a five-hour task for 2 hours you should ask yourself “where is the joker?”. Find where you could invest the 3 hours which are left. Write tests, catch exceptions, etc.