From time to time I am asked to look at someone’s CV/resume and to suggest improvements. Usually, apart from o bunch of tips/comments, I give that person a link to a 10-year old blogpost of mine which enumerates things a programing/hacking enthusiast might have done and could include on their resume - some of them are obvious, others less so. Originally the blogpost was published in Polish; however, a few days ago I had it translated, I've updated it, and here we are - enjoy!

Here’s the usual problem: how to document the knowledge acquired on your own?

In the case of courses, studies, etc., that’s simple – we usually obtain a paper confirming the acquired qualifications:

• after graduation, it will be a graduation certificate,
• after a professional examination, it will be a technician diploma,
• after graduating from an university it will be a master's degree, engineering degree, etc.,
• after completing a course or training, it will probably be a type of a certificate of completion.

It goes without saying that we put the above certificates into our CVs, either in the Education section or in the section for “additional qualifications/skills”. However, the situation is not as clear if we acquired the knowledge ourselves. But it’s only seemingly so.

The whole thing, in my opinion, comes down to publishing what you are doing - i.e. let's give the future employer a chance to see that we have actually gained some experience, even if we might have not been employed anywhere before (or at least not in these fields).

What can be published if we learn programming, reverse engineering, or hacking/security? (If you still have some time before looking for a job, you can also treat this post as a list of things that could be done to strengthen your CV/resume)

• Apps, libraries, or smaller snippets of code (e.g. as a GitHub link). This point is both valid for project which were 100% done and have actual users, as well as for smaller apps that we wrote mostly for fun, and then got bored half way through implementation. However, do include only properly written code - neat, with comments, ideally even with accompanying documentation. And, to state the obvious, I wouldn't recommend including (or even creating in the first place) anything similar to “a new trojan stealing passwords from this-or-that-MMORPG and this-or-that-social-network, undetectable by anything on VirusTotal” – it can ruin one's chances with a lot of companies (e.g. ones from the antivirus industry).
• Articles or tutorials (published on our own website, on various sites, or in the industry press [thx Mariusz]). There are two advantages to publishing articles: firstly, we pass the knowledge on and give back to the larger community; and secondly, we prove that we have actually learned something. But remember that this is a double-edged sword! If the article is derivative (i.e. there are already 150 articles in our language on this topic), unreliable (full of errors), too chaotic, on a topic we will be ashamed of later (e.g. “how to steal a friend’s password to their mailbox”), or, oh the horror, is plagiarized, then we will get the exact opposite effect to the intended one.
• Lectures, talks, videos. This point is closely related to the previous one – just the medium is different. If we feel confident in a given topic (and actually have the grounds to be that) as well as with public presentations, we can try recording a set of training/tutorial videos or speaking at a conference. There are quite a few conferences out there – they are diverse in their topics, reach (local ones vs international ones) and in the level of talk (there are some that only accept original research, and quite a few where you can talk about anything interesting). Of course, in the event of an appearance (or recording), we need to ensure the quality of the lectures – both in technical content and making sure it’s interesting (counted in the number of people yawning, falling asleep or leaving the room).
• Participation in conferences. If we don't particularly see ourselves as a speaker, it's still worth to attend conferences. There are many new things we can learn, and we can say that we participated in such a conference. Networking is also important!
• Run a technical blog. By definition blogposts are a simpler and less refined medium than articles – therefore they can also be more diverse in topics. We can use blogs to publish updates on our current projects and endeavours, write about curious and interesting details we've seen, about problems we've encountered – how did we solve them, and also about new things we've learnt. As in previous cases, do care about the quality of the postings – try to write in an interesting way, care about details and the language, and avoid posing as an expert in areas new to you (especially when writing about new things you've learnt). Obviously, avoid publishing (and doing) things which could negatively affect your career (e.g. "How I stole 1000 passwords and sold them to the highest bidder").
• Publish vulnerability advisories and case studies. Typically, when you find a vulnerability, an advisory and PoC exploit are written, sent to the vendor/maintainer, and eventually published – this is pretty much the norm in the industry. If you plan to look for a job as a pentester or security researcher, it is worth showing that you can actually find something. Also carefully consider the way you approach the process beforehand – there's an age-old dilemma whether to go for Full-Disclosure or Vendor-Coordinated-Disclosure (aka Responsible-Disclosure); the current norm seems to be some form of the latter (e.g. 90-day policy).

All of the above things can be put in the CV. Personally, I have added sections to my CV like “Publications, lectures, projects worth mentioning, research worth mentioning” and I put there everything that I think is worth mentioning (running a blog is an exception here, and I personally put it in the 'interests' section). Over time, it will probably be a lot, so it is worth ignoring what is less interesting - the CV is, after all, to be quite concise and some say it's good if it does not exceed two pages (depends on the country / YMMV).

It is important not to put anything in your CV that you don't really know. Job interviews at good companies are often designed to check whether what a person has written in the CV is actually true, so we can be sure we will be thoroughly grilled about everything that is written there. But if we've actually worked with what we put there, that shouldn't be too difficult. To look at it from another perspective: this is an extremely favorable situation – because not only do we know some of the questions up front – we've already learnt how to answer them!

The first item on the above list (the one about publishing one's projects) actually extends even further – regardless if we decided to publish any of our projects, we need to have some code ready to show a potential employer if asked (in my personal experience this was a typical request I've received until I've reached senior level). Thankfully, while learning programming (a process that never actually stop) it's pretty typical to write a lot of code and to create small projects – so having something to show shouldn't pose a problem.

In the list above I have mentioned a few things that I am using personally, but this is not an exhaustive list in any means! I encourage you to come up with other ideas for documenting your own knowledge and to share then in the comments. The list below contains other items that were suggested under the original blogpost.

• (by Karton) Take part in open projects (e.g. open source). First, we can demonstrate our knowledge, and second, help develop some interesting projects and gain experience in teamwork (even if it is limited to sending patches the maintainer of the code).
• (by Karton) Create a portfolio. A collective space where we publish what we have done :)
• (by michał) Certificates. After learning something on your own, you can try to certify yourself in that thing – i.e. pass an exam and have a lovely entry in your CV. I once heard that “in the west” some employers are big on certificates :)
• (by Gynvael) Take part in various competitions/challenge/hackathons/compos, etc., and it is best to win them. And there is no shortage of such competitions - like different CTFs at conferences, challenges published by different companies, various algorithmic contests, and so on and so forth. The more prestigious the competition, the better.
• (by myst) Internships for students. “Larger companies also organize a different kind of internships for students that can be held at their premises or remotely during the student year. You can often find out about them in scientific circles or somewhere at the university.. Participating in such internships is also, probably, a good way to document that you are doing “something” ;>.” I'll add that some companies also perform open qualification tests with programming languages and grant internships to people who have performed the best. I encourage you to approach such a test, even if you don’t manage to snatch the internship (because e.g. it is only for higher years and you are a first-year student).
• (by y) Write and develop an application. A case similar to writing an application I proposed, but with an emphasis on the constant development/maintenance of one program. “Later in the conversation 'Oh, you are the author of this program.. We use it in the company’ You will definitely look good then” :)
• (by Mariusz Kędziora) On the blog, make a list of the most important/most interesting entries. “You can sum up in a way, for example, your blog (because the blog itself is a lot for the potential employer/co-worker to browse) – in a collection of the best and most interesting entries in your opinion.”.
• (by Jurgi) Being active on forums. Employers and headhunters also browse thematic forums. If the user has meaningful posts, then that can arouse their interest. “Similarly, being active in the forums (maybe it is worth adding?). In my case, it worked – it wasn't me who applied – it was the employer that came to me, because he wanted me to write for him.”
• (by Jurgi) Running workshops, zins, scientific circles, etc. “[...] non-internet activity (conducting literary workshops, running several zins) resulted in me being accepted as an editor of a weekly, even though when I asked, there were no vacancies left.”
• (by Kele) “Portfolio” of solved tasks on pages with constant challenges (tasks, competitions, etc.). “I have recently received an email from Polish SPOJ with a link to a survey. One of the questions was whether we would like to have a possibility to create a profile that could be shown to the future employer on the site. It's also some form of ‘competition', but a more long-term one.”

- to be continued ;)

P.S. If you have been learning for a while (a few years) and after reading the above list nothing comes to your minds that you could put in your CV, you might want to stop and think carefully if there isn't anything you should change, adjust or improve in the way you go about learning hacking/programming.