Before joining Optimizely, Rasel worked at Vivasoft Ltd., where he contributed to AI-powered products. His most recent major project was Novara, an AI-driven recruitment platform. Outside of work, he writes technical articles on frontend security, JavaScript internals, and agentic AI.
Rasel applied for the role through a referral.
The hiring process consisted of four rounds: a recruiter screening, a combined behavioral and technical conversation, a take-home assignment, and a final demo and defense session. One theme ran through all four rounds: how he actually works with AI tools in his day-to-day engineering workflow.
The first call was a short conversation with the talent acquisition team. It began with an overview of the role and the company, followed by a brief introduction from Rasel.
What surprised him was where the discussion went next. Much of the call focused on how he used AI in his engineering work. The recruiter was looking for grounded, specific examples rather than general familiarity with AI tools.
To prepare, Rasel reviewed the job description closely and made sure he could describe his day-to-day workflow concretely. His advice is to treat AI fluency as part of modern engineering practice and be prepared to discuss it from the very first call.
The second round was a longer conversation that opened with the team’s mission and what the role looked like in practice before moving into Rasel’s background.
The discussion covered his career path, how he works within Agile teams, his approach to code review, and challenges he had faced on previous projects. Throughout the conversation, the interviewer repeatedly returned to how AI appeared across his software development lifecycle, how he evaluated its output, and how his usage of AI had evolved over time.
The conversation became particularly detailed when Rasel discussed Novara. Having shipped AI features to production rather than simply prototyping them gave him concrete experiences to draw from, particularly when discussing technical trade-offs and how to present AI-generated output to users without overpromising.
For preparation, Rasel recommends having two or three real situations ready where AI changed the way he approached a problem, along with the trade-offs involved. Although the questions may sound conversational, the answers need to be specific and grounded in actual experience.
The third round involved a frontend take-home assignment with defined business requirements and constraints. What made the round unusual was that AI tooling was not merely permitted; it was expected to play a central role in completing the assignment.
Rasel first scoped the problem, broke it down into milestones, and then used Claude for code generation, refactoring, and reasoning through architectural decisions. He also used Google Stitch for the design layer.
He found that treating AI as a thinking partner produced much better results than asking it to generate an entire feature in a single attempt. After completing the project, he deployed it and submitted it within the deadline.
His advice for this round is to treat a take-home assignment like production work: scope it, plan it, version it, and deploy it. Heavy AI usage does not mean offloading the thinking. The judgment involved in deciding what to accept, modify, or reject is an important part of the process and may itself be assessed.
The final round was a live walkthrough of the take-home assignment in front of a panel. Rasel presented the project in much the same way he would present a product to a customer.
The panel explored how he planned the solution, which architectural decisions he made and which alternatives he ruled out, the technical and design trade-offs he accepted, the rough edges he was aware of, and how AI factored into each stage of the development process.
Rather than trying to hide the project’s gaps or known issues, Rasel chose to acknowledge them directly. He believes this is a better approach because being transparent about a bug and explaining how it could be addressed demonstrates stronger judgment than attempting to conceal it.
To prepare for a similar round, he recommends being honest about the limitations of the solution and being ready to explain how those limitations could be addressed. He also suggests preparing substantive questions for the end of the interview, such as asking what the most challenging part of the role is.
Overall, Rasel’s interview experience highlighted that technical ability alone was not the only focus of the process. His ability to reason about engineering decisions, communicate trade-offs, work effectively with AI tools, and take ownership of the final outcome played an important role throughout the four rounds.
Special thanks to Rasel Hasan for taking out the time to share his recruitment experience with me. If you have any queries, feel free to contact him at raselhasan.cse11@gmail.com
]]>In her final year, Nusrat decided to pursue Software Quality Assurance (SQA) roles because she found that the responsibilities described in SQA job postings closely matched her skills and interests.
She is currently working at Therap (BD) Ltd. as an Associate Software Engineer, QA. She learned about the opportunity through the on-campus recruitment event held at SUST, where she submitted her CV.
The recruitment process consisted of four phases:
The written test covered a range of topics, including testing fundamentals, different types of testing, testing specific scenarios, basic SQL queries, two LeetCode problems, and simple Linux commands.
During the technical interviews, Nusrat was asked to introduce herself and answer questions about different types of software testing. She was also asked to describe test cases and testing scenarios for various objects and concepts, including safety pins and web forms.
The HR interview focused on her personal background, academic experience, motivation for pursuing the role, and reasons for being interested in Therap. She was also asked about ongoing events in Bangladesh and her opinions on various related topics.
Nusrat began preparing a few days before the written test. Her preparation focused on problem-solving, basic software testing concepts and theories, and revising the Software Development Life Cycle (SDLC) and Software Testing Life Cycle (STLC). She also reviewed SQL and Linux commands, practiced some mathematical puzzles, and developed an understanding of how to write and explain test cases and testing scenarios for both the written and technical interviews.
She did not take any specific preparation for the HR interview.
Special thanks to Kazi Nusrat Tasneem for taking out the time to share her recruitment experience with me. If you have any queries, feel free to contact her at kazinusrat236@gmail.com
]]>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
]]>