Search Unity

Describe how you design software?

Discussion in 'General Discussion' started by yoonitee, Aug 10, 2015.

  1. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    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. :p



    (*I've had many non-Unity programming jobs before.)
     
  2. Master-Frog

    Master-Frog

    Joined:
    Jun 22, 2015
    Posts:
    2,297
    Programming != software engineering, I know that.
     
  3. SpaceMammoth

    SpaceMammoth

    Joined:
    Jan 2, 2013
    Posts:
    220
    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.
     
  4. Dreamaster

    Dreamaster

    Joined:
    Aug 4, 2014
    Posts:
    148
    "Explain how you go about designing software?"

    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."
     
    jpthek9, Gigiwoo and ippdev like this.
  5. Master-Frog

    Master-Frog

    Joined:
    Jun 22, 2015
    Posts:
    2,297
    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.
     
  6. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    That's almost poetic. :)
     
    Gigiwoo and Dreamaster like this.
  7. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    The correct response:
    "The simplest way possible. But no simpler"
     
  8. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    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.
     
  9. Master-Frog

    Master-Frog

    Joined:
    Jun 22, 2015
    Posts:
    2,297
    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.
     
    jpthek9 and Gigiwoo like this.
  10. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    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.
     
    jpthek9, landon912 and minionnz like this.
  11. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    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.

    Edit: Or - what frosted said :) Agree 100%
     
    yoonitee likes this.
  12. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,465
    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.
     
    frosted likes this.
  13. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    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.
     
    Last edited: Aug 10, 2015
    Kiwasi and frosted like this.
  14. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    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.
     
    Kiwasi likes this.
  15. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    That reminds me, I still have to develop my new programming language which will have code like:

    Code (CSharp):
    1. When the user clicks the top button then transition to the Start Menu.
    which will be actual valid code. But until then, I guess I'll learn some design patterns.
     
    frosted likes this.
  16. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    7,828
    Whiteboard and sticky notes.
     
    Kiwasi and Dreamaster like this.
  17. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391

    Let me know when you manage to do it - I'd integrate with Cortana in Windows 10 then let her do all the programming for me :)
     
  18. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,465
    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?"
     
  19. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    A plain English coding language would presumably be structured like a design document. So the design pattern would be that of a design document.
     
  20. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,465
    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.
     
    minionnz likes this.
  21. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    Probably the closest thing to plain english programming is legal english. It's actually really interesting how legal documents are written. Legalese is a little different in that there's global variables defined by precedent and case law, but it's surprisingly similar in intent: to be precise.

    In terms of dealing with computers, precision involves S*** like differentiating between floats and ints, its much lower level than case law, which just means that... its more precise.
     
    Kiwasi likes this.
  22. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    This is how I approach interviews. I don't see it as an interrogation - more of a conversation to see if the company is the right fit for me, while they do the same.
    If I'm not happy with the way they approach the interview, then I'd probably be unhappy working there and looking for another job within a few months anyway.

    Make sure you ask questions. You should have long term goals, so you need to figure out whether their company will help you get there - I'd rather have a developer who knows nothing about design patterns but is willing to learn and focuses on self-improvement than a developer who knows patterns inside-out but is rigid and inflexible.

    That approach seems to have worked out well for me so far.
     
    Kiwasi likes this.
  23. delinx32

    delinx32

    Joined:
    Apr 20, 2012
    Posts:
    417
    No no no. Design patterns are the single most important thing you can learn about if you want to do any programming at all. They're not "corporate", and they're not "telling you how to code", they're explaining well thought out solutions to problems so you don't have to solve them again and again and again. If you learn them, and use them, you'll start thinking about programming differently. You'll approach problems by saying things like "Well, I think a strategy pattern would work here, and i'll need a factory as well." Other programmers who know design patterns will understand what you just said, and you can talk about code in an understandable way instead of saying things like "I want a bunch of classes that are all loosely related that implement some common interface and I need another class to generate instances of those classes based on a fixed set of parameters."

    Design patterns are not code, they are a way of thinking and talking about code.

    Design patterns == modern coding. Learn them and use them, and then the next time you get asked a question like that in an interview you can answer properly.

    My answer would have been "I probably have a good idea of how to approach the problem based on past experience using design patterns. I can't explain the process because its automatic, but after coming up with an overall framework for the project I stub out code and get all the pieces in place. Then I write the implementations to tie it all together."

    Depending on the audience, I might throw out some junk about writing unit tests, even though noone actually does that.
     
    minionnz and Kiwasi like this.
  24. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    2,640
    I have been through a few of these tests and they asked me crap about various acronyms and names of design patterns. I later looked them up and found I had been doing them for years...because they worked well for me... not because I had some professor tell me they were important acronyms to spit out. I am self taught at everything and frankly..when someone wants me to do a test about such and asks general compsci graduate student rememorabilia I really don't think I want to work there. They won't let me stretch my legs and flex my muscle. I can also name other design patterns they miss because they are spitting out rote and verse and not down in the trenches knowledge of component based design for game mechanics in Unity. I wasn't auditioning for a windows forms job or a cloud stack programmer..I was interviewing for a game dev job ffs.
     
    XGundam05 and Kiwasi like this.
  25. tedthebug

    tedthebug

    Joined:
    May 6, 2015
    Posts:
    2,569
    depending what the company does, in non-game positions (corporate IT/Finance IT) I always mention ensuring that the requirements are clearly articulated & they encompass any legal obligations & internal management requirements. I often had requests coming from users or mid level managers that wanted something that breached company, legal or government reporting requirements. Then document the high level details, break it into smaller chunks/modules that can be worked on & tested independently whilst feeding into the whole. Check for interfacing systems & any potential conflicts, data sending/receiving & storage.
     
    Kiwasi likes this.
  26. GoesTo11

    GoesTo11

    Joined:
    Jul 22, 2014
    Posts:
    548
    I'm not a programmer but I did stay at a Holiday Inn Express last night. If you play in Waterfalls, expect to get very wet and if you are not careful, you will get swept away. You need to be Agile so that you can dodge the waterfall and keep dry.

    But in all seriousness, I wonder if Agile vs. Waterfall development could have been part of the answer to that question. As I understand it, Agile is quite the buzzword these days and if you are dead set on Waterfall development you might not be a good fit for an outfit that uses agile development.

    Be encouraged that you are getting interviews. I've never had an interview for a software development job.
     
    Kiwasi likes this.
  27. Teo

    Teo

    Joined:
    Oct 31, 2009
    Posts:
    564
    @yoonitee Hahaha, don't worry dude, move on.

    I am contacted by different HR dudes.. poor guys, 99% of them are practically not competent to judge correctly because they don't have required knowledge. Also stupid questions, like "do you know GIT?"
     
  28. 3agle

    3agle

    Joined:
    Jul 9, 2012
    Posts:
    508
    That is how I viewed the question, and likely how I'd have answered, design methodologies are a big part of how I go about designing software.
    Interestingly I have just started a set of projects using Agile with my team, it will be interesting to see how it works out. We normally use Iterative/Prototyping.

    And on that last point, I'd argue that a developer that can't adapt to new development methodologies isn't a good fit for most companies. It has next to no effect on how you actually do your work, more on how you communicate and plan, flexibility is a desirable trait.
     
  29. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    So I did some research on design patterns. That is to say I scanned the Wikipedia page. It looks like I've been using some of these without realising it. Such as lazy initialisation.

    Interestingly at the bottom it says that some of these patterns are simply due to lack of direct language support.

    Is there some more interesting ways to learn this because my eyes are struggling to keep open when reading down the list? I tend to think more visually, and so all these ways of talking abstractly about things just goes in one ear and out the other. Perhaps I'm just not suited to being a software engineer. :( I'd rather be writing an A* algorithm or some graphics code.

    Although I did learn the difference between "inheritance vs composition" designs which is something new.
     
    Last edited: Aug 11, 2015
  30. wccrawford

    wccrawford

    Joined:
    Sep 30, 2011
    Posts:
    2,038
    Your biggest mistake was lying in an interview. If you *had* got the job, and they wanted to see you chart something out, what were you going to do?

    The truth would have been so much better, even though it boiled down to, "I just futz around until the design becomes clear in my head." That's a bit harsh, but not far from the truth I bet, huh?

    In actuality, what you probably do is just start coding until you get a clear view of what's going on, and then structure the code accordingly, sometimes rewriting it from scratch. And this is a perfectly valid way to do it, though some will argue that there are more efficient ways to do it.
     
    Kiwasi and Ryiah like this.
  31. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,284
    Talking of design patterns in general. I think one of the biggest disconnects is that things like a "menu screen" doesn't actually exist in the real world. And so in the real world we never "transition to a menu screen". And so our brains might not have an abstract way of dealing with things like that so we have to invent patterns.

    Never in the real world do we see buttons float in mid air then dissolve when you touch them and a new list of buttons appear. If we imagine each screen is in some different dimension and that we are jumping through a wormhole each time we touch a button.... That's probably why it is almost impossible to describe the functionality of a menu screen with natural language.

    But that's going off topic!
     
  32. delinx32

    delinx32

    Joined:
    Apr 20, 2012
    Posts:
    417
    That's the point of design patterns. Design patterns give us a language to talk about code, a way to talk about things we do every day. When we talk about things that we do every day in a common language, then we understand each other.

    Imagine if every noob came to the forum and said something like "I'm trying to implement this strategy pattern, but I'm having an issue with the order of start/enable.", rather than "HALP! It doesn't work. I've got these things in a list and I get an exception."

    In the first case you might say something like "Consider using an observer pattern on your top level component to monitor the initialization of the items rather than relying on unity's built in event order."
     
  33. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,137
    Since c# and c++ are object oriented you could have probably gotten away with "I design with abstraction and explaining that to you would defeat the point."

    I design my projects as modules. I go from pseudo-visual scripting to building the code for each node and then making changes is easier. Also dividing the project into small modules might give me some modules that can be useful in other projects and be accomplished faster since each one has a more specific purpose.
     
  34. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    The trick is, what exactly does "transition to a menu screen" mean?

    When you read a sentence like that, you can imagine some kind of result - 'put some kind of panel with some buttons on the screen' - but what does it REALLY mean? My menu screen and your menu screen are going to be written differently. They're going to have different concerns and stuff, and potentially a very different implementation.

    I use NGUI, and my "transition to menu screen" probably means:
    - make sure the caller has a reference to an ngui panel object.
    - On "TransitionToMenu", make sure we enable the game object associated with panel
    - Make sure that we rewind the tween for the panels fade in animation
    - Make sure the entry tweens start
    - Fade the saturation on the main world camera, so it greys out
    - Make sure that once the tweens are complete, we also update the "most current screen mode" enum and notify
    all the subscribers that we are now in main menu mode.
    - Make sure that there is some mechanism to prevent clicks on other potentially still visible buttons.

    That's most of the process for making sure that the main menu panel is visible. Does your list look exactly like mine? Probably not. So "transition to menu screen" as an instruction lacks precision (since there are clearly multiple interpretations). As a programmer, really what you do when your programming is take these fuzzy, imprecise statements or ideas like "transition to menu screen" and make them not fuzzy, not ambiguous, and much more exact.

    Code is really just a language you use to write a specification that has very little ambiguity, as the language gets lower level, there is more and more precision, more determinism and less ambiguity.

    If you look at that specification above, it's written in english and it translates pretty closely to a line by line set of statements in code - each of those lines is more or less an assignment or function call. The interesting thing to note is that the english description is actually inferior to the code description, it requires more words, it has more ambiguity. Just writing out the code is actually much more efficient and way more precise. That's why there will never be a 'plain english' programming language, because the code we have right now is just better at the job than plain language is. Plain language is better for communicating rough, general ideas from person to person when precision isn't needed.

    As for learning design patterns and stuff. I don't learn well from just reading articles or looking at diagrams. I need to get my hands dirty, write code and actually use a concept in practice before I am comfortable with it or talking about it. If you have free time (which if you're interviewing you probably have), then take a few hours every day, take a single design pattern - make a very small project out of one or possibly two - and put them to use.
     
    Last edited: Aug 11, 2015