devopsy.kinsta.cloud

Tag: DevOps careers

  • Eradicating Developer Burnout With a Flexible Workforce

    Eradicating Developer Burnout With a Flexible Workforce

    Burnout can affect people no matter what their job role, but software developers are particularly vulnerable. Too often, businesses chase profits by chronically relying on heavy workloads delivered by employees in short turnaround times. Developers often undertake intense work and find themselves pushed to meet deadlines under great pressure over and over again. But without proper care, burnout is almost inevitable. After all, developers are humans first before they are developers.

    Programming is a cognitively stressful job that requires individuals to constantly solve complex problems. Working for hours on end day after day with no break is tough for anyone, and this pattern over a period of weeks is all too familiar for developers. 

    But slowly, the face of the workplace is changing. We are seeing a post-pandemic focus on employee well-being, and the current job market conditions mean that professionals have choices and the right to demand better care or even explore self-employment or non-traditional job paths (thanks, Great Resignation!). In this context, businesses are also thinking differently about how they work with talent to use workers more efficiently.  There is an opportunity here to lower the burnout risk facing developers for the benefit of employees and employers.

    Organizations Can’t Afford Burnout

    Developers are key to most digital transformation projects, so organizations can ill afford for their developer teams to suffer from burnout. This can significantly delay the rollout of new products, features or apps and slow down DevOps initiatives, which can’t progress without the tech teams responsible working consistently and productively. 

    This risk to developers is particularly high in the wake of the pandemic, with technical staff under additional pressure to play catch-up and deliver projects that might have stalled. During this period, there has been little consideration for employee well-being; a 2021 study found that 83% of software developers were experiencing burnout. It’s not just about writing code—technology teams also struggle with inefficient engineering processes, backlog and technical debt  and are more likely to encounter friction when trying to deliver work quickly, leading to a greater risk of burnout. 

    Low quality in-house software is also a point of frustration for development teams, with 83% of engineers reporting being concerned about software reliability in their organisation. Prioritizing the right tools for these teams is one way that businesses can help ensure projects run more smoothly. It’s a simple fix, but one that is frequently overlooked, though empowering technical teams is increasingly top-of-mind for businesses.

    Developers Aren’t Easy to Replace

    Great developers come with years of experience, learning their trade through practical problem-solving. They’ve never been easy to replace, but the state of the current global job market means it is more difficult than ever. This is inherently linked to developer well-being; some are changing jobs and moving to other companies in search of better working conditions while others are creating their own. For example, many are switching to freelance roles to gain independence and control of their own workloads. 

    However, freelancing can be lonely and admin heavy. Despite the improved flexibility, the lack of support can also lead to burnout. Talent clouds offer a potential solution to this through closed communities offering structured work for freelancers and regular interaction with peers. They have seen a surge in membership and have driven wider uptake of self-employment. In fact, 11.2% of developers were freelancing in 2021, up from 9.5% in 2020, as they sought to balance the freedom of freelancing and some of the perks of permanent work. 

    And that’s crucial. For a role that’s considered ‘always on’, the flexibility of freelancing to decide when or where developers work could be crucial to delivering quality, secure code. Without wasting hours a day commuting—that could otherwise be spent working or, crucially, decompressing from their intense workload—it’s been the option of choice for overworked developers all over the world. IT is the foundation on which modern businesses are built—giving the architects of these businesses some of this flexibility is a small price to pay to ensure their well-being. And, as a result, the timely delivery of products, projects, features and apps that accelerate digital transformation initiatives.

    It’s a Two-Way Street

    We’ve already seen how the increased workplace flexibility afforded to freelancers translates into better productivity and lowers the risk of burnout. Equally, 31% of developers worry about unclear goals and processes, so there is also something to be said for improving project management of digital initiatives to ease the burden on technical staff. In fact, 58% of devs feel that burnout is not inevitable, and that better working practices and management are key tools to its prevention.

    For businesses wanting to deliver projects quickly, harnessing on-demand workers from the increasing pool of freelancers means they can engage specialists depending on the type of work or coding language being used, but also that they are fresh to tackle each new challenge—a key concern among developers who have experienced burnout. Doing so via a private talent cloud also ensures that the burden of managing and vetting freelancers is taken away from the organisation and nixing potential concerns about bringing in external talent. 

    Eradicating Burnout

    Well-being is in the public eye more than ever. On one hand, developers should not have to face the high risk of burnout; on the other, businesses can’t afford to lose the talent fuelling their digital future. 

    Both parties can help solve the issue. Developers are taking professional well-being into their own hands by exploring freelance careers that give them flexibility. On their end, businesses need to consider creative ways to access talent. In part, this is about ensuring internal technical teams have the right support in place so they do not become overworked. It’s not easy to find this support in the current job market, but with developers flocking to freelancing, there is an opportunity to rapidly engage highly skilled workers on an on-demand basis at pinch points. After all, a well-managed workload significantly reduces the risk of burnout.

    We have the resources and available skills to eradicate burnout among developers—we just need to arrange them in the right way. 

  • DevOps Is Not a Role — It’s a Culture

    DevOps Is Not a Role — It’s a Culture

    The full-stack developer is becoming increasingly rare these days. Due to the accelerating complexity of modern software development, programmers often specialize in specific languages, frameworks or levels of the software stack, such as frontend or backend.

    These same fractures seem to be occurring within DevOps, too. Nowadays, large companies no longer have one strain of DevOps—there are often many flavors of rapid deployment and various DevOps toolchains used across an organization’s development teams. DevOps now requires specific training in the nuances of each cloud service provider’s platforms, too, requiring specialists trained on individual cloud platforms, like AWS, Azure or GCP. The role is expanding and taking on new forms, with platform engineering and site reliability engineering coming of age.

    Therefore, companies should be viewing DevOps not so much as one specific role or a set of tools, but as a culture. I recently met with Sashank Purighalla, CEO and founder of BOS Framework, to gather insights into the evolving role and culture of DevOps. According to Purighalla, “DevOps is a combination of culture, practices, processes and tools.” Below, we’ll identify the challenges that come with introducing DevOps and consider the right blend of technology, human specialists and governance required to get the job done.

    The Challenges of Implementing DevOps

    One challenge of implementing DevOps is simply defining the position itself. “DevOps is not really a job,” Purighalla explained. Instead, it encompasses many aspects, such as CI/CD, provisioning, maintenance, and compliance, all of which now adopt a plethora of different tools. There is also overlap between CloudOps and DevOps, an ambiguity that makes it tricky to write a job description for a DevOps engineer.

    Various roles make up the teams responsible for modern cloud-native operations. In the same way that programmers have particular specialties, DevOps has specialized areas too. This segmentation might be based on the cloud vendor suite or the tools in use, such as familiarity with Jenkins, Docker or Kubernetes. Particular domains, such as DevSecOps or BizDevOps, may require dedicated focus as well. Purighalla shared some example roles that often exist in a modern CloudOps team:

    • Cloud architect
    • App architect
    • Security expert
    • Compliance expert
    • DevOps engineer for AWS
    • DevOps engineer for Azure
    • SRE for AWS
    • SRE for Azure

    Complicating things further, DevOps can transcend cloud-based systems and be applied to on-premises or edge network maintenance. Given the many possibilities, crafting a job description for a DevOps position requires “awareness of and vision for how you want to build the DevOps function in your organization,” said Purighalla. Unfortunately, most people don’t have a clear picture of where to begin, he said. Setting this roadmap will vary from sector to sector and require intimate knowledge of and context about the company and its technological assets.

    DevOps Shouldn’t Create Another Wall

    DevOps is a mechanism to deliver high-quality code more quickly—this business outcome has been the guiding principle since its origin. To get there, DevOps sought to place development and operations ‘in the same room’ to reduce friction. Yet, in some organizations, DevOps emerged as an entirely new role on an org chart. “In certain cases, it created a wall,” says Purighalla. “Developers can’t think beyond when they hand off code to the infrastructure team.”

    If this wall stays in place, it could further divide team motivations. Of course, building a healthy DevOps culture will vary from company to company and will require clarity about the end goal. But creating common incentives could include shifting left some security and provisioning responsibilities so developers have more perspective and can participate in DevOps.

    Another reason to embrace a DevOps culture is simply the talent scarcity in this arena. This is a problem facing businesses of all sizes. Startups may not be large enough to hire a DevOps or site reliability engineer, but are beginning to see the necessity of greater focus on reliability and compliance as a core business function, says Purighalla. Enterprises typically have multiple clouds and hybrid environments, which are challenging to find talent to support. Middle-market companies often lose out to the attractiveness of startups and the big bucks of large corporations.

    Outsourcing DevOps: Is It Ever a Viable Option?

    So, given that it is so challenging to find engineers, is outsourcing DevOps ever a viable option? According to Purighalla, “outsourcing is a good option if your company has pre-built solutions for clouds and if it’s able to give you similar capabilities without requiring ground-up custom work.” A cloud enablement solution could be used to reduce the barrier to entry but is never a replacement for an entire DevOps practice.

    The reason is that software programming is a creative engineering process. “I’ve never found an engineer that does the same thing every time.” People continue to experiment with a ‘build and fix’ mindset. This means that, in general, hiring external engineers is tricky as they don’t have intimate knowledge of the system at hand.

    Furthermore, a platform that applies a standard way of working with multiple cloud providers must be flexible and open to change, as backend infrastructure is constantly evolving. As such, DevOps must be viewed as something that’s much more continual and requires ongoing maintenance. It’s not something you can outsource once and be done with.

    “It’s becoming like accounting—you’ll fail an audit if you don’t do it,” said Purighalla. “Outsourcing needs to be viewed that way. You need to bring in a cloud enablement solution in combination with experts. You can’t have one or the other.”

    DevOps: Not Just a Role or Toolset

    Many assume that DevOps is just a set of tools. Instead, some experts argue that DevOps is more of a combination of varying roles, tools and processes. “DevOps started as a model—it’s not a tool,” Purighalla reiterated.

    In essence, it’s more of a culture than a specific job title. And when viewed this way, organizations can begin to eliminate silos, which DevOps ought to eradicate in the first place. With the right technology and collaborative spirit, a company can create a culture that meets the goals of efficiency that DevOps aims to achieve.

  • 8 Skills Cloud Architects Need to Succeed

    8 Skills Cloud Architects Need to Succeed

    For cloud architects, a deep understanding of cloud tools and technologies is only the starting point in terms of skills that need to be mastered. Enjoying a successful career as a cloud architect requires much more, including certain skills that are typically not associated with the tech industry. 

    Architecture and Design

    The cloud architect needs to be an expert on end-to-end system design since their primary responsibility is solving a customer’s problems through the use of technology. The architect’s ability to develop a design that solves a business’s problem is where their true value lies. Because design is architecture, the cloud architect must have expert knowledge of all the current and legacy systems that exist in the network and in the data center and also understand how to migrate them to the cloud, matching them to the proper cloud-based systems.

    Network and Data Center Technologies

    Networking and data center skills are critical for the cloud architect because one of their major responsibilities is designing a plan to take the systems that were on the network and hosted in a data center and migrate them to the cloud. To do this successfully, cloud architects must be experts on networking and data center technologies.

    Digging deeper, they must be experts at routers, load balancers, switches, routing protocols, IP addressing and WAN connections whether those are private line-based, VPN-based or software-defined networking. They must be experts on servers and server virtualization and containers and storage, too: Block storage, object storage and file storage. The cloud architect also needs to be an expert at file-sharing protocols such as Server Message Block for Windows and NFS for Linux. Security, too, is an important skill; they must understand how firewalls, IDS/IPS systems and how VPN concentrators work. The cloud architect needs to have full knowledge of databases, understand how web applications work and understand ERP applications and supply chain applications. Good, strong network and data center knowledge is the foundation for architects who are overseeing the migration of tech from the data center to the cloud.

    Business Acumen

     Cloud architects are digital transformation specialists. They must craft end-to-end business solutions for customers with the goal of improving their businesses. If they do not have a thorough understanding of customers’ business, they cannot effectively engineer solutions that will solve their business problems.

    Business skills include the ability to calculate an ROI model based upon the expected value of an opportunity, to read a financial statement and to read a balance sheet. It includes knowledge and understanding of what the CEO, CFO, CIO and CTO care about and being able to communicate with them in ways they understand. Without an understanding of business, cloud architects limit themselves to simply adding or removing technology, which might make business outcomes better or might make them worse.

    Leadership

    Accomplishing anything great requires a team, which means being a great cloud architect requires leadership skills. When working for a client, a cloud architect typically will need to set a baseline of current systems. Accomplishing that effectively might require a team of 50 cloud engineers working together to evaluate the customer’s systems. Leadership skills allow you to effectively manage that team of engineers.

    And leadership skills go beyond effectively managing people as they work on proofs-of-concept and deployments. Leadership skills empower the architect to make sure teams are motivated, are fully engaged with projects and are contributing to success.

    Sales

    When on the job, a cloud architect is constantly selling. The solutions they designed need to be sold to the customer. The plan to implement the solution needs to be sold to management before the necessary resources can be obtained. When it is time to get people to work with us on a project, we need to sell them on its value. Sales skills are employed in a wide variety of ways. Cloud architects sell to customers, internal stakeholders and to management.

    Presentation

    Cloud architects also need exceptional presentation skills because they will be presenting to customers. Those customers could be technology professionals like engineers; they could be presenting to management and/or to C-level executives. Additionally, cloud architects will be presenting information at executive briefings and at conferences. In general, presentations are part of everyday life for the average cloud architect.

    Communication

    Determining the business requirements for any cloud architecture project requires asking a lot of questions. They’re never just handed a piece of paper by a client that says, “Build this.” Without stellar communication skills, it’s difficult—if not impossible—to determine the business’ requirements, meaning the solutions that are designed could be incorrect.

    Even once the business requirements are well understood, the next step is to take those requirements to a team of technology professionals, which means communicating effectively with tech people as well as business people. Communication skills, which include communicating to customers, teammates and various other stakeholders in the organization, are critical.

    Emotional Intelligence

    Emotional intelligence is a critical skill for those who want to increase their professional value and propel their cloud architect career forward. Emotional intelligence increases the capacity for leadership, understanding and communication. When used regularly in the job, it is the best predictor of career success and typically results in about a $30,000 increase in the average person’s salary. For a cloud architect to have a successful career, building on the skills outlined above is critical.

  • Start Date

    Start Date

  • How to Build a People-First Engineering Team

    How to Build a People-First Engineering Team

    When we think about successful technology teams, there is a tendency to primarily focus on the technology being created rather than the people who are creating it. While both approaches can lead to successful products, a technology-first approach is often the default when software engineers become managers without necessarily having the right tools to manage effectively. Becoming an engineering manager requires an entirely new skill set that involves different communication styles, time management, organization, tools and software, scoping work, learning how to effectively delegate and identifying the right people to complete the team.

    As a CTO, and having gone through this transition, I have noticed that the more a manager is able to be in sync with the people on their team, the less burnout they experience, the higher the employee retention rates and the better work their employees will do.

    While most people won’t be entirely people- or technology-focused, here is a quick overview of the differences:

    • A team-oriented manager knows the personal and professional struggles their people are experiencing, and there’s a sense that the team they run is all working together on a mission toward the same goal. When you talk to this type of manager, they will naturally gravitate towards giving status updates on the wellbeing of individuals.
    • Managers who tend to see the team through a more technical lens will instead identify parts of the project or technological or strategic roadblocks that are impacting the team.

    The same issues will be dealt with very differently by these different types of managers. It can be beneficial to record yourself when you are talking about your team to identify where your focus is, and evaluate if that feels right for you.

    Building Effective 1:1 Communication with Team Members

    An individual contributor is normally accustomed to arriving at weekly 1:1s and working with their manager to solve any problems they may have. When they become a manager, it becomes their role to coach team members to solve their own problems, in addition to building trust. This role change takes preparation, and, if you are unsure how to do it well, you may find it helpful to draft out an agenda that you can follow if needed. You can also gain knowledge about this process by talking to more experienced managers.

    What do you talk about in your 1:1 meetings? Even if you are more a technology-oriented person, 1:1 meetings with your team should be less about the status of projects and more about how the person you are speaking to is doing and how you, as a manager, can help. Having started as a software engineer myself, and now as a CTO, I have found the below questions to be helpful as I navigate how best to help my team thrive in their roles.

    1. “How are you doing?” If you are speaking with a team manager, another great question is, “How is your team doing?” You want to genuinely understand the status of the individual outside of the technical aspects of the job.
    2. “Do you have any feedback for me?”
      I always ask for feedback. For a while, they may not have any; but I often find they start with a small one like “Better options for snacks.” This is an excellent opportunity to build trust by improving the work experience. The next time, they will probably share more until you receive really important feedback, while also improving the relationship. The important thing to remember, here, is to respond to the feedback.
    3. “On a scale of zero to 10, how much fun are you having at work?”
      I really want people to have fun at work. You can ask them to give you a number between zero and ten. When they respond with a number, say, six, a great follow-up question can be to ask what is needed to change the situation so that number becomes a seven. How can you help get them there? I have heard a wide spectrum of answers to this question, ranging from easy to complex; from things like permission to be unresponsive for an hour a day to the desire to learn the skills needed to do a different type of job.
    4. “Where do you see yourself in the next two years and 10 years?”
      Helping your team define both long and short term goals is a really important part of being a manager. Specifically for engineers, it is a great idea to think about if you want to continue moving up in an engineering role, or if making the switch to a managerial role is a better fit.
    5. “How can I help you get to the next level in your career?”
      It is common to get sidetracked when balancing your day-to-day work with your personal life. You can also use 1:1 meetings to help your team members identify what they can do to hit their short- and long-term goals, and how to maintain a better work-life balance.

    Supporting Colleagues

    This last year has been tough for most people, to varying degrees, which has solidified the idea that we need to be there for team members during difficult times; this goes beyond the pandemic. That can mean sending their favorite meal via delivery, sending a care package or simply making it very clear that when someone on your team needs to step out or take time off, that is fine – no questions asked. To be able to be offline and not need to do a long handoff is so important when you are going through a hard time.

    During this move to remote work, as in many leadership teams, my company has gone against the cultural norm of keeping life and work separate. We have acknowledged that it is too difficult to do that right now, and very publicly recognized that everyone is going through something. It has felt like mental bandwidth is filled up with things going on outside of work, so as team members, it is good to make sure work doesn’t add to that pressure.

    In a way, this pandemic period has broken down barriers between work and “life” that has made it almost obligatory to focus on people first. From my perspective, this has been a breakthrough in how we can do business moving forward. By thinking about each individual on your team, everyone can be uplifted and heard, which can be the impetus to more innovation. If you are operating at your max with no slack in your system and little support from managers and teammates, you lose creativity. As innovative teams, this experience has been a reminder to build people-first principles into our cultures to promote a healthy work-life balance that lends itself to innovative solutions and better results.

  • Why DevOps Needs Mandatory Vacations

    Why DevOps Needs Mandatory Vacations

    “If a team doesn’t have time for retrospectives, you should hold them twice as often.”

    It’s 5:00 p.m. on Friday, and you’re just shutting down your computer to kick off the weekend. A message pops up in Slack:

    “Congratulations, you’ve been selected to take the next week off! We’re cutting off access to all work-related systems and revoking your credentials for the week. See you the following Monday.”

    What just happened?

    There’s an ancient security practice worth reviving in the age of DevOps: mandatory vacations. In practice today, it typically looks more like cutting off access when an employee is taking an already planned vacation, rather than forcing them to take a spontaneous one.

    But the goal remains the same: quickly assess bottlenecks, critical dependencies and security vulnerabilities. The side benefit? Your employees actually disconnect completely when they go on vacation!

    The Double-Edged Sword of DevOps

    DevOps practices increase a team’s end-to-end ownership, responsibility and autonomy. Team members modify code, deploy infrastructure and handle operational duties – sometimes all in the same day. Bringing Dev and Ops teams closer together results in reduced lead time, faster deployments and higher-quality software.

    But blurring the lines between Dev and Ops requires broad access and permissions. When everyone on the team has access to everything, there’s no forcing function to prevent relying on individual or shared accounts. This access proliferation results from a lack of clear indication on which credentials, accounts or permissions authorize each responsibility. Critical tasks may depend on a single person’s account. Credentials may be shared and never rotated.

    For example, deployment may depend on a service account, or bot, for which everyone has a copy of the API token. Admin or sudo rights may be delegated on a case-by-case basis to individuals, rather than role-based access control or group management.
    The result: a confusing quagmire of roles, permissions and dependencies.

    Reviewing and Remediating

    Explicit review of all accounts and permissions is an onerous, audit-like chore. While it might be necessary, particularly in regulated environments, it doesn’t mesh as well with agile, iterative, automated and just-in-time principles that fuel DevOps.

    Mandatory vacations provide an alternative. It’s a simple concept: cut off a team member’s access when they go on vacation.

    Depending on your setup, you might use this time to disable accounts, revoke privileges, rotate credentials, remove them from groups and even archive any home directories left over in production.

    The danger lies in leaving dependencies on personal accounts for day-to-day operations. From a security perspective, personal accounts are much more likely to be compromised or abused by a disgruntled insider. They’re an automatic back door into your deployment and production systems. From a reliability and operations perspective, a dependence on personal accounts means that changes to personal accounts (such as an employee leaving or losing access) may cause unforeseen outages. When you control the change as part of a mandatory vacation, you’re prepared for a change that could potentially cause things to break and can trace it back to the root cause quickly. Nothing like breaking the build to force a cleanup of technical debt! This technical debt could include critical nightly cron jobs left in home folders or owned by a single user, personal credentials hidden away in build secrets or operational practices that were assuming an individual’s identity or role.

    As a bonus, mandatory vacations also help ensure you keep your on-boarding practices up to date and robust. While re-provisioning your well-rested colleague upon their return, you are forced to acknowledge which privileges and permissions are truly necessary. Depending on the team’s growth and maturity, that may mean creating well-documented practices or enabling full user management automation.

    Finally, this provides an opportunity to promote key security principles. Are you enforcing least privilege where you can, giving users the minimum level of permissions needed to do their job? Are you granting access to shared folders in your password manager? If so, did you rotate the stored credentials when your colleague “left” the company, however briefly? This might provide an excellent example of why it’s time to implement multi-party authorization (MPA), just in case gaps like these persist, even after a few mandatory vacations.

    Mandatory vacations provide a ‘testing framework’ for access proliferation. Repeating difficult agile practices frequently helps streamline the process simply by doing it more often. If your team doesn’t have time for retrospectives, you should hold them twice as often. Testing your access management practices every time a colleague goes on vacation provides a natural, easy cadence to ensure your practices remain up-to-date – without having to scramble after a breach or when a team member leaves permanently.

    Take a Vacation, for Everyone’s Sake

    You might think you don’t have time to deal with the ramifications of random mandatory vacations. But imagine how much more difficult it is to discover a single chokepoint during a live incident! If you don’t have the time to test off- and onboarding accounts, that implies your access management practices are rusty, poorly defined and thus, unavailable when they’re needed in a rapid-response scenario. Laptops and accounts will be compromised. Staff may leave or join for unforeseen reasons.

    So please, take a week off … for your sake, and ours.

  • 5 Questions to Ask Remote Web Developers

    5 Questions to Ask Remote Web Developers

    Great web developers are waiting to be hired. Your company could seize upon the opportunity—but only if you’re willing to be patient, dedicated and a little creative.

    Don’t scare away qualified remote web developers with a few poorly worded questions or a mistimed probe. Ask direct and concise questions that can help you understand the candidate.

    Be sure to include the questions listed below to ensure you’re interviewing a remote web developer to the best of your ability:

    1. Have You Worked Remotely Before?

    Remote work is different from many traditional forms of work. For a company to properly manage a remote web developer, the web developer must have a solid understanding and knowledge of remote working environments.

    If an exceptional web developer candidate hasn’t telecommuted before, it doesn’t bar them from the pool of qualified candidates. However, it is easier to onboard and retain remote web developers who have had the experience of working remotely beforehand.

    2. Are You Familiar with Popular Web Development Frameworks?

    Remote web developers, like any other web developer, must stay abreast of the latest trends and advancements in the web development field. To master their craft, they must keep a running knowledge of the latest tools, frameworks and web programming languages.

    An experienced web developer should, at the very least, be aware of a large and robust framework such as Bootstrap. They should be able to explain how the framework works, why web developers use it (it’s much better to utilize a framework to save time, in most cases) and the drawbacks of utilizing a premade framework.

    3. How Much Experience Do You Have with Web Programming Languages? Are You Familiar with Server-Side Languages?

    Every web developer should be proficient in HTML and CSS. Scripting languages such as Angular.js, Express.js and JSON are important, too. JavaScript adds interactivity to websites. HTML acts as the skeleton and CSS acts as the design.

    Preferably, an experienced remote web developer candidate will have three to five years of experience with these languages.

    It’s also important to ascertain whether the web developer you’re interviewing has the ability to code the back end of websites. Do they know how to set up a database? Do they understand how to store values in a website’s database?

    4. Which Content Management Systems Do You Use?

    A content management system (CMS) helps streamline organizing, adding and managing content for a website.

    One of the most popular CMS is WordPress. Web developers leverage CMS to utilize built-in structures and architectures to create dynamic blogs and alluring corporate websites.

    Setting a website up with a CMS also makes it easier for writers, marketers and designers to tweak already-developed websites. They can add content without needing the web developer to intervene.

    5. Are You Comfortable with Regular Phone and Video Meetings? Do You Have Experience with Telework Software?

    Remote work has unique challenges. One of the most challenging aspects of working remotely is maintaining communication. Miscommunication can occur more easily for remote workers, so it’s important that you keep communication lines open and stress the importance of speaking clearly and confidently.

    It’s much better if a candidate already has experience with telecommunication software such as Zoom, Skype or Slack. Knowing how to interact via these technologies will lessen the chances of miscommunication in telework environments.

    Conclusion

    How you conduct a remote web developer interview is entirely up to your organization. There are several methods for conducting technical interviews, telework interviews and startup interviews. Each one of them is effective in a unique way; very few are ineffective or harmful. Adding a few questions to your interview script could help make whichever strategy you employ more effective.

    Ask remote web developers about their experience working remotely. Remember to ask about experience with certain telework software programs and telecommunication applications. On the technical side, be sure to ask about programming skill, familiarity with web frameworks and their experience with CMS.

    Companies that seek to hire remote web developers should take note of the interview questions listed above. By asking these five questions, interviewers can gain a great deal of insight into a web developer candidate’s habits, passions and challenges.

    Using these interview questions should make the vetting and hiring process easier for everyone, helping interviewers assess a candidate’s adaptability, experience and dedication.

    — Anthony Coggine

  • Defining the Role of a SRE

    Defining the Role of a SRE

    Soft Skills are Just as Important as Technical Skills in the SRE role

    Site reliability engineering (SRE) is a relatively new discipline, having only been in existence for about 15 years. It originated at Google and has gained popularity recently with more companies advertising SRE positions or trying to implement SRE practices. In the technology field, 15 years may seem like an eternity, but the SRE role is very much still in its infancy. There are still challenges defining the role and understanding exactly what it is. Just look through one of the 1,000-plus job listings on LinkedIn for an SRE in the United States—you will see many different job expectations and requirements.

    Some may see the SRE role as being similar to DevOps, while others may see them as competing concepts. Liz Fong-Jones and Seth Vargo from Google created a video describing the differences and similarities between DevOps and Site Reliability Engineering. They point out that DevOps is a philosophy and SRE is a prescriptive way of accomplishing that philosophy.

    Earlier this year, Catchpoint conducted a survey of 416 professionals with the title or responsibility of an SRE. The goal was to create a real-world profile of an SRE and their organizations. What we found was that some of the challenges in clearly defining the role may be due to differing needs and priorities based on industry and company size.

    Being a good SRE requires a mix of technical skills and “soft skills.” It was a relief to see there were no variations in the skills required based on whether a person was an individual contributor, manager or executive. Consistency in articulating goals and expectations is crucial to being a successful SRE and this is where some of the soft skills come into play. Someone may be good at automation, know a variety of scripting languages and is well-versed in application and network protocols, but that doesn’t make them a strong SRE. SREs need to know which questions to ask, not just how to apply technology to solve a problem. This requires being adept at problem-solving, working as part of team and having exceptional communication skills.

    The growing importance of soft skills cannot be overstated. West Monroe Partners recently conducted a survey of 600 HR and recruiting professionals who are responsible for hiring IT workers and 650 business professionals who work with IT staff on a regular basis. In the study, 42.9 percent of respondents said a lack of soft skills made it tough to find qualified candidates for technical jobs. When asked which were the most important soft skills for IT, 77.2 percent named teamwork and collaboration, and 63.4 percent named verbal communication.

    The SRE is fast becoming a mandatory position at many organizations, as continuous delivery of software applications becomes the norm. Development teams must work within dramatically condensed time frames, and unexpected performance incidents will arise. The SRE, who is responsible for increasing the reliability of supported services, needs to be able to effectively communicate why and how a proposed code or infrastructure change will impact reliability. This is why strong communications skills are so necessary.

    The Catchpoint survey also highlighted the need for alerting and notification tools. A full 90 percent of SREs responding noted they cannot live without such tools. These enable them to identify conclusively where the source of a problem lies, thus avoiding time wasted blaming or war-rooming, all while supporting a clear communications process.

    If your organization does not yet have an SRE, chances are you may soon. What are some things both employers and employees need to be thinking about?

    Advice for Employers

    Think about your organization’s specific needs, not whether your organization is doing exactly what is in Google’s SRE book. Specifically, for large organizations where there is enough headcount for people to specialize, the SRE role may look very different than at a small startup. Larger organizations generally will have more headcount, which means people are able to specialize in certain areas. If they aren’t familiar with a certain technology or toolset, others on the team with the knowledge can pick up the slack. Smaller organizations, however, require people to do more or potentially know a little bit about many topics, as often they don’t have the ability to hire experts in all areas. A strong SRE candidate for a large organization may only be good at a single technical skill, but they can still be a successful SRE. A strong SRE candidate at a smaller organization may need to have a wider arsenal of technical skills.

    Advice for Potential SRE Candidates

    Workers considering a move to an SRE role should understand that technical skills and soft skills are equally vital. Your job will consist of approximately 50 percent traditional IT ops functions—collecting and analyzing logging and diagnostic information, participating in on-call rotations and proactively monitoring and reviewing application performance, for example. You will also need to have good problem-solving skills and communicate clearly to identify and address incidents with your team. Being able to ask the right questions is critical to determining why systems and applications are not operating correctly. Collaboration is at the heart of the SRE role and that requires flexibility, teamwork and solid verbal skills.

    Also understand that while you may still have one foot in the developer world, your role will be quite different from other roles on the development team. The majority of SREs do not develop new features or contribute to product road maps, a stark difference to other roles on the development team. SREs write software to automate tasks such as configuration management; they also write software or scripts to monitor systems and applications and help scale and build resiliency in these applications.

    Conclusion

    The real-world SRE job requisition is still evolving, and may look different from one organization to another. One thing we know for sure is that today’s high-intensity continuous delivery environments demand a cool head—someone who can toggle seamlessly across IT ops and development and successfully bring together both sides around the common goal of delivering high-performing, innovative software and features. An SRE must possess a blend of technical as well as soft skills and, perhaps most of all, must be adept at communicating effectively and inspiring a teamwide approach to excellence.

    — Dawn Parzych