Alongside his interest in software testing, Nahid has a strong passion for competitive programming. He has solved more than 800 problems on platforms such as Codeforces, LeetCode, and GeeksforGeeks. He believes that this experience has strengthened his analytical thinking and problem-solving abilities—skills that help him approach software testing more effectively.
He enjoys learning new technologies, improving software quality, and continuously expanding his knowledge as a QA professional.
Nahid came across the job posting on LinkedIn and found that the position aligned well with his interests and career goals in Software Quality Assurance. He applied for the position through a referral from an employee of Nymph Solutions Ltd., who forwarded his application to the recruitment team.
The recruitment process consisted of three phases.
After submitting his application, Nahid was contacted by an HR representative who asked whether he would be available to attend an interview on short notice. Since he was available, he agreed, and his technical interview was scheduled for two days later.
The technical interview covered both theoretical knowledge and practical problem-solving skills.
The interview began with a discussion about Nahid’s background, including why he chose Software Quality Assurance despite having a strong interest in competitive programming and problem-solving. The interviewer then asked several questions related to software testing fundamentals.
The discussion gradually moved to API testing, where Nahid was asked scenario-based questions designed to evaluate his analytical thinking and approach to testing real-world applications. The interviewer later asked about his experience with automation testing and assigned him a small automation-related task to assess his practical skills.
To prepare for the interview, Nahid revised core Software Quality Assurance concepts, reviewed API testing with Postman, and refreshed his knowledge of automation testing fundamentals. He also revisited his previous projects and practiced explaining his approach to different testing scenarios.
Three days after the technical interview, Nahid had a discussion with the Project Manager. Since the team was looking for someone with strong analytical and problem-solving abilities, the conversation focused largely on how he approaches technical challenges.
During the meeting, the Project Manager explained the project in detail, discussed the team’s expectations, and asked several project-related questions to understand Nahid’s thought process and problem-solving approach.
A few days later, the HR team contacted Nahid to discuss the remaining formalities and informed him that he had been selected for the position. He was then invited to the office to receive his formal offer letter.
Following the completion of the formalities, Md Nahid Hossain officially joined Nymph Solution Ltd. as a Junior QA Engineer.
Special thanks to Md Nahid Hossain for taking out the time to share his recruitment experience with me. If you have any queries, feel free to contact him at nahidhossainmd99@gmail.com
]]>Before joining Optimizely, Akif worked on enterprise IoT device management, video streaming, and ride-sharing platforms. Throughout his career, he has gained hands-on experience with technologies such as Redis, MongoDB, Kafka, RabbitMQ, Kubernetes, Elasticsearch, and various AWS and GCP services. Outside of work, he enjoys studying computer science fundamentals, backend architecture, and competitive programming.
Akif applied for the Software Engineer II position at Optimizely through LinkedIn.
The hiring process consisted of five virtual interview rounds: two Data Structures & Algorithms interviews, two System Design interviews, and one Behavioral interview.
The first interview focused on problem-solving. Akif was given a palindrome-related problem and initially approached it with a brute-force solution. As the discussion progressed, he explored recursive decomposition and identified the overlapping subproblems that naturally led to a dynamic programming solution.
When asked whether the solution could be optimized further, he was unable to derive the most efficient approach. The interviewer then introduced Manacher’s Algorithm and explained how it achieves linear-time complexity for solving palindrome problems.
To prepare for this round, Akif reviewed common algorithmic patterns, including recursion, dynamic programming, trees, graphs, binary search, and greedy algorithms. Although he already had a competitive programming background, he spent additional time practicing coding problems in Java and improving his ability to communicate his thought process while solving problems.
The second round began with a fast exponentiation problem. Akif first discussed the straightforward solution before identifying important edge cases, such as handling large exponents and negative powers. He then optimized the solution using Binary Exponentiation.
Since he completed the problem relatively quickly, the interviewer introduced another challenge involving two knights on a chessboard and determining the minimum number of moves required for them to meet. Akif proposed a recursive solution, which the interviewer found satisfactory.
His preparation for this interview closely mirrored the first round, with an emphasis on solving coding problems, identifying edge cases, and clearly articulating his reasoning throughout the interview.
The third interview began with a discussion of Akif’s previous projects before transitioning into a system design exercise: designing a platform similar to Google Photos.
He started by gathering functional and non-functional requirements, followed by capacity estimation and high-level architecture design. His proposed solution included a Spring Boot backend, Amazon S3 for image storage, MongoDB for metadata management, Redis for caching, CDN integration, and database replication to improve scalability.
During the feedback discussion, the interviewer noted that while the high-level architecture was solid, they had expected more emphasis on low-level design, including service-layer interactions and data-access abstractions. The interviewer also expected security considerations, such as the use of presigned URLs for secure file uploads and downloads, to be explicitly addressed.
To prepare for this round, Akif studied scalability, caching strategies, database design, API design, distributed systems fundamentals, and common backend architecture patterns. He also practiced discussing architectural trade-offs using real-world systems and his own project experience.
Since the previous system design interview was not considered a definitive pass, an additional technical round was scheduled.
The interview began with an in-depth discussion of Akif’s previous projects. He was then asked to design and implement a bidding service for an eBay-style platform. After clarifying the requirements, he implemented the solution while applying object-oriented design principles and keeping maintainability in mind.
Throughout the session, the interviewer explored alternative approaches and architectural trade-offs, making the interview feel more like a collaborative engineering discussion than a traditional coding assessment.
For preparation, Akif reviewed object-oriented design principles, SOLID principles, and common backend design patterns. He also revisited his previous projects to prepare for discussions around technical decisions, implementation challenges, and architectural trade-offs.
The final interview focused on behavioral and communication skills. Topics included motivation, teamwork, conflict resolution, communication style, and collaboration.
A significant portion of the conversation also revolved around Akif’s previous projects, particularly the technical challenges he encountered, the lessons he learned, and how he worked with teammates and other stakeholders.
To prepare, he reflected on his professional experiences and reviewed examples of difficult situations, important technical decisions, and instances where he had to balance competing priorities or navigate disagreements.
A few days after the final interview, Akif was contacted by the HR team to discuss his availability and potential joining date while the hiring manager completed the final approval process. Shortly afterward, he received the official offer and joined Optimizely as a Software Engineer II.
Special thanks to Syed Akif Azwad for taking out the time to share his recruitment experience with me. If you have any queries, feel free to contact him at akifazwad6969@gmail.com
]]>This situation could have been easily avoided. If someone had taste-tested the food while you were cooking, you could have adjusted the seasoning before serving. And if you had asked your guests about their allergies beforehand, you could have chosen the right ingredients from the start.
Shift-left testing follows the same principle.
Instead of waiting until the final stages of development to test a feature and discover major issues, shift-left testing brings testing activities into the earliest stages of the software development lifecycle. In other words, testing is “shifted to the left” on the project timeline. By identifying problems early—just like tasting and adjusting a dish while cooking—teams can reduce rework, lower development costs, and deliver higher-quality software.
At Therap, we practice shift-left testing by encouraging close collaboration between developers and QA Engineers throughout the development process. Here are some of the ways we do it.
When a new feature is planned for the web application, the requirements usually originate from customers or stakeholders. Because Therap is a domain-heavy application, the developer responsible for the feature discusses the requirements with experienced QA Engineers before implementation starts. Together, they review the feature from multiple perspectives, including:
These discussions often uncover gaps, inconsistencies, or overlooked scenarios that might otherwise remain hidden until testing—or even after the feature has been released.
The same collaborative approach applies to bug fixes, especially critical ones.
Before implementing a fix, developers and experienced QA Engineers discuss questions such as:
These conversations help ensure that the solution addresses not only the reported bug but also related risks, significantly reducing the likelihood of introducing regressions.
Before implementing a REST API, developers first prepare an API design document describing the endpoints, request and response payloads, payload structures, parameters, and expected behavior.
An experienced QA Engineer then reviews the document to verify things such as:
Developers and QA Engineers continue refining the design through discussion until all concerns have been addressed. Only then does implementation begin.
This process helps identify design issues before a single line of production code is written, making them far less expensive to fix.
Practicing shift-left testing gives developers a much clearer understanding of a feature or bug fix from a quality and testing perspective. As a result, they are less likely to overlook important workflows, business rules, or edge cases during implementation.
Without these early discussions, problems often surface much later during formal testing. By then, developers may need to rework significant portions of their implementation, testers may need to expand the testing scope, and release schedules can be delayed.
Sometimes the issue is even more fundamental: the developer may have misunderstood the original requirement. Discovering such misunderstandings during testing wastes valuable development and QA effort because much of the completed work must be revisited.
By investing time in collaboration before implementation begins, teams spend far less time fixing avoidable problems later. Shift-left testing is not simply about testing earlier—it is about building a shared understanding of the problem, reducing uncertainty, and improving software quality throughout the development process.
Ultimately, shift-left testing is more than a testing strategy—it’s a mindset. It encourages developers and QA Engineers to collaborate from the very beginning, ask questions early, challenge assumptions, and think beyond the happy path. When quality becomes a shared responsibility rather than a final checkpoint, teams build better software with greater confidence and fewer surprises throughout the development lifecycle.
Just as great meals are perfected while they’re being cooked, great software is built by improving quality throughout development—not by waiting until the end.
]]>He has eight years of experience in backend engineering and has worked across multiple companies before joining Grab. In this interview, he shares his perspective on what it takes to build a successful career in software engineering.
Sahariar’s backend engineering journey began in 2018 in a research and development (R&D) environment. Unlike many entry-level positions, the expectations were exceptionally high from the very beginning.
He had to learn technologies such as Kubernetes and OpenShift almost immediately, an experience he describes as a “trial by fire.” Although challenging, it taught him one of the most valuable skills in software engineering: the ability to learn quickly.
Throughout his career, Java has been his primary programming language. However, he emphasizes that programming languages are simply tools.
“The tech stack is just a tool to solve the problem at hand.”
His progression into a senior engineering role happened naturally over time by taking ownership of products, participating in architectural decisions, and consistently delivering reliable systems.
According to Sahariar, responsibilities differ from company to company.
For him, the primary responsibility is acting as the owner of the product he works on. That means:
Ownership, rather than simply writing code, is what defines much of his work.
A normal workday starts by reviewing his Jira board and selecting the next task to work on.
During the day, his responsibilities include:
Once meetings are finished, most of the day is spent returning to development work.
Sahariar believes there are two misconceptions that many people have.
He doesn’t believe this will happen.
Instead, he sees AI as an extremely powerful productivity tool rather than a replacement for engineers.
Many beginners spend too much time debating which programming language pays more or is “better.”
As engineers become more experienced, they realize that programming languages are simply tools.
Understanding problems and designing good solutions matter far more.
If someone were starting software engineering today, Sahariar recommends focusing on the fundamentals:
In fact, if he had to start over himself, he says he would study Operating Systems from beginning to end before anything else.
For fresh graduates and beginners, Sahariar believes one skill stands above the rest:
Problem-solving.
Strong problem-solving abilities make learning new technologies significantly easier throughout a software engineering career.
Technical skills alone are not enough.
His advice is simple:
Try to learn from others.
Being open to feedback and continuously learning from experienced engineers can accelerate career growth.
Hiring expectations vary depending on the company.
These companies generally evaluate:
Their focus is on strong computer science fundamentals.
These organizations often prioritize candidates who can contribute immediately.
While this may sound appealing, Sahariar considers it a potential red flag because such environments often leave little room for mentorship and learning.
Fortunately, he doesn’t believe expensive courses are necessary.
He recommends:
According to him, these resources provide everything needed to build a solid foundation.
His opinion is straightforward.
Projects provide far more value than certifications.
He also believes expensive certifications are often overrated and rarely provide the same career impact as building real software.
Instead of randomly creating projects, Sahariar suggests a more strategic approach.
This demonstrates practical engineering skills that employers appreciate.
One of his strongest recommendations is contributing to open-source software.
Beyond writing code, beginners should:
This provides exposure to professional software development practices that personal projects often cannot.
For entry-level software engineering interviews, he frequently sees questions covering:
These subjects remain important across many companies.
Sahariar considers them extremely valuable.
Strong GitHub projects and meaningful open-source contributions can significantly strengthen a candidate’s profile.
In many cases, they can outweigh undergraduate academic results during hiring.
AI is currently the biggest trend shaping the industry.
Interestingly, Sahariar doesn’t believe this means engineers will disappear.
Instead, he believes engineers will spend:
As AI handles repetitive coding tasks, problem-solving ability becomes even more valuable.
When asked to leave one final message for aspiring engineers, Sahariar shared four simple pieces of advice:
And for standing out in today’s competitive job market?
His answer was equally simple:
Build projects and contribute to open-source software.
One of the recurring themes throughout this interview is that fundamentals matter more than fashionable technologies.
Programming languages change. Frameworks evolve. AI tools become more capable.
However, a strong understanding of computer science fundamentals, the ability to solve problems, and a willingness to learn continuously remain timeless qualities that distinguish successful software engineers.
If you’re just beginning your software engineering journey, this interview offers an important reminder: focus less on chasing trends and more on building a solid foundation that will support your career for years to come.
This article is part of the Career Insights series on Tahanima’s Blog, where professionals share their career journeys, responsibilities, learning paths, and advice for aspiring engineers.
Special thanks to Sahariar Alam Khandoker for sharing his experience and insights with the community. If you have any queries, feel free to contact him at rifatsahariar@gmail.com
Before I share those hobbies, I want to emphasize why I believe having interests outside your profession is important. Office work can be mentally exhausting, especially for roles like software quality assurance that require continuous concentration, critical thinking, and attention to detail. Having hobbies gives your mind an opportunity to disconnect from work-related stress, reduces screen time, and helps you recharge both mentally and physically.
Over the years, I’ve found that these hobbies have improved my energy, creativity, patience, and overall well-being. Those improvements have naturally carried over into my professional life as well.
About six months ago, I was experiencing very low energy during office hours. I found it difficult to concentrate on my work and stay motivated throughout the day.
To improve my health, I started brisk walking with one of my colleagues. Since we usually return home in the same office microbus, instead of going straight home, we spend around 40 minutes brisk walking in a nearby park before heading to our respective homes.
I also bought a pair of 2 kg dumbbells and started following Chloe Ting’s dumbbell workout videos on YouTube.
These two habits significantly improved my energy levels throughout the day and helped me manage stress, anxiety, and depression. What surprised me most was how quickly I noticed the benefits.
Being physically active has also made me more focused during office hours. Instead of feeling mentally exhausted by the afternoon, I now find it easier to stay attentive during meetings, think through complex problems, and remain productive throughout the day.
About two years ago, I came across some crochet plushies on a Facebook page and immediately wanted to buy one. I asked my husband which one he thought I should purchase.
Instead of helping me choose one, he simply said, “You don’t need to buy it—you can make it yourself.”
At that time, I didn’t know the first thing about crochet, but that comment stayed with me. I started watching beginner tutorials on YouTube, bought the necessary materials, and began my crochet journey.
Crochet is a completely handmade craft that cannot truly be automated by machines. My favorite type of crochet is making amigurumi plushies. Although each project takes many hours to complete, I find the process incredibly relaxing and rewarding.
I’ve gifted many of my crochet creations to friends, family members, and colleagues. Their reactions have been overwhelmingly positive, and many have encouraged me to start a small crochet business.
Crochet has also taught me patience. Every stitch contributes to the final product, and rushing usually leads to mistakes that need to be corrected later. That mindset translates surprisingly well to software testing, where careful attention to detail often makes the difference between finding a bug and missing it.
After enjoying crochet, I became interested in exploring other creative hobbies.
Since I already followed many craft-related Facebook pages, I was constantly discovering new materials and techniques. That’s how I found resin and gypsum art.
I purchased several molds—mostly for vases and organizers—and started making decorative pieces for my home and office desk. I enjoyed the hobby so much that I introduced it to my sister, who now enjoys it as well.
Resin and gypsum projects allow me to experiment with colors, designs, and different combinations of materials. It gives me an opportunity to be creative without worrying about perfection, which is a refreshing change from the structured nature of software testing.
My sister introduced me to anime back in 2012, and I’ve been watching it ever since.
Anime helps me unwind after a busy day. Some series make me laugh, some make me emotional, and others leave me feeling inspired.
Some of my favorites include:
Sometimes, simply taking a break from work and immersing myself in a good story helps me return with a fresh perspective. I’ve often noticed that solutions to problems become much clearer after allowing my mind to rest.
Creative journaling is another hobby I discovered while exploring different craft communities.
The concept is simple—you decorate journal pages using stickers, washi tape, stamps, and various embellishments. There are no strict rules, which makes it a very relaxing activity.
One of the things I enjoy most about creative journaling is the immediate sense of satisfaction it brings. It allows me to express creativity in a completely different way from my technical work.
As a QA Engineer, I’m constantly working with requirements, documentation, and structured processes. Creative journaling gives me an outlet where there are no right or wrong answers, which helps me maintain a healthy balance between analytical thinking and creativity.
I recently bought a printer and have been experimenting with different DIY paper crafts.
One of my first projects was designing and printing Eid greeting cards, which I distributed among my colleagues. It was a wonderful experience.
I’ve also made personalized notebooks for myself and printed my own stickers. I’m still exploring what else I can create using my printer, and that’s part of the fun.
I particularly enjoy designing personalized items because they allow me to combine creativity with problem-solving—something that’s also central to software quality assurance.
Not every hobby becomes a long-term passion, and that’s perfectly okay. Exploring new interests is part of the fun.
I tried making decorative lily flowers using pipe cleaners and used them to decorate my resin and gypsum vases. Although the results looked nice, I didn’t continue with the hobby.
I bought coloring books and supplies because I wanted to give coloring a try. However, I didn’t enjoy it as much as I expected, so I eventually stopped.
I built two cartoon characters using LEGO bricks. While the finished models looked great, I personally found the building process too tedious to continue.
Trying these hobbies also taught me that it’s okay to discover something isn’t for you. Every new hobby doesn’t have to become a lifelong commitment.
There are still many creative hobbies on my wishlist. Some that I’d like to try in the near future are:
I’m looking forward to learning these crafts for the same reason I started the others: the joy of creating something with my own hands.
Many people think becoming a better QA Engineer only means learning new testing tools, programming languages, or automation frameworks. While those skills are certainly important, I’ve learned that taking care of yourself outside of work is just as valuable.
These hobbies have helped me become more energetic, patient, focused, and creative. They’ve taught me to slow down when necessary, enjoy the process of learning, and maintain a healthier work-life balance. I genuinely believe they’ve made me not only a happier person but also a better software tester.
]]>Before diving into the details, I want to emphasize the importance of having a well-defined workflow. A strong workflow not only improves team efficiency and productivity but also has a direct impact on the quality of the final outcome. Additionally, a streamlined process enables new team members to onboard more quickly, adapt to the team’s practices, and contribute effectively from an early stage.
I designed the test automation framework currently used by our team. The framework is built using Java, Playwright, REST Assured, and Allure Report. This technology stack was selected based on my previous experience, along with discussions and feedback from two senior QA engineers on the team. As a result, I am primarily responsible for introducing framework enhancements, architectural improvements, and technical upgrades whenever necessary.
When we began our automation journey, the two senior QA engineers and I agreed that regression testing should be our primary focus. We first identified the features that would benefit most from automation and created a roadmap of regression test scenarios to cover. Afterward, automation tasks were distributed among team members through collaborative discussions.
Not every regression scenario can be fully automated. In such cases, we maintain clear documentation indicating which test cases are covered by automation and which still require manual testing. Our approach is incremental. If a feature or a portion of a feature cannot be automated immediately, we revisit it later and conduct additional research and experimentation to determine whether automation has become feasible.
Once a QA engineer is assigned an automation task, their first responsibility is to develop a high-level implementation plan and discuss it with either me or one of the senior QA engineers. During this discussion, we review the scope of automation coverage, identify any limitations, evaluate missed test scenarios, and discuss implementation strategies and design considerations. This collaborative planning stage helps ensure alignment before development begins.
After the implementation is completed, the engineer announces in our dedicated Google Workspace channel that the work is ready for review. At this stage, we conduct a test case review rather than a code review. A reviewer is assigned to evaluate the automated test coverage, validate the selected scenarios, and provide feedback on any missing or incorrect test cases. The assignee then addresses the feedback and updates the implementation accordingly.
Only after all test case review feedback has been resolved does the assignee notify the team that the pull request is ready for code review. We typically invite all team members involved in automation to participate in the review process. Since our automation team currently consists of six members, this approach remains manageable and encourages knowledge sharing across the team.
During code review, reviewers focus on code quality, framework standards, maintainability, and implementation best practices. Any feedback received is addressed by the assignee until all concerns are resolved. Once all reviewers approve the pull request, the changes are merged into the develop branch.
This workflow has helped us maintain high-quality automation code, encourage collaboration, and ensure that both test coverage and code quality are thoroughly reviewed before any changes become part of the framework.
]]>Mushfiqur is currently working at Optimizely as a Senior Software Engineer. He secured the opportunity through an employee referral. The interview process consisted of three phases.
To prepare for the problem-solving round, Mushfiqur focused on strengthening his understanding of common problem-solving patterns, particularly ad hoc and greedy algorithms. He practiced regularly on online coding platforms, beginning with easier problems and gradually progressing to medium-level challenges to build consistency, confidence, and speed.
For greedy problems, he concentrated on identifying scenarios where locally optimal decisions lead to globally optimal solutions. For ad hoc problems, he worked on improving his ability to analyze constraints carefully and derive solutions without relying on predefined templates.
In addition to solving problems, he reviewed editorial solutions to learn alternative approaches and refine his thought process. His preparation strategy centered on consistent practice, pattern recognition, and improving problem-solving clarity.
The second phase was primarily a behavioral and experience-focused discussion. To prepare, Mushfiqur reviewed his experiences working within software development teams and reflected on various aspects of the software engineering process.
He focused on topics such as team collaboration, effective code review practices, task estimation through technical analysis, sprint planning, and Agile methodologies. He also refreshed his understanding of how Jira tickets are created, managed, and tracked throughout the software development lifecycle.
This preparation enabled him to confidently discuss both the technical and collaborative aspects of software engineering and demonstrate his experience working in professional development environments.
For the system design round, Mushfiqur concentrated on core backend engineering principles and practical system design concepts commonly encountered in real-world applications.
His preparation included revisiting SOLID principles, clean code practices, design patterns such as Singleton, dependency injection lifetimes, and thread-safety considerations. He also reviewed how production-grade systems are architected, including caching strategies, concurrency management, and the behavior of different service lifetimes within dependency injection containers.
Additionally, he refreshed his knowledge of CI/CD pipelines and deployment processes, covering both self-hosted and cloud-hosted environments. To further strengthen his understanding, he studied security fundamentals, including OWASP guidelines, and explored architectural trade-offs related to scalability, performance, and maintainability.
Rather than focusing solely on theoretical concepts, his preparation emphasized understanding how these principles are applied in real production systems, which proved valuable during the interview process.
Special thanks to S.M. Mushfiqur Rahman for taking out the time to share his recruitment experience with me. If you have any queries, feel free to contact him at mushfiqur940@gmail.com
]]>Nusrat applied for the role at Ding through LinkedIn.
The recruitment process consisted of four stages spread across several weeks, with approximately one week between each stage.
The first round focused on understanding Nusrat’s background, experience, and career motivations. The interviewers asked about her educational journey, professional experience, reasons for pursuing Software Quality Assurance as a career, motivations for seeking a new opportunity, and notable professional achievements.
To prepare for this stage, she reviewed her career progression, key projects, strengths, accomplishments, and long-term career goals. This preparation helped her confidently present her background and professional experiences.
The second round was primarily technical and focused heavily on software testing practices. A significant portion of the discussion centered on application testing, including her approach to testing web and mobile applications, designing test scenarios, identifying edge cases, reporting defects, and ensuring overall product quality.
The interviewers also explored her knowledge of manual and automation testing, API testing, log analysis, testing tools used in previous roles, and her experience working with AI-based products. Since Nusrat had prior experience testing AI-driven applications, the conversation delved deeper into that area.
To prepare, she revised software testing fundamentals, application testing methodologies, API testing concepts, automation basics, and the projects and tools she had worked with throughout her career.
The final interview combined technical discussions with behavioral assessment. Topics included QA best practices, establishing and improving quality processes within teams, stakeholder communication, problem-solving approaches, and long-term career aspirations.
The interviewers also asked technical questions related to testing strategies and previous work experiences. To prepare, Nusrat reflected on real-world workplace situations, collaboration with cross-functional teams, challenges she had encountered, and the ways she had contributed to improving product quality and delivery processes.
After successfully completing the interview stages, Nusrat received a call from the HR team to discuss the offer. The conversation covered compensation, benefits, company facilities, and other employment-related details.
To prepare for the different stages of the recruitment process, Nusrat combined her professional experience with focused study and research. She reviewed software testing fundamentals, application testing methodologies, API testing concepts, automation fundamentals, and QA best practices. She also revisited previous projects to ensure she could confidently discuss practical examples and real-world challenges during the interviews.
In addition, she leveraged AI-powered tools as part of her preparation. These tools helped her practice interview questions, review technical concepts, identify knowledge gaps, and improve how she communicated her experiences and achievements. By combining hands-on industry experience, self-study, and AI-assisted learning, she felt well-prepared for both the technical and non-technical stages of the recruitment process.
Special thanks to Nusrat Jahan for taking out the time to share her recruitment experience with me. If you have any queries, feel free to contact her at nusratjahanmily99@gmail.com
]]>To answer these questions, I spoke with Nirjas Mohammad Jakilim, a DevOps Administrator II at Therap (BD) Ltd. with five years of industry experience. He shared his career journey, his perspective on the role, and practical advice for anyone interested in building a career in DevOps.
Nirjas’s path into DevOps wasn’t a direct one. He began his career working extensively with application servers and deployments, particularly managing WebLogic environments.
His responsibilities included deploying Java applications, tuning performance, troubleshooting production issues, and maintaining standalone servers. While doing this work, he noticed how much time was spent on repetitive manual tasks and began looking for ways to automate them.
That curiosity led him to develop scripts for WebLogic setup and application configuration, create Ansible playbooks for JDK and WebLogic patching, and automate deployment processes using Jenkins. Along the way, he also identified architectural limitations and worked on solutions to improve operational efficiency.
The goal was always the same: reduce manual effort, eliminate human error, standardize processes, and make deployments more reliable.
As his experience grew, so did his interests. He gradually moved into the observability space, researching and implementing logging and monitoring solutions such as LogScale, Vector, ELK, Grafana, Prometheus, and Datadog. This work involved building dashboards, configuring alerts, creating custom metrics, developing log parsers, and integrating authentication systems.
More recently, his focus has expanded to containerization and CI/CD initiatives. He has been involved in helping applications move from traditional standalone deployments to containerized environments, automating image builds and deployments, and exploring open-source solutions to simplify deployment management.
Reflecting on his journey, Nirjas emphasizes that most of his learning came from solving real operational challenges rather than following a predefined roadmap.
According to Nirjas, the primary responsibility of a DevOps professional is rooted in the core philosophy of DevOps itself: reducing the gap between development and operations teams. The goal is to ensure that applications can move smoothly from a developer’s machine to production in a way that is efficient, reliable, and repeatable.
Achieving this involves:
Beyond deployments, DevOps professionals are responsible for improving system reliability, performance, security, and overall operational efficiency.
Whether through CI/CD pipelines, infrastructure automation, monitoring platforms, or containerization technologies, the ultimate objective remains the same: delivering software faster, more reliably, and with fewer manual interventions.
One of the things that attracted Nirjas to the field is the variety of work involved.
His day often begins with routine operational checks to ensure that applications, servers, monitoring systems, and deployment pipelines are functioning correctly.
After that, the focus shifts to whatever the team’s priorities demand. This could include:
Collaboration is also a significant part of the role. DevOps professionals frequently work with developers, operations teams, and other stakeholders to resolve issues, discuss deployment requirements, and ensure smooth software delivery.
As Nirjas puts it, DevOps is a blend of operations, automation, troubleshooting, and teamwork—and no two days are exactly alike.
Despite its popularity, DevOps remains one of the most misunderstood areas of software engineering.
Many people assume DevOps is simply a collection of technologies such as Docker, Kubernetes, Jenkins, or cloud platforms.
Nirjas disagrees.
The tools are important, but they are only a means to an end. The real goal is improving collaboration, automation, reliability, and software delivery processes.
Automation is certainly a major part of the job, but much of the work involves understanding applications, troubleshooting complex issues, improving observability, and designing infrastructure solutions.
In reality, DevOps sits at the intersection of development and operations.
Professionals in this field need to understand how applications are built, configured, deployed, and monitored, while also being comfortable managing the underlying infrastructure.
No system is perfect.
The purpose of DevOps is not to eliminate problems entirely but to reduce risk, improve visibility, automate repetitive work, and make systems easier to recover when failures occur.
If someone were starting from scratch today, Nirjas recommends focusing on fundamentals before diving into popular tools. His suggested learning path looks like this:
Start with:
Without understanding how systems work, it becomes difficult to automate or troubleshoot them effectively.
Next, focus on:
These skills form the foundation of automation.
Learn how applications are deployed and managed by studying:
Once the basics are comfortable, explore:
These technologies are widely used in modern deployment environments.
Finally, build knowledge in:
Throughout the process, he strongly recommends building projects and maintaining personal lab environments.
Nirjas recommends a practical, hands-on approach to learning. Some of his preferred resources include:
He particularly highlights NotebookLM as a useful way to interact with documentation and learning materials more efficiently.
When discussing certifications, Nirjas takes a balanced but experience-first approach. While certifications can be valuable, he believes they should never replace practical knowledge.
Certifications that can provide value include:
However, he cautions against collecting certifications without developing real-world skills. Employers are often far more interested in what you have built, automated, deployed, and troubleshot than the badges displayed on a résumé.
For aspiring DevOps professionals, practical projects are one of the best ways to demonstrate capability.
Nirjas recommends building:
For those without professional experience, maintaining a home lab, managing self-hosted applications, contributing to open source, and practicing incident troubleshooting can provide valuable hands-on exposure.
As the industry evolves, several trends are becoming increasingly important.
Areas gaining momentum include:
At the same time, skills such as manual server provisioning, manual deployments, and heavy reliance on GUI-based administration are becoming less relevant as organizations continue to embrace automation.
When asked for one piece of advice he would give to anyone entering the field, Nirjas’s answer was simple:
“Focus on fundamentals before tools. Learn how systems work, not just how tools work. Build things, break things, fix things, and document what you learn.”
Technology will continue to evolve. New tools will appear, and old ones will disappear. However, a strong understanding of Linux, networking, automation, and troubleshooting will remain valuable throughout your career.
For anyone considering a path into DevOps, that may be the most important lesson of all.
This article is part of the Career Insights series on Tahanima’s Blog, where professionals share their career journeys, responsibilities, learning paths, and advice for aspiring engineers.
Special thanks to Nirjas Mohammad Jakilim for sharing his experience and insights with the community. If you have any queries, feel free to contact him at nirzashzakilim@gmail.com
]]>She has more than 4.5 years of experience in Business Analysis and has previously worked at TechnoNext Software Limited and Southtech Limited in various Business Analyst roles. Starting her career as an Intern and Junior Business Analyst, she gradually progressed into a full-fledged Business Analyst position.
Her professional experience includes:
Throughout her career, she has worked closely with development, QA, UI/UX, and business teams to ensure smooth project execution and proper alignment of requirements.
Academically, Anika completed her MBA from East West University and earned her B.Sc. in Information and Communication Engineering (ICE) from Bangladesh University of Professionals.
In addition to her technical and analytical expertise, she places strong emphasis on communication, problem-solving, and continuous learning. She enjoys identifying process improvement opportunities and developing solutions that enhance efficiency for both users and businesses.
Anika applied for the Business Analyst position at Brain Station 23 through LinkedIn after coming across the job posting on the platform. Following a review of her profile and CV, the HR team contacted her and informed her that she had been shortlisted for the recruitment process.
The recruitment process consisted of several phases.
After applying, Anika received a call from HR informing her that her CV had been shortlisted. An initial online interview was then scheduled, which lasted approximately 30 minutes.
During this interview, she was asked questions such as:
To prepare for this stage, she focused on reviewing fundamental Business Analysis concepts, methodologies, and terminologies. Since it was an initial screening interview, she concentrated on strengthening her understanding of the basics.
The next stage involved an on-site assessment at the company’s office, which lasted approximately three hours.
As part of the assessment, a business scenario was provided, and she was required to:
The written analysis and presentation were closely related, with most of the presentation content derived from the written assessment.
For preparation, Anika reviewed the job description and practiced different types of Business Analyst assessments using AI tools. Since she did not know the exact format of the assessment beforehand, she used AI-generated scenarios and exercises to strengthen her analytical and presentation skills. This preparation significantly boosted both her confidence and readiness.
The assessment submission and team interview took place on the same day. After submitting her assessment, she attended the team interview.
During this phase, she was asked to:
Her preparation using AI-generated assessment scenarios proved valuable during this stage. She also practiced mock interviews using AI tools, which exposed her to various scenario-based questions and helped improve both her communication and analytical abilities.
The next stage was a one-on-one interview with the BA Lead.
Topics discussed during the interview included:
To prepare, Anika revised Business Analysis concepts, methodologies, and terminology while also revisiting the materials she had studied for the earlier interview stages.
The BA Lead interview and HR interview were conducted on the same day.
During the HR interview, discussions focused on:
For this stage, she prepared her expectations in advance, enabling her to discuss compensation and career aspirations confidently and clearly.
The final interview stage involved a meeting with the client, attended by both the client and members of the project team.
This interview focused heavily on:
The team also asked several questions regarding how she would handle client-facing responsibilities and real-world project challenges.
Before the interview, the team had provided her with some background information about the client. Based on this information, she continued practicing with AI tools. However, she found that her real-world work experience and practical communication skills played a much greater role in this stage, as the interview primarily assessed how she approached problems, communicated ideas, and made decisions in realistic business situations.
Following the client interview, there was a brief salary negotiation discussion with HR over a phone call. Shortly afterward, Anika received the offer letter and successfully joined Brain Station 23 as a Business Analyst.
Special thanks to Anika Tabassum for taking out the time to share her recruitment experience with me. If you have any queries, feel free to contact her at anikatabassum0204@gmail.com
]]>