Step by Step Approach to Solve Any Programming Questions in your QA Interview.
This article is written based on my recent 100+ real live interview experiences of my SDET learners with many product organisations in India.
Skill up before you apply
If you are looking to become a high paid SDET, I personally recommend you to start solving 100–150 easy/medium DSA problems in Leetcode with brute force approach and optimise using other algorithms.
Most of the interviewers, watch out for your approach towards solving problems and not the solution itself. The below 10 Steps can guide you to crack your QA coding round.
Step 1: Understand the Problem
Most of us during interview become nervous upon on coding round and do not read the question fully specially incase of word problems. By chance, if you did not understand the question (that happened few times for our learners during the mocks/real with difficult question), ask the interviewer to detail the question with example(s).
Here are 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 important to ask right questions like what-if cases and edge cases early to the interviewer and it will defintely help to design your tests well.
Step 2: Build your test data set
It is time to show up your QA testing skills. Recommend to build the minimum of 3 test data set including — Positive, Edge, Negative and edge data set is the most preferred ask by most of the interviewers. Convert the test data into unit tests and can be used for test driven development (TDD) approach.
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
Considered you have solved many LC problems, you mostly would get a (similar) problem that you may have solved. But, ….. do not show up quickly to interviewers else you would get another question (it happened twice in 100+ interviews in last few months). So, take a few moment to think through the problem solution / work around with the given data & constraints.
Pro Tip: It is important to constantly communicate to the interviewer (specially when you are taking online interview), even when you are thinking about the solution(s)!
Step 4: Ask for hints
What if, you cannot think through any solution? I recommended all my learners to ask shamelessly to the interviewers for hints/help. It worked most of the time, as many interviewers were willing to help you.
Pro Tip: When you get hint from the interviewer, it is important to thank him/her for the help. It definitely helps to show your attitude.
Step 5: Always start with brute-force
Though you know multiple and optimised solutions, it is always recommend to start with the brute-force approach unless the interviewer defined the problem constraint. If there is time challenge, then mention about brute-force approach and its O-Notations.
Pro Tip: It is super important to communicate the time and space complexity for every solution that you are coming up specially from testing side.
Step 6: Write Psuedo Code first
Most of the live coding rounds are about 45 to 60 minutes long and generally you get about 1–2 coding questions and may be other questions including — front/back end automations and few other questions like agile, test data enumerations too. With that said, each programming question may be about 15–20 minutes average.
Sometimes, you may get lost when coding difficult problems. It is always a good idea to scribe the psuedo code first and get confirmation from the interview before you really code.
Pro Tip: Validate the psuedo code with the interviewer and many times, they will happy to advise few corrections before you code.
Step 7: Write your clean code
Apply clean coding practices when you code your solution and it begins from your method/variable naming conventions, meaningful short comments to using appropriate (built-in) methods towards solution.It is a good idea to confirm with 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 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
Being test engineer, you may wish to run the test and not keen on debugging. That may be the greatest mistake. Hence, recommended to start with debugging every line of code with step into/over and walk through the interviewer. Remember to communicate O Notations for every solution that you built.
Pro Tip: Ask interviewer, if they like to run for specific test data. Many times, your coded solution can be new for interviewer and she/he may be interested to know if their test data works against your code.
Step 9: Run for all test data
If all above steps went well, take a deep breathe and run your code against all test data that 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 make sure to note them on your sticky notes and if there are improvements mentioned during interview, mention that you will begin working on them swiftly today.
Thank you for taking time to read this article and will be honoured by your claps and shares. At TestLeaf, we assisted 10000+ manual testers to transform their career towards test automation engineering (Grow Vertically), development (Shift Left) and to devops (Shift Right).
