As a someone who recently graduated 8 months ago, who has been working in the industry since, and who has been on tons of interviews in the last few years... I believe I have a relevant perspective on this. I've been rejected and accepted by the best and worst of them.
I don't have a great memory and I almost never have to recall some obscure implementation of a sorting algorithm outside of an interview. So you can imagine these types of interviews either go well, if I'm lucky enough to get a familiar problem, or terribly. This interview method merely tests a candidate's ability to memorize which isn't going to proved a ton of insight into how that person will be to work with. With that being said, there are many concepts and patterns which come with comprehension and experience which reveals a surprising amount about the personality of the candidate. For instance, using map/reduce instead of for loops everywhere or modularizing subroutines appropriately.
It's also notable that 6 months ago I firmly believed that I would never use some of the more theory related info from school (i.e. State machines) and 6 months later, guess what? I'm advocating the use of state machines to my coworkers as a way to approach a particular challenge at my company. The point being, you are going to learn valuable problem solving skills and get many ideas from existing designs, even if you aren't setting up linked lists and BST's at work.
tldr; Mohamed, you're absolutely right, but who wants to work for a company that doesn't understand what makes a good developer anyway. Keep at it!
As a someone who recently graduated 8 months ago, who has been working in the industry since, and who has been on tons of interviews in the last few years... I believe I have a relevant perspective on this. I've been rejected and accepted by the best and worst of them.
I don't have a great memory and I almost never have to recall some obscure implementation of a sorting algorithm outside of an interview. So you can imagine these types of interviews either go well, if I'm lucky enough to get a familiar problem, or terribly. This interview method merely tests a candidate's ability to memorize which isn't going to proved a ton of insight into how that person will be to work with. With that being said, there are many concepts and patterns which come with comprehension and experience which reveals a surprising amount about the personality of the candidate. For instance, using map/reduce instead of for loops everywhere or modularizing subroutines appropriately.
It's also notable that 6 months ago I firmly believed that I would never use some of the more theory related info from school (i.e. State machines) and 6 months later, guess what? I'm advocating the use of state machines to my coworkers as a way to approach a particular challenge at my company. The point being, you are going to learn valuable problem solving skills and get many ideas from existing designs, even if you aren't setting up linked lists and BST's at work.
tldr; Mohamed, you're absolutely right, but who wants to work for a company that doesn't understand what makes a good developer anyway. Keep at it!
Thanks a lot for the kind words! Who knows what makes a good developer, anyway!