preparation for technical/practical assessment both manual and automated testing for an SDET role at a dream company

Question

I'm having my last interview challenge next week for an SDET Role at a company that I pray every day to nail it. The recruitment steps I passed so far are:

• interview with HR manager
• theoretical questions with 2 QA leads

The last step is coming next week: I will be invited to a slack channel where I have to answer 3 questions (could be anything - the interview process is designed this way on purpose)

My question is:

• How to well prepare for this ?
• How to be impressive and have acceptable answers ?
• Any good materials (books/videos) that may help ?

Some of key points mentioned in the role description and the company main tech stack:

• RESTful API
• Cypress (I'm a selenium engineer with java) and have no experience with Cypress but I'm good with JS
• There might be manual testing: so how to write Test cases / test suites for a given functionality without having the requirements and specifications?

Answer 1

This is a nasty interview process.

Some things I'd suggest you consider:

• Be honest. You obviously want to work with this company, so make sure you can give them good reasons why they want to hire you. = Spend a little time over the weekend searching for Cypress getting started information, and maybe even install it and play with it a little. You being unfamiliar with Cypress isn't going to count against you (although it will count strongly for any other candidates who do have Cypress experience), but you taking the initiative to start learning about it will be a big plus for you.
• If you've done any automation involving REST APIs, review what you've done and what you found problematic. It will make any questions involving RESTful API automation easier if you're not trying to remember how to handle that particular API style.
• For writing test cases of functionality without requirements or specifications, I'd suggest you start by asking for a bit more context: for example, if asked to write test cases for a toaster, you might want to ask whether it's meant to be one of those big restaurant models where you drop the bread on the conveyor and it comes out a couple of minutes later, whether it's a domestic use toaster, whether it's supposed to take bagels as well (I loathe these questions. Ask me how I'd approach testing a web site with no documentation, no problems, but this kind of thing is something I find rather jarring). If you can get a basic context, you can come up with some basic happy path tests as a starting point, like, using the toaster example, does it blow up when you plug it in? (this would be a rather literal smoke test. If smoke comes out before you have a very dark piece of toast, you have a problem).

The biggest thing you have going for you is that the interviewers are likely to be more interested in how you approach the questions they give you than the exact correctness of your answers.