I sympathize. Early in my career I landed a job in a small software company. My skills improved greatly. Then I made the mistake of taking an IT job. That IT jo

I sympathize. Early in my career I landed a job in a small software company. My skills improved greatly. Then I made the mistake of taking an IT job. That IT job rolled into another and another. While I stay near the technical top in my IT departments, I find it tough interviewing for software company jobs. The concerns of a software engineer in a software company are just so different from an IT developer’s. I interview for backend engineer jobs. I notice a common theme in the interviews: efficiency. They are very concerned with transactional throughput. They optimize everything from the services layer to the database for trimming every microsecond. At a past interview, the people wanted me to talk about the efficiency and implementation of various data structures: nothing exotic, just garden variety queues, stacks, lists, and hashmaps. They quizzed me on threading issues. One guy got into various indexes in a relational database and then jumped into TCP vs. UDP questions. In my most recent interview, the guy started by asking me the difference between optimistic and pessimistic locking. In my IT job, I never deal with locking issues: they are all abstracted away. Two-thirds of the way through the interview, I remembered and circled back to the question. However, the damage was more than likely done. A person who deals with those issues daily would never forget. But, I know what to work on for the next interview. I understand your predicament. It’s deadening on every level when you’re doing work beneath your capability and interest, but you don’t have the necessary knowledge to get through an interview for more interesting jobs. Hopefully, the observation I made above helps you to target particular areas to successfully navigate an interview.