Hey Chris, good luck in your interview.
The standard set of tests I've seen given to Devs is:
- Given an array of strings, write a method that identifies which are palindromes
- Bonus points if you stop comparing at the half-way point
- Write a method that has two string arguments and will identify if the strings are anagrams of eachother
- Given a string, arrange the characters alphabetically, e.g. CAT = ACT.
They have their uses but I'm not a fan of those personally, they certainly won't be the deciding factor of making an offer. I'd rather discuss features of the language and frameworks the candidate, for example, garbage collection, generics, async and parallelism, etc. Enough to reveal weaknesses and strengths. They may do that too.
I prefer candidates that show an understanding of code-quality, the differences between unit-, integration- and system-testing. Knowledge of unit test frameworks, negative-testing, and of any tools that can be in-lined into an automated build process to check for regressions and overall quality are definite bonus-points.
I find most businesses are becoming much more security conscious (via their customers) and that filters into Engineering too. It is worth refreshing your memory of the
OWASP Top 10 vulnerabilities, and be able to give a one-line definition of the
STRIDE attack categories.
If I think of anything else, I'll post.