Had another Unity interview today* and another fail
This time, got all the math and general C++ and C# coding questions correct.
But then got tripped up by the seemingly benign questions:
“Explain how you go about designing software?”
“Explain the parts of some software you wrote?”
My mind went blank. It seems like I’ve been programming so long that it’s almost become second nature like walking. And asking someone “How do you walk?” “Well… I… just do…?”
I said something about flow charts. (I don’t actually use flow charts but this seemed like the right thing to say).
OK. Now berate me. I’m ready for it.
(*I’ve had many non-Unity programming jobs before.)
Read about design patterns, even if you don’t like them they are a useful language for talking to others about design. Also consider reading “Code Complete”, it really is a good book for software engineers.
Hmm… my answer would have been something like …
“Software is a tool created to solve a problem, so the first thing I would do is restate the problem as simply and cleanly as possible. Then I would think about the solution in the most general terms and write them down. Then I would start breaking down the general solution into more specific pieces… what data needs to be stored? What information does the software need from the user? From those questions then the actual software starts to emerge, because the answers to those questions become the structures for database tables, objects, and GUI and the calculation and business rules that will bind them together.”
In the future, just say you do test-driven development and follow the MVC pattern. Also mention single-responsibility. Find out what the interviewers opinion is of Singletons and agree. Haha.
Is it just me or when you here the words “software engineering” and “design patterns” it makes me sleepy. It seems so corporate and almost the opposite of the spirit of indie dev.
I know it’s important to know these things. But I struggle to get excited by them.
I did feel that way, really strongly. Then I went and tried to make a complete game, and after lots of rewriting I started seeing the point of it all. Now, I am actually scared of not using any pattern. Randomly plugging away works until it doesn’t, then it’s just boring, tedious work.
You gotta remember that working in teams is extremely different from working solo.
Honestly, I don’t think that design patterns themselves are particularly interesting. The important part about design patterns is how you use them in communication. They give developers a common vocabulary to talk about how they approached a problem. In this regard, they’re extremely valuable.
The problem is that people think of them as fancy, “good developers use design patterns” blah blah blah. Developers have been using these techniques forever, tons of them are filthy hacks and workarounds for inadequate language features. Trust me, you can write just as terrible code using design patterns as without.
But as a tool to describe a process to someone else, or talk about techniques with other devs, they’re really kinda invaluable.
Patterns solve common problems - you’ll probably find you use a few without knowing it anyway.
But the biggest advantage of patterns (IMO) is that other developers will recognize the pattern.
This actually is a tough one. It’s designed to judge how you think and check your experiance level. Here is one possible answer.
“When I design software I look first to my target audience. What are they going to use it for? What problems is it attempting to solve? Normally I would sit down with key users and get a very clear list of requirements. This may go back and forth several times. Clearly stating the problem to solve is key.”
“Once I have a clear problem statement I go on to sketching out the basic structure of the program. I’ll mock up basic key data structures and key user interfaces. These I’ll review with the key users, making sure this still meets their needs.”
Then you can move on to discussing the build process.
Sometimes employers are simply trying to hit you with a problem you’ve never encountered before, and see your problem solving skills at work. It’s always valid to say something along the lines of “I’ve never done this before, it’s a skill I’m keen to learn. This is how I would approach it…”
Stick with it. The job search process can suck, I’m in the middle of my own now. But you’ll find something suitable.
This makes sense. Because what I’ve been doing seems to work. But my brain doesn’t have the vocabulary to explain what I just did to other people.
Yes, the job interview process sucks. Literally, it feels like the interviewer is trying to suck out your brain and invade your private thoughts and then you sit there having your entire life choices judged.
Writing code is really nothing more than writing an extremely detailed specification. If you actually understand the problem in depth, writing the code for it is just a bunch of typing.
The process that most of us think of as ‘programming’ is really just the process of learning what the actual problem is, and learning which parts of the problem we thought we understood but didn’t.
Software design has very little to do with language. Language is generally an implementation detail. Design refers to everything you do before you start building. Most major projects I’ve been on spend more time in design then in any other phase.
Implementing a “plain English” coding language will have no effect on the need to design software. Nor will it have an effect on design patterns. And quite frankly I would be surprised if design patterns were the answer they were looking for, design patterns are about code structure. More what you would design then how.
As another pro tip, it’s always permissible to ask the interviewer for feedback afterwards. Something along the lines of “Do you have any feedback about how I interviewed that I can take to my next job?” It’s both flattering to the interviewer and it shows you care about self improvement. And if you really feel like you bombed with no hope, straight out ask “I struggled with the question xxx, what sort of answer were you looking for?”
You would still need the maintainability and flexibility that can come from decent design patterns. Especially in a large project.
Until you can argue both for and against any particular issue, you don’t have a good understanding of it. Your constant dismissal of design patterns isn’t a good sign to employers. There will be plenty of times when you are required to follow a pattern because someone senior to you said so.
Spin it around. Consider the interview more about you deciding if the company culture, ethics and work flow is right for you. Judge their life choices.
