Tag: Advice

  • Considering A Career In Dev-Ops?

    Considering A Career In Dev-Ops?

    DevOps is a term you will have seen used a lot in recent years. Whether you’re a student planning their future, or an experienced developer or infrastructure engineer seeking a change of field, a DevOps career path can often seem like an enticing prospect. However, there is always one question on your mind- what exactly is DevOps?

    The short answer is that there is no short answer. What exactly a DevOps team entails, and what work they specifically carry out, will vary organization to organization. There are, however, several common principles that run throughout the DevOps space whether you’re delivering complex investment management software for a Tier 1 Bank or working on the latest release of a popular mobile app for teenagers.

    DevOps is fundamentally a way of thinking. Before the DevOps movement came to life, development and operations teams existed worlds apart. Rarely would they communicate beyond addressing specific problems. This lack of communication caused a whole host of issues, from bottlenecking to broken version releases to monumental delivery delays. Developers and Operations kept to their silos and practically ignored anything taking place outside them. Then DevOps came along.

    DevOps is crucial to Agile and Lean environments. In the world envisioned by the DevOps movement silos are a thing of the past; an antiquated computing term thought of in the same way as dial up modems and floppy disks. In a true agile DevOps environment developers, sysadmins, business stakeholders, and anybody else with vested interest in successful delivery would work and operate as one team. There are always going to be differences, but this is the central axiom of the DevOps movement- multiple disciplines in one team can understand each other and speak the same language.

    How can this be achieved? This is where the idea of DevOps being a mindset, being a methodology, comes into play. Generally speaking there are three principles to every DevOps environment:

    1. Collaboration
    2. Automation
    3. Continuous Everything

    The principle of collaboration is self-explanatory by this point. The DevOps movement originated when the need to bridge the gap between Development and IT Operations became too apparent to ignore. This has since evolved though, and now collaboration within a DevOps environment encompasses not only Development and Operations but also QA’s and Business Stakeholders as well. Since DevOps, the idea of the lone programmer grinding away in solitude has almost become a thing of the past. It creates teams where previously there were groups of individuals sharing a common work environment.

    Automation is another focal point of any DevOps engineer’s professional life. As far as technical and practical skills go, DevOps practitioners focus on one thing; tools, tools, and more tools. These can be built, brought, or open source, but these automation tools are the key to everything DevOps. Large toolchains that automate as much of the end to end development and deploy process as humanly possible are what have given DevOps the ‘must have’ reputation it currently enjoys.

    The final principle, Continuous Everything, can be broken down into the realms of integration, testing, delivery, and monitoring. This is where DevOps shows itself to be an Agile methodology that has divorced itself from the old Waterfall-style ways of working. Continuous Everything means integrating code from different developers as it is completed, repeated testing at every stage of development, delivering a steady stream of updates as opposed to placing all your bets on a final build, and monitoring everything constantly. This seems like a lot of work, but when combined with the impetus to communicate and the construction of automation pipelines this rigorous addressing and redressing of every stage creates a streamlined SDLC free from bottlenecking, one that is fluid and adaptable.

    Hopefully this has made the world of DevOps a bit clearer for you. From here your next step would be to look into specific tools such as Ansible or Jenkins, and more in-depth concepts such as containerization. One thing is for sure, DevOps is a unique career path and one that opens a great many doors, and the demand for DevOps engineers isn’t going to wane any time soon.

  • UK Contract Market CV Tips – Part One

    UK Contract Market CV Tips – Part One

    By Thomas Russell

    As you can imagine, as a recruitment consultant I read through hundreds of CV’s every week. I work across a variety of sectors in the IT and technology space, dealing with everybody from project managers to DevOps engineers to user researchers. One thing every recruitment consultant knows is that a good CV can be what makes or breaks an application. I have seen some of the most technically skilled, qualified, and experienced, candidates miss out on positions because their CV didn’t translate their talent to hiring managers. I pride myself in my ability to give my candidates the strongest possible chance in every application, and with this in mind I have put together this list of 3 CV tips for candidates working in the UK contract marketplace.

    1. Have Plain Text CV’s Ready

    So you’ve read up on graphical CV’s, how they’ve landed people their dream job. You’ve put together your own with charts, tables, a colour theme you spent five hours carefully selecting, and a good photograph of yourself that’s the right mix of professional and flattering. You’ve exported it as a PDF, put it on all the job boards, and have sent it forward for a few contracts. The success that the internet promised, however, has failed to materialise. Why is this?

    The answer is quite simple: formatting. When submitting CV’s consultants are more often than not required to stick to formatting and style guidelines. These vary from client to client, but in almost all cases require converting a CV to a word document to remove the contact information at the bare minimum. In a lot of cases (particularly with larger clients) fonts, margins, even the number of pages we are able to submit can be limited.

    Unfortunately, the most heavily stylised CV’s are also often times the ones that come out looking the worst at the end of this process. I’m never allowed to send photographs, first of all. This is true of the UK market in general. Whilst pictures are considered the norm in most regions of the world, in the UK they’re considered a bit of a professional faux pas by most hiring managers. Visual graphs are also incredibly difficult to translate into text, so in a lot of cases they also have to be either chopped completely or summed up in a single sentence which lacks the same impact.

    My suggestion isn’t to stop doing visual CV’s. On the contrary, when searching job boards they are incredibly convenient for scoping out candidates. My suggestion is to have a plain text, word document version to send to consultants once you’re at the stage of submission. Not only does this save time, but it also gives you greater control over what’s included in the final version of the CV that hiring managers have in front of them.

    2. Keep Things Concise

    This is a simple point, yet one that I find myself thinking again and again. The common rule of thumb is that a CV should be two sides of A4. There is debate around this, but in general two sides seems to be the average. Obviously, in the IT field this isn’t possible in a lot of cases. Some candidates I speak to have careers that span decades. Trying to explain how you’ve adapted and kept up with every advancement in your field since the 80’s on two sides of A4 would make for some disjointed reading. There is a happy medium, however. Some CV’s I look at can stretch to as many as 15 pages long. These professional sagas can be fascinating, but to a hiring manager viewing their 25th profile of the day they present little more than a tiring slog to try and dig out information relevant to the current position.

    I’m not suggesting that you butcher your CV, or remove valid examples of your abilities. My suggestion is to be brief but comprehensive with your language choice. Let’s look at an example. An overly lengthy CV might describe a position with a sentence like:

    I led a complex project with a team that averaged 50 professionals (but often more), drawn from across the scope of the business. This team included both technical and business professionals such as BA’s. This was a transformation project, and my task was to upgrade the organisations outdated CRM to a modern system’.

    You can convey the same information with fewer words;

    • Transformation project, managing multidisciplinary team of 50+ technical and non technical staff upgrading legacy CRM.’

    In less than half the words the same point has been made, in a way that is kinder to tired eyes worn out from too much time in front of a screen. Hiring managers are experienced. They can form a rough mental image of your capabilities from a few bullet points, and read CV’s in awareness that all projects or roles have more depth than can be put into a few paragraphs. Remember who you are writing your CV for and why you’re writing it. It’s an assessment of your professional capabilities, not of your writing talent.

    3. Have Your Three Greatest Achievements On The Front Page

    You’ve got a long, complex career history. You’ve worked in a lot of places and have done a lot of things. You were a pioneer of a specific technology or field in the early 00’s, and you’ve gone into detail about how this proves you’re the perfect candidate for any role in your space. You don’t understand why it hasn’t brought you more offers. After all it’s right there, in plain text, on page seven of your CV.

    Hiring managers will have possibly looked at dozens of CV’s by the time a role moves from internal recruiters to a consultancy. They know they will still have to look through dozens more. With each page of your CV beyond the second the chances that the information will be properly ingested (or even, in some cases, read) grows slimmer and slimmer. Some of the strongest CV’s I see are those from applicants who understand this. These applicants have included a section listing their three greatest achievements, most prominent projects, or challenging roles, on their front page. This gives hiring managers an instant idea of what the candidate is capable of. A summary of how you turned a struggling DevOps team into a continuous pipeline, or brought a struggling project from the brink of collapse to an on time and on budget delivery of a flagship product, makes for a much better first impression than a skills matrix or academic history.

    Keeping it concise is, as usual, key. A three to five bullet point summary of three particularly relevant projects, or three anecdotes from roles in which you show why you’re an asset, will suffice. It’s a simple yet effective way to give a snapshot of yourself at your most dynamic, innovative, and skilled. Do this well enough and nobody will bother reading a page beyond the first before picking up the phone to schedule an interview.

    In Summary

    So, to recap; keep a plain text version of your CV, keep things concise, keep your three biggest achievements on the front page. I have more tips to come such as the importance of writing different CV’s for different roles, and how including a cover sheet for consultants can prevent unnecessary calls.