It sounds like your main problem is confidence. The simple act of having more confidence revolutionized the way I look at interviews. Look at it this way, if y

It sounds like your main problem is confidence. The simple act of having more confidence revolutionized the way I look at interviews. Look at it this way, if you've really been developing that long, you're a fricken veteran. Unless you've been writing up TPS reports in Excel for 13 years, you've seen and used a wide variety of tools to build projects, and get things done. New grads may know the difference between a tree and a trie and how to optimally traverse each, but you know how to define a project, what to expect as you scope it, what types of tools tend to work best for different approaches, how to develop with an eye to scaling and maintaining, how to test things, how to deliver them to end users, and so on. There are probably dozens of types of projects that I could ask you about in a social setting, and you could immediately deliver a 5-minute sketch of how to design and build them from scratch, pros and cons of various approaches, likely problem areas, etc. That comes from the experience of having lived it for a decade, and the confidence to recognize that you can do these types of things, because you have done them, and because you're smart and resourceful. This sort of confidence in one's abilities is such an asset when interviewing. Just assess your skills, know what you can do, and talk like you know what you can do. Sure you don't know everything about these skills, but who does? The thing about CS fundamentals and interviews focusing on them is just a lame facet of the industry. It's hard to assess complicated skills in a standardized way, so instead people ask about data structures and language syntax. It's like interviewing an architect by asking him minutia about specialty hammers, but it's just the way it is. Look at it as a flavor of FizzBuzz, read through some books on the topic. If you're asked such a question, try to get behind the question, see what the interviewer is really assessing, and speak to that out of your skill toolbox. If you want some CS theory book recommendations, here are my favorites: - "Cracking the Coding Interview" by Gayle Laakmann - "The Algorithm Design Manual" by Steven Skiena