devopsy.kinsta.cloud

Tag: tips

  • 5 Tips If You’re the First SRE Hire

    5 Tips If You’re the First SRE Hire

    Site reliability engineers (SREs) have a considerable set of tasks to juggle no matter where they work or how long their company has had an SRE practice. But if you’re the very first one to join an organization—as many SREs are these days, given that the trend is trickling down into smaller and smaller companies—you face a special group of challenges.

    You may find it difficult to get buy-in for SRE from other technical teams. You may struggle to know how to convince your boss that the company’s decision to hire an SRE is paying off. You probably worry that you’ll end up being overextended because you are the only SRE. And so on.

    These five tips are for site reliability engineers who find themselves in the position of being the pioneer at their companies. Whether you’re an experienced SRE who has just been hired at a company that had none previously or you’re brand-new to SRE and your first job happens to be at a company that is also brand-new to the SRE role, the following best practices will help you make the transition as smooth as possible for all involved.

    Collect SRE Metrics Early and Often

    For starters, you’ll want to be prepared to justify the business’s investment in your new role as soon as a boss or fellow engineer asks.

    Do this by collecting metrics about the technical and business impact of SREs starting as early as you can. Your goal should be to quantify how you are benefitting the organization so that you can encourage more support for yourself and any others who may be hired after you.

    On top of this, collecting metrics is also important for establishing early feedback about which SRE strategies are succeeding and which could be improved. Since you’re building an SRE practice from scratch, getting this insight early and often is critical.

    Treat Devs and IT Engineers Equally

    As you start the role, you may find some uncertainty among existing engineers about whose ‘side’ you are on. Are you there to support developers or IT engineers?

    The answer, of course, is both. Although SREs tend to borrow from software engineers’ playbooks more than they do from those of IT Ops, an SRE’s goal should be to empower and support both of these teams. So, unless you’re given explicit instructions to interface with only one group or the other, make yourself everybody’s buddy within the IT organization.

    Introduce Yourself to Non-Technical Teams

    SREs spend most of their time doing technical things with technical tools. But ultimately, the only reason they are doing what they do, in most cases, is to support non-technical users by improving the reliability of the systems they use.

    As the first SRE at a company, it may be well worth your time to get to know these non-technical stakeholders and ask them what they see as the greatest reliability issues in the organization. Building these relationships early on will help you communicate the value of your role across the organization. It’s also likely to come in handy during incident management routines, when you may need to interface with non-technical stakeholders as well as other engineers.

    Build Your SRE Tool Set

    Deciding which tools to use is an obvious early step for any SRE who is building a practice from scratch. But we didn’t put it first on this list because it’s important to get to know the rest of the organization before committing to a particular set of tools.

    As you meet the rest of the organization, ask detailed questions about which tools they use to address needs like observability, security and incident management. Then, by factoring in feedback about which tools work well and which don’t, choose which tools you’ll deploy to support SRE. Be prepared for those tools not to match your own personal preferences perfectly. You may need to prioritize the preferences of the rest of the organizations.

    Plan to Grow the Team

    Unless you have been hired at a very small company, it’s likely that the business plans to hire more SREs over time (assuming that you prove the value of the position, of course).

    Toward that end, plan for how the team will expand. Think about things like whether to use embedded SREs or create a dedicated SRE team. Think, too, about how you’ll document your company’s SRE practice and ensure it keeps operating smoothly as individual engineers come and go.

    Conclusion

    The job of a newly hired SRE is not an easy one, especially if you’re the first person at your company to fill those shoes. But by being deliberate and strategic about how you work, which data you collect and how you introduce the company to SRE, you set yourself – and your future colleagues – up for success.

  • 5 Interview Tips To Help Developers Land Their Dream Job

    5 Interview Tips To Help Developers Land Their Dream Job

    CodeFights recently launched Interview Practice Mode, a new mode on its website that enables developers to prepare for job interviews with technical questions asked by top tech companies. Interview Practice Mode marks the latest step in CodeFights’ mission to transform the way companies hire with skill-based recruiting. This feature will help developers from all backgrounds, locations and skill sets better understand their abilities, pursue lucrative job opportunities and land their dream jobs.

    For most engineering jobs, companies put candidates through rigorous technical interviews with difficult questions and coding tests. These interviews can be difficult to prepare for, especially for candidates who have never gone through a similar interview process before.

    Here are five interview tips to help developers land their dream job.

    1. Practice using real interview questions. As a great developer you often think, “This is what I do for a living and I am good at it,” so it’s tempting to walk into an interview without much practice. The reality is, interview questions you face at most companies are very far away from your day job, so make sure to do some research and practice using real questions that appear on interviews.
    2. Make sure to ask lots of questions during the interview. Some engineers think that asking questions is a sign of poor skills or lack of understanding. In reality, it’s the opposite. Most questions during technical interviews are intentionally vague and the goal of the interviewer is to see if you can ask the right questions before diving in. The worst thing you can do during a technical interview is to solve something you weren’t asked to solve. So ask questions until you are absolutely sure you have all the details.
    3. Use sites such as Glassdoor and your own network to find out the interview process at the company. At some companies, the interview process includes four or five people onsite and they all have to agree on who to hire. At others, the interview process still includes four or five people, but all are from different teams, so as long as one says, “Yes,” then you are in. Knowing what you are dealing with and the process is behind the scenes will drastically improve your chances.
    4. Apply to as many companies as you can. Some candidates make the mistake of only talking to a select few companies and trying to hit the bull’s-eye from a few shots. That works in theory, but in practice it’s very hard to understand from the outside what a company is like. Interviews are a way for you to interview the company and see if it’s a place you’d like to spend time working at. On top of that, doing more interviews is more practice and, when you get to the offer stage, having several offers helps you negotiate the best compensation package.
    5. Be mentally prepared for a negative outcome. At the end of the day, interviews are run by human beings and human beings tend to be quite subjective. So no matter how good you are and how much you prepare, most of your interviews are going to have a negative outcome. You have to be mentally prepared for that. Candidates who are used to excellence throughout their lives can take it very personally when a company decides not to hire them. You have to set your expectations right upfront so you don’t set yourself up to be disappointed.

    About the Author / Tigran Sloyan

    Tigran Sloyan is CEO of CodeFights. Tigran is the co-founder/CEO of CodeFights, a startup aiming to make improving your coding skills and finding your dream job fun and accessible to everyone in the world. Since its launch in September of 2014, CodeFights has attracted half a million users from over 200 countries becoming one of the largest developer communities in the world. Connect with him on LinkedIn and Twitter.