Ask HN: Do senior engineers have a mental model before coding?

FAANG interview is all about leetcode problems. Where your competition has already extensively studied the problem sets. If you cant get it the first time, and spend 15 minutes on bad solutions as you work through it, its a rejection. FAANG wants you to show up with near optimal solutions.

FAANG interviews aside, I find the idea of having a mental model before you write code extremely helpful. It's a lot easier to understand the purpose of individual functions and how things should interface with each other if you do. It won't be perfect at first, but the more you can get right in the first stab the better.

Your ability to build that mental model depends on both your experience/skill and the complexity of the problem. For simple problems, a more senior engineer might be able to come up with a mental model instantly because it's similar to lots of things they've done before. For really complex problems, it probably takes everyone a long time to build the correct mental model and you'd want to balance that with what you can figure out by diving into the implementation.

My guess would be that the interviewers' line of thinking is that if you couldn't build a mental model for a problem quickly, that means you're not proficient with problems like that. Which is probably true, but opens up the question of whether the interview is testing the right type of problem, of course.

In my experience its purely random if/when someone will care about that. You just have to do a lot of interviews and if you're still coming up with near optimal solutions in the allotted time you should be okay.

I also do not think Senior Engineers have better mental models of these code trivia questions than Junior Engineers do on average. Seniors spend more time on architecture and facilitating Juniors to be more productive so I dk.

I have never been in an interview where piecing out the problem solving and debugging outside of whatever the IDE/editor of choice was frowned upon.

Maybe they just wanted to see you solve the solution in the pair programming window and thought you were copy/pasting your solutions from someone that was helping you off screen.

Yes - it's essential for debugging.

Your mental model tells you that if the system is in a given state, and receives a given input, what "should" happen. You can then look for evidence whether those things happened and narrow down a bug.

It also works the other way. If, given this input, that happened, your mental model tells you what the system state must have been. That can help you work backwards to identify a bug that put the system into a bad state.

A. It's pretty dumb to fail an live coding interview assignment for that reason.

B. Yes, mental models are absolutely critical.

---

A better interview assignment to test mental models would be to architect a data model or system. No code, just concepts and relationships.

On meaningfully sized non-FizzBuzz problems, starting by banging out code is like starting a vacation by getting in the car and driving. A better use of time is upfront thinking about possible plans, pros, and cons.

I think you probably should build a mental model. The way I see it the code/compile/debug loop style of programming is a bit like a gradient descent. You are probably going to fall into whatever solution pops up rather than really thinking about what makes sense.

With that being said no one is smart enough to not use a debugger.

I don't think it's a good idea to start the implementation firmly planted in the trees of the forest you're trying to see.

I think it's best to start with something like an outline. This could be comments, tests, sparse pseudo-code, or some level of documentation that explains what you're trying to do.

Once you have a rough idea of the pieces that are required and will roughly fit together, understanding the consequences of the decisions you make while implementing those pieces will come more naturally, and can help prevent rework. Most architecture mistakes, and often bugs, are from not understanding the consequences, which isn't really possible without having the mental model.

Maybe I misunderstand what you're talking about, but wouldn't this manifest when you ask questions and talk about your approach?

Comunication while coding seems to be a big deal during interviews now so if you just started coded after hearing the problem I could see that being a negative.

Yes, I pretty much have a mental model of what I want to build before I build it. I am not sure that I build the mental model in 30 minutes, though; rather I get an idea, think about it over the course of many days, talk with people about it, write down some design details, etc. Only after all of that does any programming begin, and the actual coding is then the easy part. You know what data structures you need. You know what the external API will look like. You know how to deal with the tricky parts; be it integration or some sort of unusually complex algorithm.

Doing the design work is what separates senior and non-senior engineers. The more details you get worked out before they are solidified by having 10 other systems depending on them, the better.

If you just do stuff with a rough idea of the direction you want to go in, it's very easy to get sidetracked by something that doesn't matter. It's also very easy to build something nobody wants. By having people agree on some sort of semi-detailed design that describes assumptions, corner cases, the API, etc... you dramatically increase your chances of building the computer program that people want.

I am not sure how you test for this in an interview... but it is important. If you don't design things before building them, that is something you should start working on.

I tend to build out a mental model of the bigger blocks of a feature, but will iterate on details as I code, just like you described. And I rarely run my code through a debugger because with that mental model and some judicious logging, I get the job done. But there are people who think coding in that way is asinine, and shows I'm not experienced. Different folks work in different ways.

But because of those differences, it may have been the right call to not move forward with you. That is not a judgment against you. It is an acknowledgement that you don't work the way they like to work, and may have had a hard time melding into the existing team. Or it may have worked, but hiring managers try to avoid risk where possible.

That is fine. Getting turned down for a job that you were perfectly capable of doing is a reality in this industry. Find another place, try again.

Depends. If I'm just sketching something in code, or I don't know what I'm actually building, I'll write it out in code first.

However, if I'm designing a known thing, where I understand what it's suppose to do; I usually devise a mental model of the thing I'm trying to build before I start committing to code.

Also, having a mental model for the system that you're designing makes it apparent whether someone else can pick up and understand your system.

I also don't really use a debugger. Not sure why though.

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 inte...

Well, in the real world I find that you don’t understand the problem you want to solve until you’ve applied a working solution to it. Practically speaking I tend to deliver quickly to accelerate the process, then refactor once all the requirements have been exposed. As mentioned here, this probably doesn’t project well in an interview. It’s a case where the most efficient practice is not the most presentable one. I’ve failed interviews for this reason too. Lessons learned!

I do not know about success in FAANG interviews.

This is just something that happens while I'm "thinking about how to approach the problem." I have an idea of what a computer can do and (hopefully) what the steps might be to solve the problem I'm trying to solve. I'll test out some things in my head and then start typing.

I think different people are different, using a console that doesn't tell me that you didn't have a mental model of how the program would work, it just tells me that you like to test as you go. That's a good, careful, practice and not a red flag to me at all.

read-eval-print loops are a time honored tradition in a number of communities. I've written entire programs by typing into a REPL and dribbling the results as I go. Languages with long compile times are genuinely unfun to work in.

So i guess my question for you, if you didn't have a mental model, how did you know what to type into the console?

Also, if developers didn't need debuggers because of their mental model, why are there bugs in the code that they are working on?

Mental models are necessarily imperfect.

Personally, I prefer your approach to writing a big huge chunk of code, assuming it is perfect, and testing it at the very end only to find all of the bugs.

I usually sketch out what I'm going to write with comments and/or function names. It gives me the sort of 'blocks' of how data is going to flow, where responsibility is divided, etc. Then I go back in and fill the details of the block. Five or six comments becomes five or six chunks of code.

I don't usually try to maintain an entire state in my head, but I do try to make sure each of those blocks is something that I can reason about and hold the entire state of. If I'm finding it hard to figure out what each block does with data, I subdivide and write two comments.

For example, I might write something like:

// Iterate over every transform and do the matrix math

and realize that there's too much for me to hold mentally, so I'll do this:

// Iterate over every transform

// Invert each matrix

// Get the position vector

// Multiply by the character's scalar

... etc.

After that all scans, then I'll start writing the actual code.

I try to keep as much in my head as possible.

Stuff in my head is always easy to change, and I find I need to change CONSTANTLY.

I create what I term a "napkin sketch," and try not to write down too much, afterwards.

Documentation is a HEAVY "concrete galosh."

That said, it's often imperative to write stuff down; especially in a team. It's just that every single thing you write down becomes tech debt.

I talk about that here: https://medium.com/@ChrisMarshallNY/concrete-galoshes-a5798a...

Sometimes yes.

Sometimes no. That's when I do TDD.

The problem with mental models is that they are domain specific. My domain is sports data, solving problems is easy because I have 10 years of experience and a cookbook of models (can we say patterns) to apply to any given problem

Good mental models == Lots of experience

I suspect that the senior that interviewed you would be out of his depth if he moved into another domain. I definitely would. But then again having lots of experience helps you identify the patterns - sorry models - quicker and recognise the problems that you will need to guard against

"Building mental models" sounds like a deliberate cognitive act. To be honest it is more like recognising which part of an existing system would best fit the problem and what changes are need to be made to get a better fit

Which kinda makes it sound a lot less glamorous :)

Anyhow let me repeat:

Good mental models == Lots of experience

I'm not sure how could you write anything if you don't think about the problem before? I didn't like my last whiteboard interview because I just stare at the screen for a long time before writing anything, and sometimes even the best design decisions happen outside when I'm walking or under the shower.

I think your practices are fine - coding even a limited prototype reveals a lot of unanswered questions in a mental model. Once you have the model, you can apply it in a theoretical sense, but in my experience it takes longer to build one by not coding than it does by doing some coding, then some thinking. The only limitation on prototyping is that it's difficult to communicate what is being accomplished in the middle of the process, because you'll make something that looks negligent or incomplete - it isn't trying to answer all the concerns yet(that's what you do in production code).

Plans are worthless, but planning is essential.

I'm lucky enough to have a memory/mind's eye where I can see the problem in my head almost always. I also tend to take time to flush that out in my head before I start coding, attempting to work through issues.

I'd like to think without having that, I'd take the time to put it in a day book.

In interviews, I've typically tried to draw/write out the problem (especially in terms of requirements) to help work through what I'm thinking.

Building at least a minimal mental model takes me far less time than trying to jump in and code something without one. When writing a trivial method/function, it often takes only a fraction of a second[1], but having it tells me if I'm on track to accomplish what I set out to. The mental model helps you plan and course correct... without it, you're likely either learning/exploring/doodling (which should help you build a mental model) or flailing about. You can get by on smaller scale/solo projects without one but it becomes an issue if you are expected to work in/with one more teams and or larger scope/scale projects.

[1] It takes effort in the early years, but like anything else you work at it does become second nature. I often don't consciously decide to build a mental model for simple tasks... it just happens reflexively with minimal time and virtually no effort. Now the model may be crap/wrong... but that's the value if it: as soon as what you're doing/observing doesn't match the model, you know you have a problem and need to course correct.