> That's why my interviews are aimed to check how does the individual think (instead of verifying her/his memorization skills). How does (s)he approach problems

> That's why my interviews are aimed to check how does the individual think (instead of verifying her/his memorization skills). How does (s)he approach problems, split them, classify them, explore possible solutions? When does (s)he abandon the path that doesn't look promising anymore? Is (s)he able to effectively share her/his thoughts (verbally, graphically, in code)? What about focus - does (s)he navigate in terms of a given goal or roam chaotically around? This sounds a lot like system design or leetcode-esque interview questions, which is the trend among tech companies in the US. > The problems candidates are facing at my interviews usually have NOTHING in common with the company's domain, BUT they have a super-low entry level (e.g. they are about common problems everyone encounters every day): building up the context takes seconds (literally), so the candidate can focus on tackling the problem, not understanding its basics. Are they system-design questions? This post could use some examples of interview questions the author has asked.