devopsy.kinsta.cloud

Tag: hiring

  • Linux Foundation Exam for Certified IT Associates Available

    Linux Foundation Exam for Certified IT Associates Available

    A while back I wrote about an upcoming certification people receive from passing the Linux Foundation Exam. Now that it is available, I’m circling back as promised with more information.

    For those unfamiliar, this certification is specifically targeted at people who are newer to their IT career or just launching it. The goal is to offer an onramp for people to show their basic skills and demonstrate to potential employers their ability to get the job done or learn what is needed. It fits in well with their other offerings, giving Linux admins a path to use the foundation’s certifications to reflect progress in their career.

    I have information about the beta test, more information about what is stressed in the testing, and availability information, so let’s dive right in.

    First off, for those like me who have a friend that might benefit from using this test, it is available for purchase now and can be scheduled in January 2021.

    Who is the Linux Foundation Exam for?

    This exam is aimed at entry-level IT folks or those who are contemplating a move to DevOps. Though it is not targeted at help desk people aiming at systems admin jobs, it is suitable for them also. Its goal is to provide employers with proof of a minimum set of skills in IT basics, with (unsurprisingly) a strong emphasis on Linux. An interesting application that Lee Marer of Outcert, one of the Linux Foundation’s partners, pointed out to us was interest from K-12 and colleges—it could be a benefit to people who are recently out of school to already have something that shows they know their way around.

    Specifically, Lee thought the following groups would benefit from the test, and sees interest from these groups:

    • K-12/College: Already mentioned. A good way to offer practical benefit to coursework and offer prospective employers a hint at an inexperienced student’s capability.
    • Those moving to DevOps: Because a lot of DevOps is open source, a lot of DevOps depends upon Linux. This test shows those looking to move have the background required.
    • Those who are intimidated by the more advanced tests available from the Linux Foundation and others. My friend fits into this category. The amount of prep required to pass some tests is not on par with the practical knowledge they test for. This test offers a stepping stone that allows users to study the basics before being asked to advanced tasks such as (for an extreme example) parsing packets.
    • Employers: This exam proves a basic understanding of the topics covered, allowing employers to say “Must have passed this exam” in place of “Must have Doctorate and 15 years of experience.” (I joke, but it does offer employers a bar for help desk or entry-level DevOps.)

    What’s in the Linux Foundation Exam?

    Specifically, Dan Brown, senior manager, content and social media at the Linux Foundation, told us that the test would cover the following topics:

    • Linux Fundamentals (20%)
    • System Administration Fundamentals (20%)
    • Cloud Computing Fundamentals (20%)
    • Security Fundamentals (16%)
    • DevOps Fundamentals (16%)
    • Supporting Applications and Developers (8%)

    We had hoped to have a couple of sample questions for you, as an example of what to expect from the test and from those who took it. As of this writing, answers to those questions are not available. We’ll keep you posted.

    How Can I Take the Linux Foundation Exam?

    As mentioned above, it is available for purchase now (at a good price for an exam), and the scheduling of exams opens in January 2021.

    Tests are delivered remotely, with a live proctor and monitoring used to ensure it is an evaluation of the test taker’s knowledge, as opposed to the test taker’s ability to look up answers.

    This will be a point of contention, as it is in interviews and other exams. Simply put, the ability to look up what you don’t know and apply what you find to answer your questions/fix your problems is a critical skill at this point in IT. But for an entry-level test, I think that proving you have the basis to even understand what you are looking up is more important. So while I believe that unfettered internet access should be available during higher-level tests, for this test it makes perfect sense to me that monitoring will detect searches for answers.

    So Why Cover it Here?

    I think that this industry has developed a kind of psychosis. We talk about skills being more important than formal education and for entry-level positions, ability being at least as important as experience. Yet, job postings read like wish-lists. No, I don’t have five years’ experience in that three-year-old tech, thanks. The Linux Foundation Exam offers an avenue for organizations to demand basic competence without going crazy on a laundry list of items. For help-desk, for admin, for DevOps, this test would prove basic competency in a swath of Linux applications and utilities that would simplify the hiring process. I think we need that. I think we need that across the board, but starting with entry-level is good for me. Priced to be available to entry-level people, gauged to judge their basic knowledge, and from an authority on Linux, this might just be the answer at the bottom end of the scale.

    In fact, combining this test with a demonstrated ability to look up and comprehend answers would be all that is needed for most entry-level positions. Employers get assurance that they’re making the right hire, applicants don’t have to try and figure out which of those “requirements” is actually a requirement. Everyone wins. But only if we’re talking about it. So I’m talking about it, to people who’ve laughed at job postings before and know something like this could help: You. Keep kicking it, and consider this another tool to get co-workers who can kick it, too.

  • How to Build a Highly Qualified Cloud-Native Team

    How to Build a Highly Qualified Cloud-Native Team

    If you’re reading this, you more than likely are aware of the struggles involved in recruiting and building a team of technical professionals skilled in cloud-native computing technologies such as Kubernetes, Helm, Prometheus and service mesh. The Linux Foundation and edX’s “2020 Open Source Jobs Report” found 93% of hiring managers are having difficulties filling open positions that require open source skills like these. The report also found that cloud and container technologies are the most in-demand aside from Linux, which itself is a necessary basic skill for cloud professionals.

    So the question is, between a talent shortage and rapidly increasing adoption of these technologies, how can any leader manage to build out a qualified team? Based on our experiences as a vendor-neutral provider of training and certification for many of these technologies, we’ve learned some tips and tricks that, with some effort, can help you establish a team that can handle any cloud-native project you throw at them.

    Don’t Rely on the Same Old Recruiting Strategies

    It’s important to understand that the most promising cloud developers, engineers, administrators and other team members may not have the most prestigious qualifications. You may often find a high school dropout who has completed a cloud computing bootcamp and passed a Kubernetes certification exam will be far more able to perform the functions of a job than a recent graduate with a computer science degree. This means you need to set the job qualifications appropriately.

    If your organization is going to limit these hires to those holding a college degree, you are reducing an already limited talent pool even further and you’re going to miss out on some incredibly talented individuals. Instead, look at demonstrable skills and experience rather than only education. Some of the most talented contributors to these open source projects themselves don’t hold degrees; if the people building these technologies don’t need one, then neither do the ones implementing and administering them.

    Of course, you should continue to look at candidates with computer science degrees—after all, you’re trying to expand your access to talent, not reshuffle your sources. College degrees are a valuable indicator of intelligence and tenacity in completing a rigorous program. But do not take the degree as evidence they can perform any cloud-native tasks. Look at their specific skills, what the university curriculum was, any external training or self-study they conducted and verifiable credentials.

    Structure job postings as a list of skills and abilities necessary to be successful in the role rather than specific educational requirements or years of experience—in fact, many of these technologies are so new that no one has more than a year or two of experience with them. Avoid absolutes where possible and encourage folks to apply even if they don’t check every single box. And if you do want to ensure that someone is up to the challenge, you can require they hold verifiable certifications. The trick here is to find the certification most respected in the industry for a particular skill set, and prioritize performance-based certifications that test abilities to knowledge-based ones that only test memorization.

    Go Where the Developers Live

    Do not expect a wave of great applications just because you throw a well-crafted job posting on the internet. Many of the most talented cloud-native pros out there don’t bother looking for opportunities as they are already constantly bombarded with them. You need to find them where they are spending their time, which is likely message boards and forums such as StackOverflow and Reddit. LinkedIn can sometimes be effective, but experience shows this type of expert is less likely to spend time there than individuals working in many other professions.

    And do not simply bombard these professionals with job opportunities, either. You need to make your organization stand out and demonstrate why they should want to come work for you. The Open Source Jobs Report asked opens source pros what would make them consider moving jobs—while to no one’s surprise salary is a top incentive, 65% stated the opportunity to work on interesting projects would tempt them, while 58% desire a better work-life balance and 51% want more flexible schedules or telecommuting options.

    Talk these up in your outreach, but you should also put your money where your mouth is. Sixty-three percent of the hiring managers surveyed this year said their company has decided to contribute to an open source project, either financially or by contributing actual code, for the express purpose of attracting developers who work on that project. If your organization is using open source technologies but not giving back to the community, you will miss a significant opportunity to raise your profile among target recruits.

    Take a Chance and Help Them Grow

    Let’s say your company is participating openly in open source, being a good community member, offering competitive benefits, being open to considering individuals from a broad range of backgrounds and advertising your open roles in ways that both get in front of and attract talented cloud-native professionals. Despite all this, you still have not been able to recruit enough talent to tackle the needs of your organization.

    The first recommendation when you’re at this stage is to look at your existing resources: Are there talented individuals in your organization who do not possess the skills necessary to perform these tasks but possibly could with the proper training? If so, give them the chance to grow into such a role. You can start off with very little risk involved; ask them to complete a free introductory training course and report back after. Consider how long it took them to complete the course and ask them how they feel about this type of work. It should be apparent quickly who is enthusiastic and excited about learning a new technology and who is not. You can then sponsor those who show promise for more advanced training courses and certifications to demonstrate they have gained the necessary skills to move positions.

    If you don’t have anyone internally who either can or wants to train for a cloud-native role, look at recruiting someone with promise and make clear from the start that the expectation is they will complete training and gain an appropriate certification within a specified time period. Look for individuals who have already demonstrated both grit and an ability to learn. Perhaps they have an entry-level IT certification that is far from meeting your requirements but still shows that they can complete this kind of program. You’ll find many candidates are strongly enticed by such an offer.

    This is reinforced by the data from the Open Source Jobs Report: 54% of developers surveyed stated that lack of employer-sponsored training is a major hindrance to their job and 70% stated that increased training would make them more effective. 70% of hiring managers also stated that they’ve seen more requests for training from employees the past year.

    Summary

    We know it’s a tough job finding qualified cloud-native talent to fill open roles, and it is not expected to get easier anytime soon. By putting in a concerted effort, being thoughtful and flexible about the types of applicants you consider and giving existing and potential employees the opportunity to grow into these roles, you and your team can be successful.

    This article is part of a series of articles from sponsors of KubeCon + CloudNativeCon 2020 North America

  • Survey Sees Surge in Demand for DevOps Skills

    Survey Sees Surge in Demand for DevOps Skills

    The Linux Foundation and edX, a provider of an online learning platform, jointly released an annual report today that for the first time finds organizations are looking for more IT personnel with open source DevOps skills (65%) than developers (59%).

    Clyde Seepersad, senior vice president and general manager for training and certification at The Linux Foundation, said the 2020 Open Source Jobs Report shows that as more workloads shift to the cloud in the wake of the COVID-19 pandemic, the number of organizations looking to embrace best DevOps practices is increasing substantially. The report finds 70% of respondents are more likely to hire an IT professional with cloud computing skills.

    Based on a survey of 175 hiring managers and 900 IT professionals with open source expertise, the report also finds that despite the economic downturn brought on by the pandemic, 37% of hiring managers say they will be looking to hire more skilled IT professionals in the next six months.

    The report also finds 93% of survey respondents report difficulty finding open source talent. An overwhelming 81% of hiring managers said recruiting open source talent is a priority for 2020, with 56% looking to recruit IT professionals with open source skills in the next six months. Nearly two-thirds (63%) said their organizations have begun to support open source projects with code or other resources for the explicit purpose of recruiting individuals with open source software skills.

    More than half of hiring managers (52%) said they are more likely to hire someone with a certification, while 80% of survey respondents reported providing online training courses for employees to learn open source software. Nearly three-quarters of organizations (74%) are now offering to pay for employee certifications, according to the survey results.

    An equal percentage of hiring managers also identified Linux as the most in-demand skill they seek in new hires, while 63% also said they are looking for IT architects who can build solutions based on open source software.

    Seepersad said given the difficulty attracting talent many organizations are focusing more on training their existing staff rather than trying to recruit talent in an open market where demand for open source expertise remains high.

    The talent pool is more global as more organizations become accustomed to working with staff who are now largely working from home, which, coupled with current economic realities, is limiting how much organizations are willing to pay for IT talent. More organizations are also keen to make sure there is a cultural fit with their organization when hiring, he added.

    In general, it’s clear more IT organizations will need to focus on growing their own farm teams with open source DevOps skills rather than hoping to lure away superstars from other organizations. Rather than simply trying to fill open positions, organizations need to think more in terms of acquiring and managing talent in the same way a general manager manages a sports franchise.

  • Eliminating Unconscious Bias in Tech Recruitment

    Eliminating Unconscious Bias in Tech Recruitment

    For a more diverse workforce, businesses need to be aware of the role of unconscious bias in recruitment and take the necessary steps to remove it where possible

    The business case for diverse organizations is clear: A more diverse and inclusive business consistently delivers better results. From a legal perspective, with a variety of discrimination legislation long since passed, there should be no barriers to hiring a workforce that is more reflective of society as a whole.

    So why, then, do we continually see data and hear of experiences where that is consistently not the case, across all sectors? What is holding back the acceleration of diversity within organizations?

    One problem is the role of unconscious bias in recruitment. We all have biases, formed from our individual reactions to a complex mix of cultural, social and economic experiences. The challenge is how these biases inform decision-making, both in our personal and professional lives. They have a direct impact on our actions and, from a business perspective, have significant consequences.

    In technology, this can result in our biases being programmed into solutions that are designed to help but end up hindering different parts of society. There have been numerous examples in which human biases have been, whether consciously or unconsciously, programmed into artificial intelligence tools, with those tools then making decisions that disproportionately affect certain sections of society.

    This happens when an organization doesn’t have a diverse enough workforce, one that is empowered to challenge decisions and highlight when products might have bias or preference built into them.

    This is why getting recruitment right is so important, yet even there, as highlighted before, unconscious bias has an effect. It means that even when presented with two candidates with exactly the same skills, experiences and qualifications, hiring managers are more likely to choose the person that aligns positively with their biases. This affects all professions—a Yale University study found that “both men and women science faculty were more likely to hire the male, ranked him higher in competency, and were willing to pay him $4,000 more than the woman. They were also more willing to provide mentoring to the male than to the female candidate.”

    How, therefore, do we root out unconscious bias within recruitment and ensure that it does not hinder the drive to create more inclusive technology workforces?

    First, it is important to realize that where you hire from is as important as how you hire. If you only ever recruit from the same schools or with the same websites, then you are leaving yourself at the mercy of the diversity of those institutions. If you only ever use one route to apply, whether that’s only using recruitment consultants or use a website that is only really accessible through a computer, then again you are limiting yourself to candidates with access to those pathways.

    Outside of reconsidering talent pools, one way to reduce unconscious bias is through the removal of identifying characteristics—no photos, no names, dates of birth or school and university grades. This can help to an extent, in that decision-makers have to go off the candidates’ experience and how they’ve presented their previous roles, but it does have its restrictions—with entry-level positions, for example, where relevant experience might be limited.

    That’s a quick-fix solution. For a more sustainable, thorough and long-term approach, recruiters—particularly those hiring for technology positions—need to look at how they can accurately judge skill sets. This can be challenging in itself—in larger organizations, those involved in early stage selection may not have the requisite background understanding to make the right choices.

    That is why having an anonymous, objective environment in which to appraise skills could be the answer. Using coding tests that closely resemble what the successful applicant will be doing will enable organizations to evaluate candidates and provide a clear appraisal of whether they would be suited for the position. This can then be taken and used alongside other tests that look at aptitude and cultural attributes to score the candidate on suitability.

    It is this combination of anonymity and focus on skills that help remove unconscious bias; as one study found, if a woman contributing to an open source software community was unidentifiable, their contribution was likely to be accepted more often than men’s. When a woman’s gender was identifiable, they were rejected more often. The message is clear and applicable to technology recruitment: Take the focus away from who is doing the work, and make it about the work, and you will see a more diverse workforce emerge (assuming the applicant pool is diverse to begin with).

    We need to have diverse employee bases; it is the only way that we can be sure that the tools and technologies being developed will serve to help society rather than to increase inequalities. To do that, businesses need to be aware of the role of unconscious bias in recruitment and take the necessary steps to remove it where possible. That means anonymity—but more importantly, it means focusing on skills and the ability to do the job in question.

  • Despite Downturn, Enterprise IT Budgets Remain Intact

    Despite Downturn, Enterprise IT Budgets Remain Intact

    A survey of 137 IT operations leaders at companies in the U.S with at least 500 employees and an annual IT budget in excess of $5 million finds a surprising amount of resiliency at the beginning of the COVID-19 pandemic.

    Conducted April 1 by OpsRamp, a provider of IT operations tools, the survey finds more than half of the survey respondents (58%) said they expect to either significantly or moderately increase their annual technology budgets, while 38% plan to either significantly or moderately reduce their technology spending.

    The survey also finds 73% of respondents expect to either accelerate or maintain digital transformation initiatives and projects.

    Bhanu Singh, senior vice president of engineering and DevOps for OpsRamp, said that at least for now among larger enterprises, digital business initiatives are being accelerated as organizations recraft their business continuity plans. With most customers and employees working from home, the need for applications that digitize business processes has become more critical, especially since no one knows for sure when the COVID-19 pandemic might subside or whether there will be another one, he said.

    Many of those projects will rely on cloud-native technologies that make it easier for organizations to scale IT resources up and down, added Singh, noting organizations are quickly discovering that monolithic applications even when they are deployed on a public cloud are not as flexible as they now require.

    Specifically, the survey finds IT leaders are investing heavily in AIOps (69%), information security and compliance (62%), self-service platforms (60%), cloud-native observability (51%), network performance monitoring and diagnostics (51%), big data analytics (46%) and cloud infrastructure (45%).

    IT leaders are also planning to drive technology vendor consolidation (59%) to reduce costs and rely more on third-party managed service providers (58%).

    In terms of hiring, IT financial analysts (68%), cloud architects (53%), DevOps engineers (50%) and data scientists (47%) top the list of priorities.

    Of course, as the impact of the COVID-19 pandemic on the global economy becomes more apparent it is too early to say what the impact on IT budgets will be. Industry analysts Gartner and International Data Corp. (IDC) are forecasting a relatively small decline in IT spending of about 5% for the year once the economy begins to recover in the second half. However, it’s clear that certain vertical industry segments, such as travel and hospitality, might have a much longer way to go than, say, healthcare companies.

    In addition, it’s likely that much smaller companies than those surveyed by OpsRamp may find it more challenging to restart operations after being forced to lay most of their employees in some cases.

    Whatever the timing, the one probable thing is many of the IT trends that were just beginning to gain traction are likely to see accelerated adoption once the economy recovers. There will be a natural tendency to limit the adoption of new platforms and processes in the short term. However, now that it’s clear existing platforms and processes are not especially flexible it’s only a matter of time now before most of them one way or will be replaced or at the very least completely modernized.

  • DevOps Hiring: What Do You Need?

    DevOps Hiring: What Do You Need?

    IT has long had a problem with hiring. I’m not certain where it started; most of us blame HR, and that’s probably incorrect, but gives us someone to blame. It’s that we post jobs with insane requirements. Sometimes this is done to keep the applicant pool down, but most of the time it is a simple case of throwing in the kitchen sink. We have laughed at advertisements that wanted applicants to have more years in a given technology than the technology has existed. The laughter was because someone quipped, “So what we really want is only liars to apply.”

    But it doesn’t stop there. How many advertisements have you seen for a person to join an already good-sized team of developers, and the requirements include experience in every single language/tool the person might encounter—and sometimes ones the organization might use in a year or so? And DevOps, with its increase in toolsets and broadening complexity, make this problem worse.

    If you want good DevOps team members, you have to focus your search. We’d all love to have unicorns who could do it all on day one, but those people don’t really exist. Even with experience in every single tool in your chain, they still have to learn apps and environment. Try to craft job requirements that focus on the couple of core tools, and then filter for ability to learn and adapt. Because the only certainty about IT at this point is that technology will be shifting, so focusing on the tools you are using today is pretty limited.

    Role plays a part in this also. While we like to pretend DevOps is one thing, it is a rare application or portfolio for which there are not specializations on the team. If you are looking for someone who will lean more toward the DEVops side, do you really need them to be operational wizards with three years each in storage, networking and container management? Conversely, if you are hiring someone more for the devOPS side, do you need them to have expansive experience in Javascript, or do they just need to know who to call if it gets beyond their ability?

    Maybe your company is one of those shops where everyone on team X is expected to be an expert at everything. Kudos for you, but there aren’t a ton of those people out there. There is a different mindset to DEVops versus devOPS, and even if unofficial, most employees lean one way or have a more proficient side. If a candidate fits the bill in an area you are weakest, consider training them on the job in the area you are strongest, rather than waiting for who knows how long for the perfect person to fill the open req.

    And we still have a need for hardware specialists. I’ve said it before, but do you want your EMC (or Cisco or whomever) person to be a generalist, or do you want that person to make the infrastructure that underlies a huge chunk of your applications hum? Hire specialists for specialized skills, hire broad knowledge for app-spanning needs.

    It’s been a problem for years, and only you can fix it. Call out overambitious job postings and make managers ponder what they’re actually looking for. You know you have a need, you know what the position will do. Help hone down postings so that they fit the actual requirements, not some blue-sky version of potential requirements.

    And get the best people for the job. After all, you are going to have to work with them.

    — Don Macvittie

  • The Value of ‘DevOps Engineer’ as a Title

    The Value of ‘DevOps Engineer’ as a Title

    Now that DevOps is proliferating in the enterprise (many companies including Disney, Nike and Walmart, for example, are all on the adoption train) the term is starting to creep up more and more in job titles. This is challenging organizations to consider the significance of DevOps Engineer as a role and the value of having someone with “DevOps” in their title on their team. There are steps you can take to ensure that DevOps candidates are the right fit for your company.

    When you are looking for someone with “DevOps Engineer” as their title, you are seeking someone who not only has the skills you need to complete technical work but also embodies the DevOps values and mindset. Part of the interview process needs to get at the DevOps culture you are seeking to create. You should ensure that you ask questions such as:

    1. What’s the most important business outcome for a DevOps team to deliver?
    2. Have you been able to achieve continuous delivery on the projects that you’ve worked on?  What were the keys to ensuring that you could deliver that value to the business?
    3. What’s the most important character trait for DevOps engineers to have to make sure that the team is successful?
    4. How do you ensure that the DevOps team communicates effectively across team boundaries?
    5. What’s the most important operational requirements to ensure that you understand early in the process?

    The goal of these and other questions is to dig into a candidate’s ability to work across teams, communicate effectively and understand of the full spectrum of DevOps capabilities. Communication skills are core to what we do as a consulting and digital software engineering services firm, so we may have an easier time and more background assessing the communication skills of engineers. But, we’ve seen clients also be successful by combining their typical technical interview process with some additional behavior-based communication questions.

    It is also important to understand that being a true DevOps Engineer entails technical capabilities and there are specific tools that need to be mastered if someone claims to be an experienced DevOps Engineer. So, in addition to soft skills and values, it’s important to understand the technology and deployment environment specifics to effectively assess a candidate for such a position. There are big differences in technologies depending on what development technology (Java, Node.js, C#, React, or some combination of all those things) and what deployment environment (Azure, AWS, Google Cloud, etc.) you are working with. These differences are critical and must be understood. You should look for candidates who have experience with the tools your organization uses.

    It also can be helpful to look for someone who has skills that matches your clients’ needs or the needs of a particular project. In some cases, you may be looking for a pure AWS DevOps Engineer who will work completely in the cloud deploying Node.js applications. In other cases, you may be looking for an engineer who might be skilled with Microsoft technologies for a hybrid deployment (on some cloud, some on-prem) of a .Net core application.

    While progress is being made to try and abstract the platform differences, those technologies still require DevOps engineers have a good understanding of the underlying tools and infrastructure that will support the software.

    Bottom line: Candidates who seek DevOps positions and self-identify as DevOps Engineers are good candidates for the general set of skills you are looking for, but be sure you have solid technical evaluation in place to ensure that your hard skill requirements are also met.

    — Jonathan Fries

  • Do Your Engineers Need a Degree? If So, You’re Missing Out on Great Hires

    Do Your Engineers Need a Degree? If So, You’re Missing Out on Great Hires

    For more than a decade, tech team leads have lamented the fact that software engineers are among the toughest jobs to fill. But in some ways, their frustration is self-inflicted.

    It is almost a given that a lack of higher education represents a deal-breaker for hiring decision-makers. The same goes for job seekers—it can feel as though the lack of a degree drops your résumé to the bottom of the stack. But the mandate for software engineers to have a formal education beyond high school may be one of the biggest mistakes I have seen companies continually make in my 20-plus years in the technology space.

    By no means am I against pursuing a higher education. Colleges, universities and technical training programs can offer real value when it comes to learning the finer points of software development. But too many talented candidates get tossed out of consideration simply because they lacked college diplomas.

    In my experience, it’s possible to hire engineers fresh out of high school with five or even 10 years experience in coding and development under their belts. If that sounds absurd, consider that there are hundreds of apps designed to teach code to kids as young as 3 years old.  In fact, Mattel has a Robotics Engineer Barbie and Fisher-Price has introduced a “Code-a-Pillar” aimed at toddlers that instills the basics of coding. Soon, the generation graduating high school will have been building their developer chops since they were in diapers.

    It’s understandable why employers believe a stellar education and a prime résumé are the prerequisites for good candidates. However, great engineers and developers share some common qualities, whether they have a degree or not. Eliminating higher ed requirements can net talented individuals overlooked elsewhere and potentially allow you to offer lower starting pay. When making hiring decisions, I look beyond the “education” section of the résumé and focus on these qualities instead:

    1. Look for “closet coders.” A great engineer excels at scripting. I call these agile individuals “closet coders” for their ability to code their way around a brick wall. A tinkerer by nature, this type of candidate grew up taking apart the family computer and successfully putting it back together, or taught themselves Python for fun. In the workplace, especially in a DevOps environment, this person can fill gaps in the tools they are using and build ways for the rest of the team to automate processes. In the interview process, make sure you’re asking questions that require your candidates to think outside the box and demonstrate they can come up with solutions in really tough scenarios.
    2. Hire a true team player. The concept of the “brilliant jerk” in engineering is finally falling by the wayside, and for good reason. This tongue-in-cheek term refers to giving miserable and cocky developers a pass simply because they are so talented and sharp. But the best engineers are those willing to share their talents with everyone, making the entire team stronger in the process. This type of collaboration goes beyond simply teaching. A great engineer also shares scripts, tools and other tactical assets they use to do their job so well. When screening candidates without a degree, look for individuals who attend hack-a-thons or local code meetups. This is a good indicator they’re willing to work in a collaborative setting and will be an effective teacher.
    3. Get an engineer who can fail forward. The best developers and coders thrive in an agile environment. They run toward the problem when things break, eager to find a way to fix it. If it’s their fault the failure occurred, they take it in stride, learn from the mistake and make sure others do as well. This “fail forward” attitude leads to a more iterative process, where risk is embraced for the benefit of making breakthroughs. Candidates without degrees are more likely to have these qualities than those with a formal college education. Why? Because they’ve taught themselves the skills they possess, meaning they’ve broken plenty of things along the way and found the fixes on their own. A candidate who doesn’t give a “safe” answer when asked about past failures is someone who deserves further consideration.

    A college degree is usually a “nice to have,” but not a “must have” when it comes to hiring decisions. Some of the best engineers and developers I have worked with and managed haven’t taken the traditional education path to earn a degree and possess a unique skill set that can be a huge asset to the team dynamic.

    By not discounting these individuals, I’ve gained a competitive advantage over competitors who shell out top dollar just because of a résumé line—and I can definitively say they’ve missed out on what could have been some of the most talented people on their teams. In your next round of hiring, commit to talking to at least one candidate you wouldn’t traditionally give a chance. The result might surprise you.

    — Gordon McKenna

  • Reinventing Talent Acquisition, DevOps Style: 7 Ways to Become a ‘Destination Company’

    Reinventing Talent Acquisition, DevOps Style: 7 Ways to Become a ‘Destination Company’

    Just as brilliant drummers have their pick of bands, top cloud-native developers and project managers can be choosy about their employers. They’re the rock stars of the business and they know it. If you’re not a “destination company” like Amazon, Facebook or Google, how do you entice top talent to work for you? And if you’re being wooed, what are the tip-offs that you’ll be valued?

    We’ve been asking ourselves the same questions, and in this article we’ll share an approach that’s working for us. Your company can become more of a destination company in today’s “seller’s market” by applying a DevOps mindset to the way you recruit, hire, onboard and retain talent.

    Begin by Imagining the End State

    DevOps teams define success criteria upfront so that everyone shares the same goals. Knowing the end state when you start is just as important for becoming a destination company. So begin by imagining what your talent acquisition organization would look like if it were the world’s best. (Even if you fall short of our goals, you’ll still be better than before.)

    To help seed your list, here are some of our ideas:

    • Knowing the best places to find people with the right skills—or the right aptitude.
    • Creating a concierge-like experience for candidates from the first contact. The idea is to make them feel welcome, valued and in the loop. More about this later in the paper.
    • Making an offer no more than two weeks after first contact. Talented people don’t stay available for very long. A swift offer gives you a hiring advantage—and sends a message to the person that you value them.
    • Fostering a culture that makes it easy for new hires to integrate into their new team, adopt the DevOps work style and feel connected to your company’s big picture—and want to stay.

    Create a Concierge-like Hiring Experience

    The key is to make the hiring process so welcoming at every step that it sways top candidates to work for you rather than their other suitors. Just as you do when developing software, focus on the experience. For example, since some engineers don’t like social interviews and questions that start, “Tell me about a time …” don’t do it. Instead, test candidates on the job they’ll perform. Ask developers to code so you can measure their speed, aptitude and empathy for users. Ask product managers to design a product that you’ve outlined in vague terms. Assess how well they:

    • Draw out requirements from stakeholders and users.
    • Create a screen flow for the app—a good demonstration of empathy.
    • Describe the architecture at a high level so you can judge whether they understand what’s feasible. The description doesn’t have to be highly technical.
    • Propose release milestones (minimum viable products) that reflect a logical build-measure-learn cycle. For example, MVP 1 might not include a login.

    In our experience, candidates either love this process or hate it. In the latter case, we have a good clue that they wouldn’t have much fun working with us.

    Look beyond skills. Technology is evolving quickly, so a candidate who can figure out the right path may be more valuable than one who knows a trendy programming language. We home in on candidates who can parachute into a situation, contextualize quickly and figure out the right next steps. That takes a combination of speed, aptitude and empathy.

    How can you assess whether a person has empathy? Good question. Our view is that if they have empathy for their teammates, they’ll most likely have empathy for our end users as well.

    Schedule a Pair Day

    A pair day is an awesome way for a candidate to experience how you work. Here’s how we do it: The candidate joins us for morning standup and chooses a team. During the course of the day the candidate pairs with other engineers to deliver real customer value (stories from a backlog). This gives team members an opportunity to assess the candidate’s skills and work style in an actual work setting—and observe whether the candidate is loving it. At the same time, candidates can experience the team culture firsthand.

    Immediately after pair day, we hold a short meeting to decide on next steps. Typically we conduct a Roman vote: Yes, let’s hire the candidate now, or no, not a good fit. We’re looking for individuals who raise the bar for the team as a whole. Rock stars. If the team is willing to fight for a candidate, that’s a good indication the person is a great fit and a bar raiser.

    Recruiting: Learn from the Numbers

    Cast a wide net initially, including talent channels such as tech meetups, college outreach and internships. Remember that you’re connecting with real people and the goal is to build relationships. Phony ads and mass-marketing strategies send the wrong signals. We’ve seen good results from hosting meetups—a great way to start informal conversations where you and the candidate can learn something about each other.

    To identify the best talent sources, measure:

    • Resumés submitted
    • Percent of applicants that went to the second round (testing)
    • Percent tested candidates who had a pair-day interview
    • Percent of pair-day interviews that resulted in an offer
    • Offers accepted

    A note about full-stack developers: finding them is difficult. The same goes for product managers who can work on a DevOps team. We know we’ll have to kiss a lot of frogs to find these unicorns (pardon the mixed metaphor). To increase our chances of finding rare talent, we measure our recruitment activities and conduct A/B tests every step of the way—from job descriptions to talent sources. For example, our data shows that in some cities meetups work better than career fairs; in other cities, it’s the opposite.

    When the data tells us that a recruiting activity doesn’t work in a particular market, we try something else. This, too, borrows a page from DevOps: Focus on data and the user need rather than clinging to subjective opinions about what works and what doesn’t. Openly share all of the data about sourcing and onboarding with your DevOps teams to get their input. The goal is continuous improvement.

    Break Down Organizational Boundaries

    Creating an engine to attract and onboard talent requires breaking down organizational walls. For example, sourcers and recruiters who are out in the field need a clear way to collaborate with the team members who conduct technical interviews.

    Organizational change is never easy. We’re approaching it in the same way we get code into production. That is, we bring people together into cross-functional teams and ask them to work together toward a shared goal. Giving everyone a common goal avoids finger-pointing. Everyone has an incentive to do what’s right for the company and the candidates rather than just their team. And gaining more empathy for the other functions’ challenges helps team members come up with better ideas for creating a world-class recruiting and onboarding experience.

    The cross-functional team should include a technical recruiter, executive recruiter, someone who runs meetups, someone in charge of onboarding, a technical screener and other people involved in the interview process. As it is for DevOps, the goal for hiring and onboarding is to go fast. That takes great communication and transparency.

    Don’t Try to Boil the Ocean: Start Small

    It’s not feasible to change the entire talent acquisition organization in one go. Better to start with a few teams and run mini experiments. When a new process improves hiring or onboarding speed or increases retention, scale it across the organization. And when a new process fails, do what DevOps teams do: Fail fast, share the failure so that everyone can learn from it and continuously improve.

    Take care to select the right people to spearhead the transition. Look for people who are open-minded and have a good understanding of how the organization works today. If you’re into 16Personalities, you’re after Explorer types—those who have “a self-reliant mix of enthusiasm, quick thinking and ingenuity.” In our view, the right people for the transformation should see it as a short-term experiment because transformation should take on a life of its own, not remain the pet project for a few.

    Roll out the red carpet for the cross-functional teams that spearhead the transformation. Limit other work for these team members: this needs to become their entire job. Celebrate each team’s success. The goal is for the first teams to model DevOps-style talent acquisition for their peers to ignite transformation throughout the company.

    Don’t Stop After You Make the Offer

    Consider pairing new hires with a buddy to integrate them quickly into the team. And to retain top talent, be proactive about offering new opportunities and training. Developing a tool that tracks lifetime project assignments, as we did at Cognizant, will help you identify the people who would benefit from and appreciate these opportunities.

    Adopting the DevOps-style of talent acquisition we described isn’t easy. It takes new processes, cross-functional teams, data collection and analysis and transparent communications. The payoff: becoming more of a destination company for the rock stars who create great software—and earning their loyalty by making them feel valued.

    This article was co-authored by Sam Harrison.

    — Brian Roche

  • Age or Experience: Which is Better in Hiring a DevOps Engineer?

    Age or Experience: Which is Better in Hiring a DevOps Engineer?

    In such a rapidly shifting space as the DevOps talent market, many employers find themselves challenged with deciding what type of DevOps engineer to hire. Do I choose the junior talent with all the energy in the world and is eager to learn anything at the click of a deployment? Or, do I push the IT department’s budget and Finance’s patience in selecting the most experienced talent in town?

    Of course, there are great case studies of companies who have digitally transformed thanks to hiring both: a senior DevOps engineer to tackle architecture and design while mentoring a savvy junior DevOps engineer working deeper in the weeds. (And from that moment forward, all DevOps hires came in twos.)

    But what happens when you can only choose one?

    While both add heaps of value to a company, there are some key distinctions worth considering.

    Related Content:

    5 Key 2018 Tech Predictions for the C-Suite

    Get Ready to Become a Full-Spectrum Engineer

     

    Communication Skills

    Senior DevOps Engineer

    It’s second nature for senior DevOps engineers to interact with varying personalities—they’ve been in the field longer. They have already dealt with one department deliriously happy with their efforts and another not understanding why they are disrupting everything “that worked just fine.” These veterans can roll with the punches when managing the all-too-familiar growing pains of user acceptance.

    When it comes to strategizing with C-levels, senior engineers have the experience to be able to predict what their biggest concerns and pain points will be, making for more productive conversations and quicker improvements with minimal trial and error.

    Junior DevOps Engineer

    On the flip side, a breath of fresh air can add spark to a company’s culture and promote communication throughout with new and exciting ideas that a senior resource may not always be willing to try. Junior DevOps engineers not set in their ways will naturally create a refreshing example for fellow engineers and admins to be proud to learn from mistakes.

    After all, productive trial and error is one of the best qualities of a DevOps culture. Changing, reinventing and creating is what DevOps is all about, and constantly learning is what junior resources thrive on best.

    Legacy Experience

    Senior DevOps Engineer

    In this case, we have to give props to those who have been there and done that. They not only have cutting-edge skills and personalities but also have probably managed legacy systems before and know how to diagnose whatever issues a company’s systems of old might be causing as it digitally transforms.

    Since a digital transformation is never a one-person job, they’ve probably picked up a trick or two managing or leading teams in the past. This experience always helps in creating a sense of confidence any business needs when going digital.

    Junior DevOps Engineer

    In the event your company is running a mobile app startup with zero on-prem history, a junior resource who can recite every case study on the latest apps’ successes and challenges could be great for your product, whose uptime needs every advantage possible.

    While every company culture and product is unique, coming from a place of DevOps fandom will keep your legacy transformation’s moans and groans to a minimum. This is usually more than just a job but a genuine passion. They’ll take pride in assuring their newfound “baby” is up to date on the latest best practices, tools and methodologies, even if the data they are moving is older than they are.

    Co-worker Perception

    Senior DevOps Engineer

    Let’s be real: We all tend to find trust in a more experienced coworker, especially during an event such as a digital transformation, where not everyone is an expert. It’s simply human nature to find more comfort in working with someone who has handled your problem before.

    Placing a senior DevOps engineer in a lean cloud native startup also has its benefits. Having probably experienced many environments previously—large, small, medium, stuffy, casual—they most likely have seen a plethora of problems and know multiple ways to fix it. Your cloud-native startup may have a unique issue you need an experienced set of hands to tackle and your rugged war hero could be just the right person to help.

    Junior DevOps Engineer

    Having a junior DevOps engineer absorbing new knowledge can dust off the cobwebs of a once-intellectually curious work culture that may have become complacent before going digital. There’s a genuine buzz when companies go digital, no matter how large or small. Since interacting with multiple departments is inherent for a DevOps engineer, having that aura around to move things quicker can rub off without either side realizing it.

    Sometimes, companies just don’t need someone with every trick in the book. Imagine finally hiring that long sought-after DevOps guru only to find they become bored or even automate themselves out of their role completely and need to leave. It could risk having fellow employees scratching their head wondering, “If the best in business is bored of our environment, is this whole DevOps thing even worth embracing?”

    Perhaps you already have highly talented team of software engineers and only need someone with an admin background. A junior admin/DevOps engineer in 2018 tends to be more “DevOpsy” than those of 2011 and further back. So, if infrastructure knowledge is what you need, pull the trigger and know that the Kubernetes/Docker rockstar could be a hire you make down the road.

    Of course, we cannot simply generalize all DevOps engineers solely into two distinct categories. Every DevOps engineer has a unique background with a lust for new knowledge. If they didn’t, they wouldn’t be DevOps engineers and remain as admins, developers or systems engineers. All in all, both sides make some compelling cases in choosing your next DevOps engineer.

    Which one can you see walking through your doors next?

    — Michael Race