Tips to crack coding round interviews for SDET role


I’m sharing my first blog on ‘Cracking to coding rounds in SDET interviews’.

Let me know what you think below.


Frankly I don’t think the SDET should “worry” about the coding interview quite so much as some do. We should all be prepared for, but not worry, since most candidate failures in my experience are not around the coding skill, but around all the soft-skill aspects that Sahil points out.
Tech: Sometimes a company might want you to code in Java but you have little experience, make it clear that it’s not your home ground, but you would like to pair-program it instead. Or use a pseudo-code.
Solver: Not much you can do to prepare for this aspect, all you can do is not panic, because you either are a strong solver, or have other strengths that allow you to break down a complex problem and solve even just the most valuable half of it in the time given without time panic.
Logic: If companies give me a “homework” coding exercise all I do is unit-test my test fixtures as part of the exercise. This demonstrates that you can “test your own tests”, which demonstrates clear logic.
Team-fit: Is probably the biggest part here that you cannot prepare for, employment agents or coaches will try to tell you otherwise, but if you don’t fit the company or the role, you yourself will be unhappy. Being a good observer and good at following instructions and asking for help however is the big thing you can work on improving.
Well written bugs : How you work as a tester has to often be about writing as a skill, things you write down will probably be read by more people in the org than things coders write outside of the source. The more at home you are just writing clearly, the easier it is to get a message across succinctly. As a tester, you often have very little space or time to write up the bug ticket in a way that is actionable. If your writing is terrible or slow, even the juiciest bug will take multiple iterations to eliminate from the product. Communication is the biggest thing about this job that nobody told me on day 1.

By all means work out what coding language and toolstacks they want you to use long before you get to the interview, and spend time familiarizing yourself with a new language, or a new toolstack, but keep that up your sleeve for the end of session. No sense in putting yourself in a tough spot from the start, otherwise all you do is demonstrate your ability to underestimate.