This article is based on my recent 100+ real live interview experiences with my SDET learners with many product organisations in India.
Suppose you are looking to become a high paid SDET. In that case, I recommend you to start solving 100–150 easy/medium DSA problems in Leetcode with a brute force approach and optimise using other algorithms.
Most interviewers watch out for your approach to solving problems, not the solution itself. The below 10 Steps can guide you to crack your QA coding round.
During the interview, most of us become nervous during on coding round and do not read the question thoroughly, especially in case of word problems. By chance, if you did not understand the question (that happened a few times for our learners during the mocks/real with difficult question), ask the interviewer to detail the question with example(s).Here are a few follow-up questions either to ask yourself or to the interviewer:
- What is/are the input(s) given to the problem?
- What is the expected output data type?
- Do I have constraints to solve this problem?
- How big the test data set could be?
Pro Tip: It is essential to ask the right questions like what-if cases and edge cases early to the interviewer, and it will help design your tests well.
Step 2: Build your test data set
It is time to show up your QA testing skills. Recommend to build a minimum of 3 test data sets, including — Positive, Edge, Negative, and edge data set, is the most preferred ask by most interviewers. Convert the test data into unit tests and can be used for test-driven development (TDD).
Pro Tip: Once you scribe them, validate with the interviewer if the test data set covers the expectations are not!
Step 3: Take a moment to think through solutions
Considering you have solved many LC problems, you mostly would get a (similar) situation that you may have cracked. But, do not show up quickly to interviewers else. You would get another question (it happened twice in 100+ interviews in the last few months). So, take a few moments to think through the problem-solution / workaround with the given data & constraints.
Pro Tip: It is important to constantly communicate to the interviewer (especially when you are taking an online interview), even when thinking about the solution(s)!
Step 4: Ask for hints
What if you cannot think of any solution? I recommended all my learners ask the interviewers shamelessly for hints/help. It worked most of the time, as many interviewers were willing to help you.
Pro Tip: When you get a hint from the interviewer, it is essential to thank them for the help. It helps to show your attitude.
Step 5: Always start with brute-force
Though you know multiple and optimised solutions, it is always recommended to start with the brute-force approach unless the interviewer defines the problem constraint. If there is a time challenge, mention the brute-force approach and its O-Notations.
Pro Tip: It is essential to communicate the time and space complexity for every solution, especially from the testing side.
Step 6: Write Psuedo Code first
Most of the live coding rounds are about 45 to 60 minutes long. Generally, you get about 1–2 coding questions and may be other questions including front/back end automation and a few other questions like agile and test data enumerations. With that said, each programming question may be about 15–20 minutes on average.
Sometimes, you may get lost when complex coding problems. It is always a good idea to scribe the psuedo code first and get confirmation from the interview before you code.
Pro Tip: Validate the psuedo code with the interviewer, and many times, they will be happy to advise a few corrections before you code.
Step 7: Write your clean code
Apply clean coding practices when you code your solution. It begins with your method/variable naming conventions and meaningful short comments to use appropriate (built-in) methods for the solution. It is good to confirm with the interviewer when you are about to use the built-in methods as many of them say ‘NO’ to them.
Pro Tip: Always practice your coding with a text editor. And many interviewers may use code sharing platforms, and they may not have auto-complete options.
Step 8: Debug your code with test data
As a test engineer, you may wish to run the test and not be keen on debugging. That may be the greatest mistake. Hence, recommended starting with debugging every line of code, step into/over and walk through the interviewer. Remember to communicate O Notations for every solution that you built.
Pro Tip: Ask the interviewer if they like to run for specific test data. Often, your coded solution can be new to the interviewer, and they may be interested in knowing if their test data works against your code.
Step 9: Run for all test data
If all the above steps went well, take a deep breath and run your code against all test data you built in step 2. If one or more fails, start debugging with the consent of the interviewer.
Pro Tip: Make sure unit tests have proper assertions against the expected and actual. That would help you to test faster.
Step 10: Ask for feedback.
Hurray, you are on the final step. It’s time for you to ask for feedback from the coding test and note them on your sticky notes. If improvements are mentioned during the interview, say that you will begin working on them swiftly today.
Final Thoughts
Thank you for reading this article, and I will be honoured by your claps and shares. At TestLeaf, we assisted 10000+ manual testers in transforming their career towards test automation engineering with the help of automation testing courses (Grow Vertically), development (Shift-Left) and DevOps (Shift Right).
