What I Expect from a Developer’s Resumé

This post also appears in my blog on Medium.

On a recent local programmers meetup we discussed the topic of writing a developer's CV in such a way that it allows one to get to an interview past the initial screening. As this is closely related to my posts on interviewing developers, I will cover what we discussed and what are the things, which when seen in a programmer's resume make the team-lead in me eager to meet its owner in person.

For all technical positions the first thing that both the recruiter and the team lead will search in a CV is work experience with relevant technologies and tools. This is the easiest one, because if you have it you just need to make it stand out. To do so make sure that you resume has the keywords that describe the technologies that you would like to work with. While people are quite different from Google search engine, when I look for a new hire I inevitably have to scan dozens of CVs and the easier it is for me to spot the names of the technologies that I need, the higher the chance that I will pay attention to the candidate. Trivial, right? Just remember that you have to be honest about what you have experience with and what you don't - if you're caught lying about these things, you will likely be wiped out from the list of candidates at the same instant.

On the other side, a resume consisting solely of keywords will be even less successful than a resume with no single one. That's because merely "knowing" all the buzzwords doesn't make you a professional, while having lots of achievements in the field of software development does. Here make sure that every job or internship mentioned in the CV lists every one of your accomplishments on that position - ideally, focus on what you have done instead of what you have been doing. Moreover, don't stop on the jobs - remember all the pet projects that you had done alone or with your friends, remember every conference that you talked at and the articles that you have written - all of these underline the experience that you reported and show that you're a person of achievement.

Such activities as pet projects and extra education - an open-source library that you helped to develop or a course that you have taken online - also show that you are willing and capable of learning new skills and technologies. That's especially good if these go beyond your main programming language or framework of choice, because breadth of experience demonstrates your ability to adapt to changing circumstances and employ different mind-models and approaches. Mentioning such activities in a resume also draws a potential employers' attention to one more thing - your fascination with the profession and desire to work and learn beyond your day job, which by itself puts you in front of the crowd.

Another important note is that all of us look for reliable employees, which in particular means that we want them to stay with us as long as possible. Planting a developer into the team and bringing him or her up to speed may take an awful lot of time, so when the process starts I want to be as confident about the result as possible. Essentially this means that a CV consisting of a long list of short jobs - e.g. those under 18 months each - will at least get me concerned. That's not something that you can change about your resume right now, but the thing is certainly worth remembering when you think over your next career move. I don't mean that you should stick to one job for decades, but after you're sort of settled with your career people may expect that you don't change employers too often.

Finally, the resume must allow you to express yourself in a clear and comprehensible manner. In particular this means that you should adhere to the generally adopted standards, such as listing your jobs from the most to the least recent one, displaying a photo of yours and so on. However, there is more to this, because to show that you're a person worth speaking to you must be polite and caring. In written communication that means that you don't brag too much, your language is good, its style is appropriate and there aren't many typos. You will also want to save your interviewers the time needed to find you at Facebook, Twitter, GitHub and elsewhere, showing that you have things to share and don't put crazy stuff up for public display.

It's that simple in regards to the contents of a resume, but I also have a couple suggestions in regards to the process of producing it. First of all, be sure to use external help when preparing the resume. Simply ask a friend, a teacher or even me to review the resume - an extra pair of eyes will spot mistakes and unclear sentences, which will help you look better. Some people prefer to ask a professional to prepare a CV for them. Here I can't advice much as I never used such a service, but it may well be a good move. In my experience, though, having someone proofread the CV is just enough. The last advice is similarly simple, even though less obvious - prepare your resume in advance and always have it ready. You never know when you will have a chance to apply for your dream job and don't want the need to write up a whole new CV to be an obstacle for that. This is not mention the fact that from time to time a friend of yours may run into you shouting something like "We desperately need a good programmer on that project! Could you send me your resume right now?!" More opportunities is better, so be prepared.

As you can see, there is no rocket science about producing a good resume and all of the above advice aligns well with what common sense would suggest. At the same time, if you follow these simple guidelines you will help recruiters and managers spot what they look for in your CV and thus increase your chance to hit an interview.  That's it for this article and I hope that the advice is valuable. If you still have any questions on what to include in your resume, please ask in the comments. If, instead, you have a better idea in regards to what a good resume should look like, be sure to share it here!

Focus

There was obviously little activity in this blog during the recent months and I feel great returning here. The blog always gave me an opportunity to step back and think over my actions and choices. However, this year I was so focused on a single thing - my day job - that only one post had made it here. Now I want to check with myself what this attitude gave me and what it stole from me.

Last February my priorities changed dramatically. In about two months after becoming a team-lead I discovered that whatever I was doing was not enough to do good with new duties. I was both overwhelmed with the tasks and problems that fell on our team and saw clearly that we don't perform as good as we could do. Part of my natural response to this discovery was to ramp up the amount of time that I dedicated to the job.

There are lots of reasons why I'm happy with this choice. Firstly, putting more effort into work made me learn a lot and build up new skills in the areas of my responsibility. Because it was my duty to process all the requests that arrived at our queue, I learnt to do this efficiently and obtained a lot of domain knowledge. In other words, it turned out that it's enough to push me into a partially familiar field and show no way out to make me learn it deeply. My expertise grew enormously over the last year and being really focused on the job helped here a lot (yes, there are lots of things in my field that I still don't know or understand not good enough - I'm speaking only of the delta). Moreover, spending a lot of time studying and resolving various issues - some being totally unclear at first - I not only learnt new areas of the domain, but also developed a skill of learning faster.

At the same time, through spending extra hours on duty I came to see clear that sometimes one cannot address problems by simply working harder. When you do a lot and it doesn't help, you start to see deficiencies and acknowledge the need for changes in one aspect of the job or another. A different edge of this same idea is that one cannot do everything on his own. No matter how hard you try, there is always less done than left to do. These discoveries, combined with high exposure to the issues that we face, constant analysis of our work and search for means to improve it - all of these being enabled by having extra time - certainly brought positive results and helped me develop myself both as a developer and as a manager.

On the other side, the same willingness to work more than 5x9 had a negative impact on the manager role of me, because having more time I could in many cases take the responsibility for any new urgent issue or task. While this attitude helped me tackle problems in time and develop my own skills, it hampered the team's collective progress. Any problem brings new knowledge and shows ways for development, so I simply stole a lot of opportunities from my fellow team-members and hampered knowledge distribution.

Generally speaking, while my attitude helped me grow in terms of knowledge, skills and career, it also shadowed both opportunities and problems. It is a very important lesson for me: whenever one decides to tackle a surge in the amount of tasks by throwing in more (his own) manforce, he misses an opportunity to find more intelligent ways to solve problems and to use them as the points of growth .

These are the effects of the extra work on my job, but there are also those that go beyond my office life. First of all, I left the attempts to do programming and software development in the outside - this means all side jobs and projects. While these used to bring new opportunities and ability to study unfamiliar areas, that's not something that I regret much. Being focused on one area allowed me to grow more than attempts to handle both the main job and one or two similarly looking activities would permit.

What I do regret is that leaving less time for myself I started to pay less attention to continued study and learning new things - both around software development and outside this field. I totally stopped exploration of new programming languages and tools and did much less learning in other areas than I used to - namely, I didn't complete a single online course over the recent months. That's certainly something that I shouldn't have forsaken:  these activities could both help me do my job better and make me expand my knowledge and interests.

Another thing that I dislike is that I quit writing for the blog. Here the reason is not only that the blog has become a silent and lonely place - it was never crowded here. The real problem is that writing less I lost the habit to deeply think over whatever I do and to search for interesting problems and irregularities in my activities. Of course, I do reflect on my decisions and actions, but without regular writing I hardly do it in a systematic and efficient way. Moreover, without posting to the blog I avoid sharing my ideas, which is not a big loss for society, but a shameful cowardice of me.

As with any choice, there do exist both positive and negative sides to putting most of your effort into one area of your life. I see these and despite the cons I am going to continue along the road that I started almost a year ago. However, even though I will continue to pursue that sweet feeling of exhaustion, I do need to make certain adjustments to address some of the problems. In particular I will certainly pay more attention to the supporting activities like learning and blogging - these allow to widen perspective and spot issues that stay invisible when you are constantly inside the problem-solving loop. At the same time, staying focused on my job I will have to pay more attention to the things that I am busy with. After all, being totally occupied with the day-to-day activities is a direct way to keep doing wrong things. So I only need more thinking, more analysis, more writing and the same amount of job. Good to know the solution to one's problems, huh?

Developing a New Feature

I recently finished working a new piece of functionality on my job and it was a whole lot of experience. Even though that's not the first significant feature that I produced and I do know what the process usually looks like, some of its aspects caught me off-guard once again. It is wonderful how many surprises the process of development bears for a developer and how these same surprises continue to happen even after one passes through the process several times.

Of course it all starts with enthusiasm. If you don't hate your job, new challenging tasks always spur eagerness in you. Interestingly, the process of reading through the feature specification and long lists of requirements usually even makes it grow. The same is true about the attempts to lay out the general ideas about the solution and outline each of its components. More broadly, any planning and preparation activities increase willingness to get the problem solved and even despite seeing numerous problems, we tend to maintain motivation and good mood when getting ready for the actual work. Indeed, no matter what, we plan for success and the more we plan the more real it feels even when one sees that there are plenty of issues to overcome. One may even interpret this observation as a bit of advice - whenever you feel overwhelmed with problems and questions it may be a good idea to go and do a bit of planning - even though it might feel like you have already laid out everything, rethinking a particular piece of work might not only help understand it better, but also encourage you to do it.

However, once everything is planned and scheduled, one has to start development and produce some, preferably working, code. While the process usually starts smoothly, on some stage you smash into a seemingly impenetrable obstacle - confusion. Speaking of me, when planning I tend to thoroughly analyze various details of the future solution and study the existing bits of code, but I am not required to produce anything working right away on this stage and can be satisfied with a set of ideas and questions pinned down on a sheet of paper. On the other side, when getting down to implementation one has to squeeze new code into the mass of the application in such a manner that both old and new bits work. The sources of confusion are plenty here: sometimes you will try to add a new line of code in a method only to notice that you need to carry in 5 more arguments for it, which would make the method much less comprehensible and elegant (let alone the case when it is not elegant already). Or rather, you may find yourself in a situation when you want to change a long run of code, but feel that you miss some important ideas about it.

In my case this confusion - or maybe we should call it frustration? - is usually caused by a combination of two factors: the lack of understanding of the domain and imperfections of the legacy code on top of which (or more likely, inside which) I add new functionality. This doesn't mean that I start working on a feature or project without any knowledge of the domain - there's just always something that one doesn't understand and this is the norm. Similarly, the people who wrote the code that I have to work with are usually smart professionals, but their code is good for the task that they were solving - not always for the problem that I am currently addressing. While one cannot escape these difficulties, there is a way to tackle them - in the world of programming this is done well by refactoring the existing program or component and gradually injecting new pieces into it. While refactoring for its own sake might well be considered a bad practice, refactoring as a way to understand the code is a totally different story. Judging from my experience, there is hardly any other way to comprehend a considerably large class or method. Additionally, if you are changing the code anyway why shouldn't you make it more succinct and elegant as well?

Now, let's pretend I have paved my way around first obstacles and tackled the difficulties - what next? First of all, there are first pieces of a reward waiting for me. After I put some time into a feature, my head gradually wraps around it and I start feeling that I am able to address all the problems in a holistic and elegant manner and even make the existing solution a bit more efficient. This confidence alone greatly helps to move forward. Bad news is that these moments of high spirits usually alternate with periods when one notices more and more unforeseen issues. It feels like the more problems you solve, the more of them jump at you from nowhere. Even though good preliminary analysis and planning are supposed to reduce the amount of surprises of this flavor to minimum, they are never totally avoided. Sources might be different: sometimes a customer visits you with a shiny new idea or a forgotten nuance, in other cases you find out that a little change in one place impacts a distant component in an unpleasant way, or maybe you notice that what seemed a perfectly efficient and elegant redesign turns into an ugly muddle in light of a tiny edge case that you missed. The general idea is that one should expect the unexpected, because it always happens - usually in large amounts.

Fortunately, at some stage the task that looked like a mess of deeply intertwined problems becomes manageable and the carefully crafted solution takes the form of a solid thing. You start to address newly found problems with great ease and with even more impressing speed. You know the answers for most questions that one might ask in relation to the feature and to its neighbors. Furthermore, you are able to explain yourself and anyone willing to listen why the answers are those that you give. This is the state of expertise - both in the problem and in the solution (read implementation) - that is by itself a perfect reward for all efforts, weekends spent at the office and even sleepless nights marked with never ending search for a solution to some nasty problem. No matter whether the feature is small or large, isolated or integrated with a dozen other modules, one should feel proud when they reach this level of understanding and familiarity with it.

When the thing is almost done, however, new surprises come in. Like the final of any Hollywood movie provides some clue to a sequel, any feature added to a software product opens the door to dozens other enhancements, improvements and, well, bugs. I thought that my inability to foresee all these consequences is caused by the lack of experience, but it looks like even a group of experts can't always predict which problems a portion of new functionality may bring to existence. This basically means that there is no end to any particular feature or component. More precisely, the development can only be finished when we decide to finish it - you can't just do all of it. While this might feel depressing, there is hardly anything bad about the fact that there is always some work to be done. One should just remember this and be ready to postpone or reject some of the new ideas when they block completion of the feature. This will free you from the current burden and let you analyze all these new pieces together in a calm and reasonable manner. What's more important however, is that this way you will finally be able to mark the work item as resolved in the issue tracker or move the sticker forward on your Agile board, face the sweet feeling of achievement and have some celebration, because the thing is shipped!

While the process of developing new functionality is often an interesting and challenging activity, it might be difficult at times. You should just be ready to find yourself confused, frustrated and overwhelmed. These bad moments are simply a part of the process and their presence by no means suggests that something is wrong with the feature being developed or with you, as the developer. Eventually, these feelings will give place to satisfaction and pride with the awesome component that you deliver and with the new level of expertise that you reach through this undertaking.

The Candidate's Wishlist: Wrecked

After defending the diploma in the end of June I have finally got employed this week. I already feel how the job changes my life and get first benefits from it, but what is more interesting right now is the rapid mutation of my views on working as a programmer.

It is easy to track these changes because before engaging into a series of job interviews back in the last month I made up the so-called candidate’s wishlist – a set of about ten points, which I deemed important in the context of choosing a company to work for. What makes me speak of it here is the fact that some of the items are not fulfilled, though this makes me even happier with the new job.

One thing that I desired is a comfortable office. When composing my wishlist I tried to imagine the place where I would like to develop software: it had an A/C, a coffee maker and a teapot as well as other stuff of this kind – we have all of this. The workplaces with decent computers in my ideal office were distributed across several medium-sized rooms hosting three to five people each. That’s precisely where I failed: we have an open-space. I heard a lot of bad words about open-space and feared it a bit, but now I thank God for getting into this one. Although it makes the boundaries of my private zone elusive – almost non-existent – it is at the same time very friendly and welcoming. Being able to constantly see the colleagues around me working, engaging into passionate conversations regarding our progress and simply striding to and fro somehow motivates and, instead of distracting, helps to concentrate on doing my own job. After a couple of days there I truly believe that the way our office is organized plays a major role in making me a part of my new team – that’s something that, surprisingly, I have never heard about open-space.

On the other side, mere floor and walls – or their absence – can’t do much to improve and make easier one’s interaction with colleagues – that’s the people who make the difference. Upon coming to the office last Monday I found about three dozen interesting and kind men and women there, who are indeed willing to help me to get accustomed to the new job and environment. It turned out that not only my teamleader is concerned about my progress, but also other seniors do pay attention to what I do and, even though I am mostly learning new stuff now, they make me feel that I contribute a little to the progress of the whole company.

Beside the requirements to the office and the presence of experienced developers my wishlist included the desired size of the team – I thought that it should lie somewhere between five and eight people. The company failed this expectation as well – I am actually going to become the third guy working on a project and we don’t expect any more newcomers. At the same time, after the week on job I feel I can’t easily draw a line between our team and the others – we depend too strongly on those who do other pieces of work and they do depend on us to some extent. Due to this fact combined with the close to absolute availability of every colleague provided be the open-space I could say that the size of my team is about 30 developers, QAs and support engineers. This leads me to an interesting idea: the tradeoff between a small team and a large one is actually a tradeoff between the availability of many experienced colleagues to learn from and the ability to focus on a particular piece of work – software in my case – and the corresponding features and customers. It seems to me that the configuration with a very small team nested in a larger one and strongly connected with the latter’s other parts provides me both kinds of benefit. I know there are no silver bullets and free lunches and I might face some drawbacks in future, although I believe I am really lucky to have things laid out this way. Moreover, now I am not sure if organizing the development of the system of our kind is actually possible in some other fashion.

 

In addition to wrecking my wishlist this way, the job also affects my life outside the office significantly. I always stated that a full-time position is not only a source of income – it is a way to spend less as well. Now, as my spending halved, I have an actual proof of this hypothesis. Moreover, the positive outcomes of my employment are not limited just to the improved trade balance – I also smoke less and even procrastinate much less. On the other side, being obliged to work every day except weekends I can’t devote as much time to, say, this blog and my pet-projects as I used to. However, the lack of free time makes me manage it carefully to be able to do more. Combined with the fact that the job allows me to do something important for the company and its customers that’s a fair compensation. Finally, the ease with which I wake up these days confirms that I am pretty satisfied with my new employer and the regularities, which employment brought into my life.

Heading West

These days I am working hard on my diploma project. The defense is scheduled for the 26th of June, so I have a great and nervous month ahead. Obviously, finishing the six year course of study is an enjoyable achievement. Being an ending of one significant period of my life, this event will at the same time mark a beginning of another one and this new beginning worries me because I am still uncertain not only about the things that it will bring, but about the direction I should go from there as well. One particular opportunity to which I am encouraged is continuing my education in the form of pursuing Master's degree in CS in USA or Canada.

 

The idea is great and there are lot's of reasons to try. First of all, I like the process of learning new skills and getting knowledge, so the chances are high that I will enjoy another couple of years at university. At the same time, the fact that I lack trust in Russian system of higher education makes me look for an opportunity to deepen and broaden my own education elsewhere. Moreover, even if my assumption about the quality of university education being higher in America doesn't hold, it would still be great to explore new grounds and se what do things look like there. Another feature that makes a degree obtained abroad more valuable for me than one got in Russia is that, as it seems to me, western MS is valued much higher not only in US, Canada and Europe, but in Russia as well.

 

However, while there are huge benefits offered by Master's program in a good university, I see drawbacks as well. The most important of these is the fact that the path I want to go is the path of a software engineer. While mastering this field indeed requires descent education, what is even more crucial for a developer is actual experience in tackling real-world problems. Since I will hopefully get diploma in a month it may be better for me to get into industry instead of spending another 20 months or so on education. This point is made even stronger by the fact that I am almost 24 now and still have only minor job experience. Put another way, I feel it's time to focus on producing things - not only preparing myself for that. I acknowledge that it is possible to create great stuff even while studying at a university, although the word 'focus' is important here and the availability of numerous MOOCs allows me to not merely trade further education for job but to get both at the same time.

 

One more thing that really frightens me when it comes to studying abroad is money. The education alone costs a great deal and one has to take into account the cost of dwelling and other stuff as well. The price really seems too high for me and I am not sure whether I will be willing to pay it - no matter through loans or from my parents' pocket. On the other side, I do believe that generally these costs are fully justified by the merits one gets from university in the form of skills, new contacts and the degree itself. Although, because I am close to getting a degree it is not that easy to estimate the value of such an investment in comparison to going straight for a job.

 

Even with all the arguments laid out it is still very difficult for me to make any reasonable decision. The idea that should I choose to pursue Master's abroad it is better to do this as soon as possible also doesn't make the decision easier. Fortunately, these days I have to concentrate all my efforts on the diploma and put most other issues aside.