> While there are some shortcuts they largely rely on having seen a problem before. I'm arguing that this is largely not true. These problems are grounded in b

> While there are some shortcuts they largely rely on having seen a problem before. I'm arguing that this is largely not true. These problems are grounded in basic CS[0] problems - implementing stacks, linked lists, standard sorts, or understanding how to solve a basic problem in a certain O time. They are not "interview problems" that recruiters invent and pass around to one anther, they are real problems with historical backgrounds and well-discussed solutions. I'm not saying your group shouldn't exist, I'm saying I disagree with your stated method: > expose yourself to enough problems and solutions Instead, expose yourself to computer science. Few interview questions (for entry-midlevel coding jobs) are novel, almost all of them (that I've seen) are just exemplifications of well-known CS problems[1] that you will encounter in an intro algorithms textbook. The others tend to be domain specific and can't really be studied for anyway (write a basic X in framework Y). There's no reason to frame this learning as interview training beyond when you state the benefits of it for marketing[2]. There's no magical distinction between programming and interviewing, there are just some abstract topics that happen to be tested by interviewers and are also used in real life. [0] Not programming, computer science [1] When I say problem here it means something slightly different than a test question. The definition is closer to "a research question that was once, and may still be, unsolved." [2] Don't take this as an implication that you should be running a business, marketing is just part of making a good thing. It's understanding your users.