Think about building anything else, besides software. The act of building is very different than the act of fixing, and even the act of adding on. Practically

Think about building anything else, besides software. The act of building is very different than the act of fixing, and even the act of adding on. Practically all software interviews -- technically speaking -- about building new stuff. Fixing bugs, adding features, and dealing with technical debt have practically nothing to do with algorithms and other technical interview topics. Which is to say that if you're not into that, it's on you to find out early because most companies think all they have to do is hire the smartest engineers and everything else will work itself out. Typically you don't need to ask anything at all: unless it's a startup or some crazy project by an older company, you're fixing bugs and adding features. But probably a good idea to ask anyway. Or there are ways to make the "fix bugs and add features" gig work. Ask about their process: do they have docs, do they have a roadmap built with engineering input, how much time do they devote to addressing technical debt, and so on. It sounds like you're actually a good programmer, but coding is really a very small part of the gig. Now that you know how to do it, you'd probably benefit from learning the process around it and being proactive about what you're getting into.