In our Culture and Methodologies category, dive into Agile, career development, team management, and methodologies such as Waterfall, Lean, and Kanban. Whether you're looking for tips on how to integrate Scrum theory into your team's Agile practices or you need help prepping for your next interview, our resources can help set you up for success.
The Agile methodology is a project management approach that breaks larger projects into several phases. It is a process of planning, executing, and evaluating with stakeholders. Our resources provide information on processes and tools, documentation, customer collaboration, and adjustments to make when planning meetings.
There are several paths to starting a career in software development, including the more non-traditional routes that are now more accessible than ever. Whether you're interested in front-end, back-end, or full-stack development, we offer more than 10,000 resources that can help you grow your current career or *develop* a new one.
Agile, Waterfall, and Lean are just a few of the project-centric methodologies for software development that you'll find in this Zone. Whether your team is focused on goals like achieving greater speed, having well-defined project scopes, or using fewer resources, the approach you adopt will offer clear guidelines to help structure your team's work. In this Zone, you'll find resources on user stories, implementation examples, and more to help you decide which methodology is the best fit and apply it in your development practices.
Development team management involves a combination of technical leadership, project management, and the ability to grow and nurture a team. These skills have never been more important, especially with the rise of remote work both across industries and around the world. The ability to delegate decision-making is key to team engagement. Review our inventory of tutorials, interviews, and first-hand accounts of improving the team dynamic.
Kubernetes in the Enterprise
Kubernetes: it’s everywhere. To fully capture or articulate the prevalence and far-reaching impacts of this monumental platform is no small task — from its initial aims to manage and orchestrate containers to the more nuanced techniques to scale deployments, leverage data and AI/ML capabilities, and manage observability and performance — it’s no wonder we, DZone, research and cover the Kubernetes ecosystem at great lengths each year.In our 2023 Kubernetes in the Enterprise Trend Report, we further dive into Kubernetes over the last year, its core usages as well as emerging trends (and challenges), and what these all mean for our developer and tech community. Featured in this report are actionable observations from our original research, expert content written by members of the DZone Community, and other helpful resources to help you go forth in your organizations, projects, and repos with deeper knowledge of and skills for using Kubernetes.
Empowering Citizen Developers With Low- and No-Code Tools: Changing Developer Workflows and Empowering Non-Technical Employees to Build Apps
The Meta-Retrospective is an excellent exercise to foster collaboration within the extended team, create a shared understanding of the big picture, and immediately create valuable action items. It comprises team members of one or several product teams — or a representative from those — and stakeholders. Participants from the stakeholder side are people from the business as well as customers. Meta-retrospectives are useful both as a regular event, say once a quarter, or after achieving a particular milestone, for example, a specific release of the product. The Benefits of the Meta-Retrospectives Your stakeholders are your allies, not an impediment! When we’re open about our goals and processes, collaboration with our stakeholders can shift from challenging or annoying to an extraordinary experience for all parties involved. Therefore, inviting our stakeholders to Retrospectives is a smart move. It’s a proven first step toward building trust, fostering open communication, and improving our collaboration with each other. To help facilitate this kind of Retrospective, I developed a brand-new Meta-Retrospectives template. This tool is not just for you but for your stakeholders, too, fostering a collaborative environment and strengthening your relationships. In four simple steps, your team and your stakeholders will identify: Areas where the team has improvement potential and the agency to act. Areas where the team and stakeholders need support from the leadership to improve value creation. Run the Meta Retrospectives regularly, and you will: Create a shared understanding of how you work, Set reasonable expectations and Open a channel to discuss how you can improve your cooperation. I also included an in-depth video walkthrough with the template to share my tips for getting the most out of this template. How To Run a Meta-Retrospective The Meta-Retrospective format I describe in the following text is partly based on Zach Bonaker’s WADE-matrix, extended by an additional practice at the beginning of the retrospective. To frame the level of (necessary) openness of the upcoming conversation, I run a short exercise bringing the Scrum values back into the hearts and minds of the attendees. After all, we are organizing the Meta-Retrospective to also address the elephants in the room. The Meta-Retrospective itself does not require any knowledge of agile practices and is hence suited for practically everyone. This format can easily handle 15-plus people, provided the room is large enough. It works best when there is space available where people can get together for discussions. Also, we need at least one large whiteboard in the room as most of the work will happen initially on this wall. The Scrum Values Exercise Running the Scrum values exercise is simple: Ask the participants to pair up and identify within three minutes their choice of the three most important traits that will support collaborating as a team. (I usually provide an example of what is not helpful such as yelling or pointing fingers.) Then ask every pair to introduce their choices to the rest of the attendees and put them on the whiteboard. If similar traits are already available, I ask to cluster them. Once all stickies are on the whiteboard, the facilitator steps forward and explains what Scrum values are about and why they are helping to guide a team to accomplish its task. (Make sure that you mention the topic of prospective elephants in the room that needs to be addressed in a civilized manner if Kaizen proves to be more than just a buzzword in your organization.) The facilitator then puts five stickies with the Scrum values written on them — courage, focus, commitment, respect, and openness — onto the whiteboard and asks the attendees to align their findings with the Scrum values. Once that is done, you are good to go with the Meta-Retrospective. The Meta-Retrospective Exercise Start the Meta-Retrospective by drawing the first axis onto the whiteboard and note that the axis represents a continuum. Then ask the attendees to pair up again but choose a different partner than before. Now ask them to pick their three most important learnings looking back. Time-box this creation phase to 3-5 minutes. After the stickies with the learnings are available, ask every pair to introduce them to the rest of the attendees and put them on the whiteboard. (Again, they shall cluster stickies where appropriate.) In the next step, introduce the second axis — the “influence” axis — which again is a continuum. Then ask the participants to align all stickies on the whiteboard also with the second axis. You can stop this once stickies are no longer moved on the whiteboard. Now it is time to turn the pattern into a 2-by-2 matrix and label the four quadrants accordingly: Get to work: This is the area of immediate impact. Talk to the management: These issues are impeding you; escalate them to the management. Luck: That went well but do not invest any effort in here. Keep doing: Nothing to change here at the moment. For the next step, focus on the upper left quadrant — “Get to Work” — and ignore the bottom two quadrants. Probably, there will also be time to address the upper right quadrant. (“Talk to the management.”) Start by moving the stickies from the upper left quadrant to a different part of the whiteboard and prepare them for dot-voting to figure out the ranking of the issues. (I usually issue 3-5 dots to each attendee for this purpose. The voting may take up to five minutes.) Once the voting is accomplished, generate some action items by running a lean coffee-style discussion based on the ranked issues. Meta-Retrospective: Conclusion Running a Meta-Retrospective is an excellent exercise to foster collaboration within the extended team, create a shared understanding of the big picture, and immediately create valuable action items. Best of all: it takes less than two hours to make the ideas of avoiding ‘Muda’ and practicing ‘Kaizen’ tangible to everyone.
The Importance of Soft Skills While technical competency is undoubtedly crucial, many experienced developers often overlook the significance of soft skills in their pursuit of career advancement. These non-technical abilities are the glue that holds teams together and enables effective collaboration, communication, and problem-solving. Some key soft skills that senior engineers should cultivate include: 1. Communication The ability to communicate complex technical concepts clearly and concisely, both verbally and in writing, is invaluable. Senior engineers often act as translators between stakeholders and technical teams. 2. Teamwork and Mentoring Leading by example, fostering collaboration, and guiding junior team members are hallmarks of senior engineers. They create an environment that encourages learning and growth. 3. Problem-Solving Senior engineers excel at breaking down complex problems into manageable components and devising innovative solutions. They can think critically and approach challenges from multiple perspectives. 4. Time Management With multiple projects and responsibilities, senior engineers must prioritize tasks effectively and manage their time efficiently to meet deadlines without sacrificing quality. Beyond the Code: Broader Perspectives In addition to soft skills, senior engineers need to develop a broader understanding of the business and the industry they operate in. This holistic view enables them to make more informed decisions and align their work with organizational goals. Business acumen: Understanding the company’s business model, target market, and competitive landscape allows senior engineers to appreciate the broader context and impact of their work. Industry trends: Staying up-to-date with emerging technologies, best practices, and industry trends ensures that senior engineers can adapt and evolve with the ever-changing technological landscape. Cross-functional collaboration: Software development rarely happens in a vacuum. Senior engineers must collaborate effectively with designers, product managers, and other stakeholders to deliver comprehensive solutions. Continuous Learning and Growth Mindset Perhaps the most crucial aspect of becoming a senior engineer is the willingness to embrace continuous learning and maintain a growth mindset. Technology evolves rapidly, and complacency can quickly render even the most experienced engineers obsolete. Seek out opportunities to learn from colleagues, attend conferences and workshops, and stay curious about emerging trends and technologies. Cultivate a mindset of humility, recognizing that there is always more to learn and room for improvement. Contribute Beyond Code As developers progress in their careers, their impact extends beyond writing code. Senior engineers often take on leadership roles, mentoring junior team members, contributing to architectural decisions, and shaping the overall technical direction of projects. Embrace opportunities to share knowledge through documentation, blog posts, or workshops. Participate in code reviews, providing constructive feedback and fostering a culture of continuous improvement. Engage in open-source projects or community initiatives, further expanding your influence and contributing to the broader tech community. Conclusion Becoming a senior engineer is a journey that requires dedication, perseverance, and a holistic approach to skill development. While technical expertise is undoubtedly crucial, it is merely the foundation upon which a well-rounded senior engineer is built. Invest in cultivating soft skills, broadening your perspectives, embracing continuous learning, and contributing beyond code. By doing so, you’ll not only enhance your chances of career advancement but also become a more valuable asset to your team and organization, capable of driving innovation and delivering impactful solutions. Remember: the path to becoming a senior engineer is not a destination, but a continuous journey of growth, adaptation, and learning. Embrace the challenge, and you’ll unlock a world of opportunities and personal fulfillment in your career.
I am an avid reader of technical books, specifically those focused on Cloud, DevOps, and Site Reliability Engineering (SRE). In this post, I will share a list of books that I believe are essential for anyone looking to start or advance their career in Cloud, DevOps, or SRE. These books will help you build a strong foundation in the top skills required in these fields. While this post focuses primarily on Amazon AWS for public cloud, I will also include a few vendor-neutral books. Note: This is my honest opinion, and I am not affiliated with any of these book authors or publishers. How Linux Works, 3rd Edition: What Every Superuser Should Know by Brian Ward and the Linux Command Line, 2nd Edition by William Shotts Learning Linux is the first step before acquiring any other skills in DevOps. These books are excellent for building a strong foundation in Linux internals and getting familiar with the Linux command line, which is essential for excelling in the DevOps space. Python Programming is the second most important skill after Linux for DevOps or SRE. I recommend starting with Python Cookbook: Recipes for Mastering Python 3. Begin with the basics, then move on to object-oriented concepts, databases, APIs, and scripting. Eventually, you should learn about MVC and other design patterns to build comprehensive products, not just scripts. As a production engineer, you will need to develop many infrastructure tools. Solutions Architect's Handbook — Third Edition and AWS Cookbook These books provide a comprehensive view of what an AWS engineer needs to know. They were particularly helpful in preparing for the AWS Solution Associate exam, covering topics such as MVC architecture, domain-driven design, container-based application architecture, cloud-native design patterns, and performance considerations. The AWS Cookbook is excellent for practical labs and contains useful topics like secure web content delivery, dynamic access with security groups, automated password rotation for RDS, and big data solutions. Terraform up and Running by Yevgeniy Brikman Terraform is a widely used infrastructure automation tool in DevOps. This book covers the basics, and intermediate topics like managing state files, creating reusable modules, Terraform syntax, and more. It also addresses the challenge of managing secrets and provides options for integrating with Docker and Kubernetes. The book concludes with strategies for managing Terraform code within a team. Continuous Integration and Deployment This skill is crucial for developers, DevOps, SRE, or any engineer involved in development or operations. Tools like Jenkins, GitLab, and GitHub Actions are commonly used. For Kubernetes environments, GitOps tools like Flux and ArgoCD are popular. I recommend Automating DevOps with GitLab CI/CD Pipelines by Christopher Cowell for those starting with CI/CD. Kubernetes This technology has been trending and growing rapidly. For theoretical knowledge, the Kubernetes documentation is sufficient, but for hands-on learning, I recommend The Kubernetes Bible: The Definitive Guide to Deploying and Managing Kubernetes Across Cloud and On-Prem Environments. Microservice development and deployment are on the rise. For AWS, small microservices-based products can be deployed with ECS but for large-scale products, Kubernetes is required. System Design This is a vendor-neutral skill. I recommend Designing Data-Intensive Applications by Martin Kleppmann to learn how to build reliable and scalable systems. Finally, I acknowledge that merely reading books won't make you an expert. You need to engage in extensive hands-on labs to excel in this field.
There is no shortage of technical events such as conferences, meetups, trainings, hackathons, and so on. These events are a great way to learn new things, connect with people, and share knowledge with others. One of the most valuable and exciting ways to share knowledge is by giving a technical presentation. Today, we will look at how to submit a technical presentation for an event and get some personal recommendations from me, as well. Though we will specifically gear the information for the NODES 2024 call for proposals, nearly everything discussed can be applied to other technical events and speaking engagements. Let's get started! Event Research No matter what event you are interested in, do your research! Find out about the event, their goals, the audience, and the types of presentations they are looking for. This information will help you decide if the event is a good fit, as well as help you tailor your submission to the attendees. NODES 2024 is devoted to technical presentations related to graph data and technologies, with a special focus on community stories and perspectives. The audience will be looking for content to inspire ideas, learn how to do/build something, gather tips and tricks, and add skills to their toolbelt for business or personal projects. Developers, data scientists, and other technical professionals are the core audience. NODES 2024 Promo Now let's decide whether to speak. Speakers Wanted! Deciding to submit a presentation to an event is a commitment. It can be intimidating to put yourself out there and share your knowledge with others, plus the effort and time it takes to build and polish your content. But it can also be a rewarding and invigorating experience. I always remind myself that my experience and learning journey is unique and can hopefully inspire or help someone else. Everyone can contribute value to a conversation! As a speaker, you will have the opportunity to share your expertise, connect with others, and learn from the community. Yes, a speaker can (and should) learn from attendees. Understanding what problems others are solving or where gaps are can help you learn more about your topic, plus improve your future content. :) NODES 2024 will be virtual, so no travel or logistics are required. The event will be held over 24 hours, and sessions will be recorded and available for attendees to watch on-demand after the event. So you will have the opportunity to reach a global audience, as well as promote or provide evidence for your efforts! So, if you are thinking about submitting a presentation to an event, go for it! And if you have decided to submit, congratulate yourself on being courageous and taking the first step. If you're still on the fence, take some time to think about it and consider reaching out to the event organizers or other speakers for advice. I'm always happy to chat about speaking and help others get started! Deciding on a Topic Choosing a topic for your presentation can be challenging. You want to pick something that you are passionate about, that you have experience with, or want to learn about. Try to pick things you like or love. That enthusiasm will come through in your presentation and help keep you motivated as you prepare. If you're interested in the topic, it's likely that someone else will be, too. What projects or technologies are you currently working on? What problems have you solved or are trying to solve? What tools or techniques have you found helpful? What do you wish you knew when you started working with a technology? What mistakes do you want to help others avoid or learn from your experience? For NODES 2024, the event is focused on graph data and technologies to interact with graphs. Here are some topic ideas to get you started: How graphs solve a specific problem (broad or narrow) How to build applications that interact with a graph How graphs integrate with AI/GenAI Mistakes or pitfalls to avoid with graph databases, tools, use cases, and more How to interact with or get data into or out of a graph database Working with graphs in a larger system or architecture (including improving operations) This list could continue on, but hopefully, these give some good starting points. Once you have a topic in mind, it's time to write a session abstract and submit it! Session Abstract and Submission The session abstract is a short description of your presentation that will be used to promote your session to attendees. It should be clear, brief, and interesting. It should give attendees an idea of what to expect from your presentation and why they should attend. There are a few things I always look for when I'm on a program committee choosing sessions for an event. Title Aim for a descriptive phrase that gives attendees an idea of what your presentation is about. If you have a clever or catchy title, that's always a plus (but not required), and make sure it still states your topic. Abstract This is the core of your submission. It should detail what you will cover in your presentation, such as the problem you are solving, what aspects of a technology are involved, what tools could be used, and what attendees will learn. Notes for the Committee Include any additional information for the committee here. This could be special requirements or why your content is a good fit for the event. I like to include why I felt my topic is important and/or how my experience could help others. Keep this part brief, but it can help differentiate when there are multiple sessions with similar topics. Bio For a bio about yourself, keep it short, but be sure to outline your experience and specialties. If you have content or socials, highlight 1-2 accounts so that attendees or program committee members can learn a bit about you. There are also a few other things to keep in mind when writing your abstract. Audience Who is your presentation for? What's their level of experience? What will they gain from attending your session? Choose wording and technologies that resonate with your audience to help readers connect with your content. Format/Length Will your presentation be a talk, a demo, a workshop, a panel, or something else? Are you giving a demo or live coding? Sometimes you select a format on the submission form, but you can also mention sub-formats with terms like live demo, hands-on, interactive discussion, etc. I also recommend writing your abstract in a text editor or word processor first. This way, you can easily check for spelling/grammar errors, and you can save your work to reuse or reference later. Editors also typically include work/character counting tools to help track length. Once you have your abstract written, you can copy and paste it into the submission form. Tips and Tricks There are a few things that can help make your abstract stand out and increase your chances of being selected. On the flip side, there are a few things to avoid that can hurt your chances. Be Descriptive + Brief Provide enough details within 1-3 paragraphs so the program committee and attendees get a clear picture of what you will present. If you use jargon or acronyms, explain them. Even if attendees to your session are familiar with them, the program committee may not be, and that can make them feel less confident accepting a session. You can always explain acronyms in the notes section if you're unsure. Be Inviting You don't need fancy or fluent language, but a genuine passion or interest in your topic can go a long way. If you are excited about your topic, it will show in your abstract and presentation. Be Honest Developers (especially) don't like to be misled. Avoid hiding negative aspects and sales or marketing tactics. Honesty and authenticity build respect. There are also some things to avoid when it comes to abstract submissions. Minimal Effort People can tell when you don't care. One-line abstracts and bare minimum details can tell readers that you don't care about the topic or helping others learn. It's okay to be brief, but make sure to provide enough information to be helpful. In It for Me Attendees are giving up their time and focus to attend your session, event organizers are pouring money and time into the event, and companies are sponsoring the event or employees. They deserve valuable content in return. It's not about the speaker, it's about the attendee. Speakers are only valuable if they have an audience. Don't cause readers to be like Picard and Riker here. ;) For NODES 2024, all of these things apply, but there are a couple of additional things to keep in mind. The event is focused on graph data and technologies to interact with graphs. Be sure to mention how graphs are involved in your topic (I've seen abstracts that don't mention them at all!). Also, NODES is meant to showcase community stories and real-world uses, so be sure to include your honest, unique experience or perspective in your abstract. Sessions are geared for technical audiences, so try to include aspects such as architecture, demos, code, tools, solutions, and so on. Even if you don't write live code, you can still show code snippets or tool screenshots to help illustrate your points. Wrapping Up! Today, we walked through how to submit a technical presentation for an event. We discussed doing your research, deciding on a topic, writing a session abstract, and preparing for your presentation. We also covered some tips and tricks for writing a valuable abstract that will hopefully increase your chances of being selected. If you are interested in submitting a presentation to NODES 2024, the call for proposals is open until June 15, 2024. You can find more information and submit your presentation here. Happy coding and best wishes on your submissions!
Software development can be tricky. One of the biggest challenges can be choosing the right approach. The traditional "waterfall" method can be frustrating, with its inflexible plans, slow release cycles, and lack of agility. Fortunately, the Agile revolution brought new options that promise faster releases and greater flexibility. However, with so many Agile frameworks to choose from, it can be difficult to know which is the best fit for your team. In this article, I will explore two popular Agile methodologies — Scrum and Kanban — and help you understand their strengths and weaknesses. By the end, you'll have a better idea of which approach is right for your team. Scrum Scrum is a structured and intense method that works well for teams that thrive on focused bursts of activity. It involves: Timeboxed sprints: Scrum uses fixed-length iterations called "sprints" that usually last two to four weeks. Each sprint focuses on a clearly defined set of goals that are meticulously planned in a "sprint planning" session. Defined roles and responsibilities: Scrum introduces specific roles — the Product Owner, the Scrum Master, and the Development Team. This clear separation fosters accountability and keeps everyone focused on the sprint goal. Daily scrums: These are short, daily meetings where team members share progress updates, roadblocks, and dependencies. The Good, the Bad, and the Burndown Chart When it comes to organizing projects, Scrum can be a good choice if the requirements are clear and there's a defined vision. By breaking the work into sprints, progress can be tracked using a "burndown chart," which can help keep the team motivated. However, Scrum might not be the best fit for projects with constantly changing requirements. The focus on sprints can make it hard to be flexible, and daily stand-ups can be time-consuming for smaller teams. For instance, when we developed a new enterprise application with well-defined features, Scrum was very helpful. We were able to stay focused and make predictable progress. However, when we started working on a mobile app with lots of user feedback, Scrum's rigid structure became more of a hindrance than a help. Kanban Kanban is a flexible development approach that's great for environments where change is inevitable. Here's how it works: You start with a board that has columns representing the different stages of your workflow, such as "To Do," "In Progress," and "Done." You then place tasks on cards and move them between the columns as they progress through the workflow. This creates a visual representation of your workflow that allows you to see how work is flowing at a glance. To prevent bottlenecks and ensure smooth workflow, Kanban emphasizes the importance of limiting the number of tasks in each stage. This is called Work-in-Progress Limits. Kanban encourages teams to continuously improve their processes by regularly analyzing their workflow and identifying areas for improvement through retrospectives. This helps teams optimize their processes for better results. Focus on Flow, Not Sprints Kanban is a system that works well when requirements change frequently. There are no predetermined sprints, which means it can respond more quickly to new priorities. The Kanban board visualizes the flow of work through the system, and the main focus is to maintain this continuous flow. However, Kanban can feel less structured than Scrum. The lack of sprint goals can sometimes lead to a lack of direction, and unfinished tasks may stay in the "In Progress" stage if there's no strong discipline. When we switched to the mobile app, Kanban provided real-time visibility into our workflow, which helped with collaboration. Limits on work in progress ensured that everything was manageable, and thanks to the continuous focus on improvement, we could make changes to our process as user feedback came in. Scrum vs. Kanban Scrum and Kanban are two popular Agile frameworks used for software development. They have different approaches to structure, planning, work management, and change management. Here’s a more concise comparison: Feature Scrum Kanban Structure Fixed Sprints Continuous Flow Roles Defined Roles No Predefined Roles Planning Sprint Planning Ongoing Planning Goals Sprint Goals Flow Management Change Management Less Adaptable More Adaptable Reviews Sprint Reviews Regular Retrospectives Structure Scrum and Kanban are two different approaches to managing projects. Scrum has a more defined framework, dividing the work into fixed-length iterations called sprints that usually last 2-4 weeks. These sprints have a set workflow that includes a planning meeting, a daily check-in, and a review meeting. On the other hand, Kanban is more flexible and adaptable. It follows a continuous flow model and visualizes the work on a board with different stages, such as "To Do," "In Progress," and "Done." Planning and Work Management When using Scrum, planning is done at the start of each sprint. The team sets goals and creates a list of tasks called a product backlog, which is then prioritized by the Product Owner. The amount of work done is limited to what can be achieved within the sprint timeframe. On the other hand, Kanban has a more ongoing planning approach. Tasks are added to the Kanban board as they are needed, and work-in-progress (WIP) limits are established for each stage of the workflow to avoid bottlenecks and ensure smooth workflow. Change Management Scrum requires the team to focus on completing pre-determined goals within a fixed timeframe, known as a sprint. However, once a sprint has begun, it can be challenging to make changes to these goals. On the other hand, Kanban offers more flexibility. The team can add new tasks to the Kanban board as needed, making it easier to adjust their workload and priorities. The use of Work In Progress (WIP) limits also helps the team to manage their workload more efficiently. Review and Retrospection Scrum uses sprint reviews and retrospectives to assess progress, identify roadblocks, and improve the following sprint. Kanban, on the other hand, uses regular retrospectives to analyze the workflow, identify areas for optimization, and continuously refine their process. Choosing the Right Framework When it comes to selecting a framework for your project, there are several factors that you need to consider. Choosing the right framework depends on your project's specific requirements, as well as the needs and capabilities of your team. If your project has clearly defined goals and requirements, and you need to complete the work in short intervals, then Scrum can be a good choice. Scrum is a framework that emphasizes teamwork, collaboration, and frequent feedback. It is designed to help teams work on complex projects by breaking them down into smaller, more manageable tasks. Scrum is particularly effective for projects that require a high degree of concentration and focus, with regular check-ins and progress updates. On the other hand, if your project has constantly changing requirements and needs to be flexible and adaptable, then Kanban might be a better fit. Kanban is a framework that emphasizes visualizing work, limiting work in progress, and maximizing flow. It is designed to help teams manage their workflow by focusing on the tasks that are most important at any given time. Kanban is particularly effective for projects that are subject to frequent changes and adjustments, as it allows teams to respond quickly and efficiently to new requirements or priorities. Ultimately, your choice between Scrum and Kanban (or any other framework) will depend on your specific needs and circumstances. By carefully evaluating your project requirements and team capabilities, you can make an informed decision that will help you achieve your goals and deliver a successful outcome. The Hybrid Hero: Scrumban If you find yourself in a dilemma between two popular project management methodologies, Scrum and Kanban, there is an alternative approach that you might want to consider: Scrumban. It is a hybrid of both methodologies and provides you with the benefits of their most effective features. For instance, you can use the sprint planning technique from Scrum and combine it with Kanban's work-in-progress (WIP) limits and emphasis on continuous flow. This approach enables you to leverage the strengths of both methodologies, resulting in an optimized workflow that is tailored to your specific needs. The Final Verdict It's important to understand your project's needs and your team's strengths when choosing an Agile methodology like Scrum or Kanban. There's no one-size-fits-all solution, but by examining both options, you can make an informed choice that will help your team deliver high-quality software. Remember that collaboration, continuous improvement, and adaptability are key to success. Experiment with both Scrum and Kanban by running pilot projects to see which works best for your team. As your team evolves and your projects change, your Agile framework should change, too, to keep empowering your team. The most important thing is to create a culture of openness and communication where everyone feels empowered to contribute. With the right Agile methodology in place, you can navigate the ever-changing tech landscape with agility and innovation.
The acronym "Ops" has rapidly increased in IT operations in recent years. IT operations are turning towards the automation process to improve customer delivery. Traditional application development uses DevOps implementation for Continued Integration (CI) and Continued Deployment (CD). The exact delivery and deployment process may not be suitable for data-intensive Machine Learning and Artificial Intelligence (AI) applications. This article will define different "Ops" and explain their work for the following: DevOps, DataOps, MLOps, and AIOps. DevOps This practice automates the collaboration between Development (Dev) and Operations (Ops). The main goal is to deliver the software product more rapidly and reliably and continue delivery with software quality. DevOps complements the agile software development process/agile way of working. DataOps DataOps is a practice or technology that combines integrated and process-oriented data with automation to improve data quality, collaboration, and analytics. It mainly deals with the cooperation between data scientists, data engineers, and other data professionals. MLOps MLOps is a practice or technology that develops and deploys machine learning models reliably and efficiently. MLOps is the set of practices at the intersection of DevOps, ML, and Data Engineering. AIOps AIOps is the process of capabilities to automate and streamline operations workflows for natural language processing and machine learning models. Machine Learning and Big Data are major aspects of AIOps because AI needs data from different systems and processes using ML models. AI is driven by machine learning models to create, deploy, train, and analyze the data to get accurate results. As per the IBM Developer, below are the typical “Ops” work together: Image Source: IBM Collective Comparison The table below describes the comparison between DevOps, DataOps, MLOps, and AIOps: Aspect DevOps DataOps MLOps AIOps Focus on: IT operations and software development with Agile way of working Data quality, collaboration, and analytics Machine Learning models IT operations Key Technologies/Tools: Jenkins, JIRA, Slack, Ansible, Docker, Git, Kubernetes, and Chef Apache Airflow, Databricks, Data Kitchen, High Byte Python, TensorFlow, PyTorch, Jupyter, and Notebooks Machine learning, AI algorithms, Big Data, and monitoring tools Key Principles: IT process automation Team collaboration and communication Continuous integration and continuous delivery (CI/CD) Collaboration between data Data pipeline automation and optimization Version control for data artifacts Data scientists and operations teams collaborate. Machine learning models, version control Continuous monitoring and feedback Automated analysis and response to IT incidents Proactive issue resolution using analytics IT management tools integration Continuous improvement using feedback Primary Users Software and DevOps engineers Data and DataOps engineers Data scientists and MLOps engineers Data scientists, Big Data scientists, and AIOps engineers Use Cases Microservices, containerization, CI/CD, and collaborative development Ingestion of data, processing and transforming data, and extraction of data into other platforms Machine learning (ML) and data science projects for predictive analytics and AI IT AI operations to enhance network, system, and infrastructure Summary In summary, managing a system from a single project team is at the end of its life due to business processes becoming more complex and IT systems changing dynamically with new technologies. The detailed implementation involves a combination of collaborative practices, automation, monitoring, and a focus on continuous improvement as part of DevOps, DataOps, MLOps, and AIOps processes. DevOps focuses primarily on IT processes and software development, and the DataOps and MLOps approaches focus on improving IT and business collaborations as well as overall data use in organizations. DataOps workflows leverage DevOps principles to manage the data workflows. MLOps also leverages the DevOps principles to manage applications built-in machine learning.
TL; DR: Top Five Rookie Mistakes by Self-Proclaimed Scrum Masters Are you struggling with imposter syndrome as a new Scrum Master? Avoid five common rookie mistakes Scrum Masters make. Instead, discover how to set clear Sprint Goals, build trust, balance metrics, and empower your team to make independent decisions. Don’t let early missteps define your journey. Learn from these mistakes and transform them into stepping stones towards mastery. By understanding and addressing these pitfalls, you’ll gain confidence, enhance your leadership skills, and truly embody the principles of Scrum. This article provides actionable insights and practical exercises to help you grow from a beginner into an effective and respected Scrum Master. Rookie Mistakes Scrum Masters Make Let us delve into the rookie mistakes Scrum Masters make: 1. Ignoring the Importance of the Sprint Goal Mistake: Treating the Sprint Goal as optional or just a list of tasks, leading to a lack of focus and direction for the Scrum Team Why it’s a mistake: The team lacks a unified purpose without a clear Sprint Goal, resulting in fragmented efforts, reduced overall value delivery, and difficulty measuring success. The team may become directionless, working on tasks that don’t align with the Product Goal or the strategic objectives of the product generally. Learning opportunity: Legitimate beginners quickly realize the importance of a well-defined Sprint Goal as a beacon guiding the team’s efforts. It fosters collaboration and ensures that the team delivers meaningful value each Sprint. To practice this, try a Sprint Goal workshop before the next Sprint, where the team collaborates to draft a clear, cohesive goal. 2. Micromanaging the Team Mistake: Acting as a task or project manager, constantly overseeing and directing the work of the Developers Why it’s a mistake: Scrum Masters should serve the team by removing impediments and facilitating processes, not controlling the work as the Developers have agency doing their part. Micromanagement stifles team autonomy and innovation, leading to reduced morale and a lack of ownership among team members, ultimately hampers productivity and creativity. Learning opportunity: True beginners learn to trust their team’s capabilities, focusing instead on enabling the team to self-organize and resolve issues independently, leading to higher engagement and better problem-solving. An exercise to help with this is to restrain from solving issues during a Sprint but observe and support their teammates’ progress. 3. Neglecting To Build Team Trust and Psychological Safety Mistake: Failing to create an environment of trust and psychological safety where all team members feel comfortable sharing ideas and concerns Why it’s a mistake: Without trust and safety, team members are less likely to engage fully, collaborate effectively, or take risks. Neglecting trust stifles innovation and continuous improvement, leading to a work environment with undisclosed problems, lackluster team engagement, and restrained creativity. It can also result in high turnover and low job satisfaction. Learning opportunity: Proficient Scrum Masters actively work to build and maintain a culture of trust and psychological safety. They encourage open communication and constructive feedback. A practical exercise is to hold regular team-building activities and trust exercises, such as sharing personal success stories, challenges, and failures to build empathy and understanding among team members. 4. Focusing Solely on Metrics and Reporting Mistake: Overemphasizing metrics, OKRs, and KPIs, turning the Scrum Master role into a data-entry clerk burdened with excessive reporting Why it’s a mistake: While metrics can provide valuable insights, overemphasis can distract from the true purpose of Scrum, which is delivering value through collaborative efforts and continuous feedback based on frequent releases and an empirical process. A metrics-driven approach can also lead to gaming the system, where team members focus on meeting the metrics rather than creating genuine value, thus distorting the team’s priorities. Learning opportunity: Effective Scrum Masters balance metrics with qualitative insights, using them to support, not dictate, team decisions and progress. They understand that metrics are tools, not goals in themselves. An exercise to implement this is to periodically review the metrics with the team, discussing their relevance and how they align with actual value delivery, ensuring a balanced approach. 5. Failing To Empower the Team Mistake: Not empowering the team to make decisions and solve problems, often stepping in to make decisions or resolve conflicts Why it’s a mistake: This approach undermines the team’s confidence and ability to self-manage, leading to dependency on the Scrum Master and reduced team ownership of the work. It hampers the team’s growth, creativity, and innovation ability, as members are not encouraged to think independently or take initiative. Learning opportunity: Good Scrum Masters learn to step back and facilitate the team’s decision-making processes, encouraging team members to take ownership of their work and develop their problem-solving skills. A helpful exercise is to use a decision matrix, for example, based on the outcome of a Delegation Poker session, where the team collaboratively decides on solutions to issues without direct intervention from the Scrum Master, promoting autonomy and confidence. Useful Practices for Beginners To Avoid Rookie Mistakes Scrum Masters Make Some food for thought for the aspiring learner: there is no need for you to reinvent the wheel. Embrace Continuous Learning Scrum Masters should always be on a path of continuous learning. Scrum and agile practices evolve, and so should your understanding and application of them. Seek opportunities for training, certifications, and networking with other Scrum professionals. For example, join the Hands-on Agile Slack community or our Meetup group. Understand the Organizational Context Every organization has its unique culture and challenges. Understanding the broader context within which your team operates can help you better support and advocate for Scrum practices. Engage with stakeholders and management to align Scrum with organizational goals. Remember, you cannot change a system at the Scrum team level. Balance Empathy With Accountability Building a high-performing team requires a delicate balance of empathy and accountability. While fostering a supportive environment is crucial, holding the team accountable to commitments and quality standards is equally important. Great Scrum teams hold themselves accountable all the time; they are professionals. Be a Servant Leader As a Scrum Master, your primary role is to serve the team, for example, by removing impediments, facilitating communication, and supporting the team’s self-organization. The team’s success measures your success, so focus on empowering them. Adaptability Is Key No two teams are the same, and what works for one might not work for another. Be flexible and willing to adapt your approach based on the team’s needs and feedback. Continuously inspect and adapt not just the team’s processes but your own practices and mindset. Foster a Growth Mindset Encourage a culture where failure is seen as an opportunity to learn and grow. Coupled with a growth mindset, it can significantly enhance the team’s ability to innovate and improve continuously. Celebrate successes but also openly discuss failures and the lessons learned from them. Value Feedback Loops Feedback is the cornerstone of continuous improvement. Make sure your team regularly seeks and gives feedback, not just during formal events like Sprint Reviews and Retrospectives but also in daily interactions. Feedback taken seriously will help identify issues early and promote a culture of transparency and improvement. Conclusion The critical difference between the rookie mistakes of the ignorant imposter and the actions of a learning beginner is the willingness to reflect, adapt, and grow from experiences. Self-proclaimed experts who misunderstand and, consequently, misapply the principles of Scrum fail to recognize and rectify their mistakes. At the same time, true beginners use these early missteps as stepping stones toward becoming effective and respected Scrum Masters.
The majority of program management encompasses two types of post-incident or post-project review: “pre-mortem” and “post-mortem.” A pre-mortem typically occurs during the project initiation phase, where potential risks are forecast before the project begins and a plan to mitigate these risks is developed. In contrast, a post-mortem occurs following the closing phase of the project, where an analysis of “what went well” and “lessons learned” is conducted. This enables the identification of areas for improvement and their incorporation into subsequent releases or other projects. These exercises are valuable learning and planning tools for every program. A mid-mortem is equally important as the other "mortems." It is essential to understand the nature and significance of a mid-mortem. What Is a Mid-Mortem? A mid-mortem, a self-initiated review exercise, can be conducted by anyone involved in the project at any time during its lifecycle. The primary objective of a mid-mortem is to evaluate the current status of the project and its challenges in relation to its predetermined goals and milestones. How Does a Mid-Mortem Work? This review is a collaborative effort to address the challenges faced by the project. For each challenge, your team should brainstorm potential impacts and formulate recommendations. Assessing each challenge thoroughly will enable the creation of a robust recommendation plan approved by program leads. It is important to approach this activity as a team, as different members may have unique perspectives and suggestions for each challenge. The second part of the mid-mortem is the project review where you measure the project status against the project goals and milestones you have outlined at the beginning of the project. Once the mid-mortem is complete, the program manager or engineering manager is responsible for ensuring that all approved recommendations are executed promptly. This may involve allocating additional resources, adjusting the project schedule, or making changes to the project plan. Different Challenges Faced by the Project That You May Need To Consider During a Mid-Mortem Scope Creep Potential Impacts Unrealistic project expectations Increased project costs Delays in project completion Reduced project quality Impacts the project timeline This leads to escalation from the management team Resource Constraints Potential Impacts Delays in project completion Reduced project quality Increased stress on project team members Technical Complexity Potential Impacts Unanticipated technical challenges Delays in project completion Increased project costs Communication and Collaboration Potential Impacts Misunderstandings among team members Delays in project completion Reduced project quality Stakeholder Management Potential Impacts Unrealistic expectations from stakeholders Delays in project completion Reduced project quality How It Adds Value A mid-mortem is unique because it presents an opportunity to assess risks and challenges during project execution. Forecasting risks in a complex, multi-year project is challenging, as during a project things are dynamic and may not go according to plan. This dynamic environment creates a need for a mid-mortem. It is important to note, as previously conveyed, that these activities are not addressed in either the pre-mortem framework due to the absence of precise forecasting capabilities or in the post-mortem framework, as it is beyond the scope of retrospective analysis and action-taking in the post-mortem phase. There are various ways in which a mid-mortem adds value: Ensuring timely corrective actions are taken to address project risks Providing clear recommendations for each challenge faced Fostering transparency and alignment among stakeholders and leadership Conclusion The midterm review is an essential tool for ensuring the successful completion of any project. By taking the time to assess the project's progress, identify challenges, and make necessary adjustments, project managers can help ensure that their projects are delivered on time, within budget, and to the satisfaction of all stakeholders.
Agile project management is all about breaking down complex tasks into manageable pieces and accurately estimating their effort. Two key techniques in this process are story point estimation and story splitting. Understanding how these two practices intersect can significantly boost your team's productivity and project outcomes. Let's look into the relationship between story point estimation and story splitting and demonstrate how your Agile workflows can benefit from both. What Is Story Point Estimation? A fundamental concept in Agile project management is story point estimation. It is a technique for estimating the amount of work, complexity, and risk involved in finishing a user story. Instead of using hours or days, teams use story points to maintain a relative sizing approach. So, why story point? They help teams focus on the effort rather than the time it might take to complete a task. This method accounts for uncertainties and variations in productivity, making it more adaptable to different scenarios. How Do Story Points Work? Teams assign a numerical value to each user story. These values are often based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or the T-shirt sizes, which reflects the idea that larger numbers or sizes should represent exponentially more effort. Here's a quick breakdown: Fibonacci Sequence T-Shirt Sizes Details 1 point XS A very simple task with minimal complexity 2-3 points S Slightly more complex tasks but still manageable within a short period 5-8 points M Tasks that require more effort, likely involve multiple aspects and potential risks 13 points and above L and above Highly complex tasks that might need to be split into smaller, more manageable pieces The team can more efficiently plan their sprints, prioritize tasks, and spot potential bottlenecks by assigning story points. Story points give a clearer picture of the workload and help in making informed decisions about task assignments and deadlines. What Is Story Splitting? Story splitting is another essential technique in Agile project management. It's all about breaking down large, complex user stories into smaller, more manageable pieces. This practice not only makes the workload more approachable but also ensures that each piece can be completed within a single sprint. Why Split Stories You might wonder why we need to split stories at all. The main reasons include enhanced manageability, increased focus, and better alignment with sprint goals. Smaller stories are easier to track and complete, making planning and execution more straightforward. They allow teams to focus on specific tasks, leading to higher-quality outcomes and consistent value delivery. When To Split Stories Not all stories need splitting, but certain signs indicate when it might be necessary. If a story is too large to be completed within a single sprint, has multiple acceptance criteria, or if the requirements are vague, it's a good candidate for splitting. Effective methods for story splitting include dividing by workflow, business rules, or data variations. For instance, a feature requiring design, development, and testing can be split into three separate stories. Similarly, a payment system could be split into stories for credit card payments, PayPal payments, and so on. By splitting the story, the team can tackle each part step-by-step, making progress visible and manageable. How Story Point Estimation Can Help in Story Splitting Story point estimation and story splitting are like two sides of the same coin, working together to streamline Agile project management. Teams may efficiently select when and how to split stories by using story points to identify overly complicated or large stories. This ensures that each element is manageable and deliverable within a sprint. Identifying Complex Stories Story points help teams gauge the complexity and effort required for each user story. When a story receives a high point value, it's a signal that the story might be too large or complex to handle in one go. This is where story splitting comes in handy. By breaking down a high-point story, the team can transform it into smaller, more digestible pieces. Techniques for Splitting Stories Using story points to guide splitting can be quite straightforward. For example, if a story is assigned 13 points, the team can look at the tasks involved and split them based on different criteria such as workflow stages, business rules, or data variations. Imagine a project involving a new user registration feature. If this story is estimated at 13 points, the team might split it into parts like designing the registration form (2 points), implementing the front-end (3 points), creating the back-end logic (5 points), and setting up email verification (3 points). This approach breaks down the complexity and makes each task more manageable. How Story Splitting Can Help Story Point Estimation Story splitting doesn't just make tasks more manageable; it also plays a crucial role in refining story point estimation. By breaking down complex stories into smaller, clearer tasks, teams can enhance the accuracy of their estimations, leading to better planning and execution. Simplifying Estimation When stories are too large or complex, estimating their effort can be challenging and often inaccurate. Splitting these stories into smaller parts simplifies the estimation process. Each smaller story is more straightforward to understand, making it easier for the team to assign accurate story points. Improving Accuracy Smaller stories come with more specific requirements and less ambiguity. This clarity allows the team to make more precise estimations. For example, a large story like "Implement user authentication" might be vague and hard to estimate accurately. By splitting it into smaller stories such as "Design login UI," "Develop front-end login functionality," and "Set up back-end authentication," each part becomes easier to evaluate and estimate accurately. Real-World Application Let's say a team is tasked with developing a feature for generating sales reports in an application. Initially, the story might seem daunting, and estimations could range wildly. By splitting the story into smaller tasks—such as creating the report UI, implementing data fetching, and adding filtering options—the team can provide more accurate story point estimates for each part. This not only improves the reliability of the estimates but also makes the planning process smoother and more predictable. Final Words Story splitting and story point estimation work well together in Agile project management. Accurately estimating story points helps teams identify complex tasks that need to be broken down, making them manageable within a sprint. On the other hand, breaking up stories into more manageable, well-defined tasks improves the precision of story point estimates, which results in more effective planning and execution. Adopting these techniques can transform your Agile processes, making your team more efficient and your projects more predictable.
From the day I wrote my first Hello World program, it took me two years to land a job at Amazon and another two years to get into Google. That’s because I accomplished this without having a Computer Science degree or attending a boot camp. I made countless mistakes along the way which made my path to becoming a Software Engineer longer than it should have been. I spent countless hours watching YouTube tutorials and paid for numerous Udemy courses, only to find that they added no real value. If I could go back in time and undo all the things that didn't work, I would be in the exact same situation as today within six months of starting programming. That’s exactly why I am writing this helpful piece. Today, I'll cut out all the unnecessary fluff and provide you with the quickest route from beginner to full-time Software Engineer. Avoiding Common Mistakes Most Programmers Make Before I begin, there are three major mistakes that can slow down your progress to become a full-time Software Engineer. I will also share these three mistakes along the way, so stay tuned for that. Choosing the Right Programming Language As a new programmer, your first decision is, "Which programming language should I learn?" To help you answer that, let's discuss what beginners typically look for in a programming language. Number one, the language should be easy and intuitive to write. It should not require learning very complex syntax and should be as close as possible to writing in English. Next, the programming language should be versatile and have many applications. As a beginner, you don’t want to learn a new language for every new project you want to build. In other words, the language should have great returns for the time you invest in learning it. Lastly, the programming language should be fast to write. You shouldn’t have to waste time spelling out the declaration of a new variable or simple iteration through a list. In other words, it should be concise and get the job done in a minimum number of lines of code. As some of you might have already guessed, Python is the language that solves all these problems. It’s almost as easy as writing in English. It has so many different applications like web development, data science, and automation. Python is extremely fast to write when compared with other popular languages because it requires fewer lines of code for the same amount of functionality. As an example, here are the same codes written in Java vs. Python. You can see that Python consists of a few lines while JavaScript contains many lines and long code. JavaScript 1. const fs = require('fs'); 2. const path = require('path'); 3. 4. const directoryPath = path.join(__dirname, '.'); 5. const filePath = path.join(directoryPath, 'Code.txt'); 6. 7. fs.readFile(filePath, 'utf-8', (err, data) => { 8. if (err) { 9. console.error(err); 10. return; 11. } 12. 13. const lines = data.split('\n'); 14. let emptyLineCount = 0; 15. 16. lines.forEach(line => { 17. if (line.trim() === '') { 18. emptyLineCount++; 19. } 20. }); 21. 22. console.log('Number of empty lines:', emptyLineCount); 23. }); Python 1. my_file = open("/home/xiaoran/Desktop/test.txt") 2. 3. print(my_file.read()) 4. 5. my_file.close() Effective Learning Methods Now that we know we should learn Python, let’s talk about how to do it. And this is where most new programmers make the first major mistake that slows them down. The mistake most beginners make is that they learn by watching others code. Let me explain this by telling you how most people learn programming. Most newbies would go to a course provider like Udemy and look up Python courses. Then they pick one of these 20+ hour courses thinking that these courses are long and detailed and hence good for them. And then they never end up finishing the course. That’s because 20 hours of content is not the same as 20 hours of great content. Right Way To Learn Code Some people will go to YouTube and watch someone else code without ever writing any code themselves. Watching these tutorials gives them a false sense of progress. That’s because coding in your head is very different from actually writing down the code and debugging the errors. So, what is the right way to do it? The answer is very simple: you should learn by coding. For this, you can go to this free website called learnpython.org. On this website, just focus on the basic lessons for Python and don’t worry about data science tutorials or any advanced tutorials. That's because even if you learn advanced concepts right now, you will not be able to remember them until you have actually applied them to a real-world problem. You can always come back to learn the advanced concepts in the future when you need them for your projects. If you look at a lesson, each lesson first explains a basic concept and then asks you to apply those concepts to a problem. Feel free to play with the sample code. Think about other problems you can solve with the concepts you just learned and try to solve them in the exercise portion. Once you’re done with the basics, you’re good to move on to the next steps. Building Projects In the spirit of learning by coding, we would do some projects in Python next. In the beginning, it’s very hard to do something on your own, so we’ll take the help of experts. Watch the video below on 12 beginner Python projects. In this video, they build 12 beginner Python projects from scratch. These projects include building Madlibs, Tic Tac Toe, Minesweeper, etc., and all of them are very interesting. They walk you through the implementation of all these projects step by step, making it very easy to follow. But before you start watching this tutorial, there are two things you should know. Setting up Your IDE Number one, you should not watch this tutorial casually. Follow along if you really want to learn programming and become a Software Engineer. To follow along, you would need something called an Integrated Development Environment (IDE) to build these projects. An IDE, in simplest terms, is an application where you can write and run your code. There are several popular IDEs for Python. This tutorial uses VS Code IDE, so you might want to download VS Code and set it up for Python before starting on this tutorial. Once you have completed this tutorial, you are ready to work on your own projects. Developing Your Own Projects Working on building your own projects will help you in multiple ways. Number one, it will introduce you to how Software Engineers work in the real world. You will write code that will fail, and you’ll debug it and repeat the process over and over again. This is exactly what a day in the life of a Software Engineer looks like. Number two, you will build a portfolio of projects by doing this. You can host your code on GitHub and put the link in your resume. This will help you attract recruiters and get your resume shortlisted. Number three, building your own projects will give you confidence that you are ready to tackle new challenges as a Software Engineer. But what kind of projects should you work on? You can think of any projects that you find interesting, but here are some examples I found. You can build a web crawler, an alarm clock, an app that gives you Wikipedia articles of the day, or you can make online calculators. Some example projects are that you can also build a spam filter, an algorithmic trading engine, and an e-commerce website. Preparing for Job Applications Now you have a great resume, and you are confident about your programming skills. Let’s start applying for Software Engineer positions. Wait a second. This is actually the second major mistake new programmers make. You see, in an ideal world, having good programming skills and a great resume is all you should need to become a Software Engineer. But unfortunately for us, tech companies like to play games with us in the interviews. They ask you specific kinds of programming questions in the interviews. If you don’t prepare for these questions, you might not get the expected results. Essential Course: Data Structures and Algorithms So, let’s see how to prepare for interviews. All the interviews are based on this one course that is taught to all Computer Science graduates. This course is called Data Structures and Algorithms. Fortunately for us, Google has created this course and made it available for free on Udacity. And the best part is that this course is taught in Python. In this three-month course, you’ll learn about different algorithms related to searching and sorting. You’ll learn about data structures like maps, trees, and graphs. Don’t worry if you don’t know any of these terms right now. I am sure that by the end of this course, you’ll be a pro. For that, just keep two things in mind. Number One, be regular and finish this course. As I mentioned earlier, most people start courses and never finish them. So, make sure you take small steps every day and make regular progress. Number Two, make sure you complete all the exercises they give in this course. As I have already said many times, the only way to learn coding is by coding. So, try to implement the algorithms on your own and complete all the assignments. Trust me when I say this: when it comes to interviewing for entry-level jobs, this course is the only difference between you and someone who dropped more than a hundred thousand dollars on a computer science degree. So, if you finish this course, you’ll be pretty much on par with someone who has a CS degree when you interview. Interview Preparation After completing this course on Data Structures and Algorithms, you'll have all the foundational knowledge needed to tackle interviews. To further sharpen your skills, practice with questions previously asked by tech companies. For that, you should use a website called Leetcode.com. On Leetcode, you will get interview-style questions. You can write your code and test your solution directly on the website. Leetcode is great for beginners because all the questions are tagged as easy, medium, or hard based on difficulty level. If you buy a premium subscription to the website, you can also filter the questions by the tech company that asked them in past interviews. You should start with easy questions and keep working on them until you can solve them in 45 minutes. Once that happens, you can move on to medium questions. When you start solving mediums in 45 minutes, you can start applying for Software Engineering jobs. If you are lucky, you will get the job right away. For most people, it will be a process full of disappointment and rejection. Handling Rejections And this is where they make the third and the biggest mistake of all—they quit. The main reason people give up early is because they overthink and complicate the interview process. After every rejection, they replay the interview over and over in their head to figure out why they failed and take every rejection personally. To avoid this, stay inside your circle of control and try to influence the outcome of your interviews but never get tangled in the things you can’t control. In other words, do your best to crack the interviews but try to be detached from the outcome of the interviews.