| TL;DR: different people have different programming styles and you might not be programming the way they expect you to; but that might not be the problem. The problem might be that you're focusing on the part of the interview that the interviewer doesn't care about and that makes it so that the interviewer gets frustrated and doesn't see your skill. -- When I was younger, I got a chance to work on a game with a friend of mine. My friend was an incredibly skilled programmer, probably one of the best programmers who built things people used or could use, that I knew at the time. I was a competition programmer. We were both learning HTML5 at the time, and we both took on the task in very different ways. I believe we were writing Nibbles (Snake) or something like it, as a learning exercise, each. I learned the basics: arrays, function creation, etc, and then went really fast at building the whole program without testing it, connecting all the pieces together in ways that I assumed would work. In the programming competitions I took part in, 3 people shared one computer, all doing different problems at the same time, so most of us wrote our code on paper before we put it in to the computer. After my whole code for snake was written or at least as much as I wanted to have for a prototype (it's been many years since we did this, so I don't remember a lot), I started trying to run it. It didn't work, of course, or did messy things, and so I spent a bunch of time going through and fixing the bugs that were in my code. My friend went a completely different approach. Of course I don't remember specifics, but it was something like this: * he got a pixel drawing in a canvas * he got a pixel moving on the canvas * he got apples appearing on a canvas * he got a chain of pieces of the snake following * he got collision working Of course, this is probably not what actually happened; but, this is basically what I remember about how he coded. He was very slow, methodical, and had a step-by-step process of how the whole code would work. In the end, I think he had his program working before I did and much better; but, if you looked at just the start, you might assume he's not skilled. -- Let's fast forward to today and a different person. I was talking directly to a senior engineer at my company the other day. Very skilled, very, very skilled. We were talking about how we do things. It came out that I design systems and draw pictures to get flow and layout down. I like to work on weird, pie-in-the-sky, robust systems that tend to take a drawing to figure out later, because they're powerful and do powerful things; and, the goal of those systems tend to be to pre-emptively be ready for v-next and handle all of the requirements as cleanly as possible, and future requirements as cleanly as possible. He greatly prefers to start hacking on a solution quickly and get something building and then work in the nuance and ugly later, refactoring whole sections over time to get a better and better solution. When I remark on a dangerous test case or scenario area that I'm worried about when it comes to the upcoming solution, he's always thought of that problem area ahead of time, too; but, from what he tells me about how he works, he starts hacking basically right away; and, I don't think he does the crazy designs as his first version, either. -- I'm not sure where I'm going with this; but, I think I want to say that this: > I ran node in console after small changes and additions to print, test, debug. is not a sufficient reason to think you're not senior; but, this: > I didn’t have a mental model of the subtask might be. Please notice that I reduced what I said down to a very, very narrow statement. If you eventually have a mental model, then I think you're fine here. -- I'm going to add some more. This might be an interviewing problem, and I think it may be important to get a feel for what sort of interview it is, even asking them. If you're adding a bit, printing, testing, adding a bit, printing, testing, you might be adding a bit to things that your testing partner doesn't think matters. Did the interviewer expect the code to compile and run proper tests? Or were they just trying to understand your thinking process? If the interview only cares about your thinking process, then they probably don't care if you don't write the code to get the substring you need exactly right, or they might not care if you get rounding wrong, or output formatting wrong, because that's not the part of the problem you're being asked to solve. You get better at this by interviewing more and practicing asking questions. -- You mention this: > The feedback was you can’t do this when compiling time is long and development will be slow While this is true, for most of the work I do, I could write a small program on the side that tests the design I'm going for that compiles quickly and then inject that code into the larger code base and test the rigging. Maybe that's not how it is for the job you're looking at. I've said a lot, I hope this helps. |
>He greatly prefers to start hacking on a solution quickly and get something building and then work in the nuance and ugly later, refactoring whole sections over time to get a better and better solution.
I think you've articulated a dimension of programming that I've increasingly been observing and discussing with other engineers.
Do you happen to know a name for (or any language to describe) this kind of spectrum of problem solving where one end tends to pre-emptively encompass as many edge cases and future versions as possible, while the other focuses solely on the most obvious use case initially, adding in each edge case in successive versions of a "working" product (where working is used very loosely (i.e. single pixel on a screen is a "working" initial version))?
I definitely fall into the latter category, and find it very frustrating to work with engineers who want to chat edge cases that are days, weeks, or even months away from being relevant in my eyes. I would like to understand their thinking and this space of meta-problem solving better, but I'm not really sure what to call what we're talking about.