|
Paolomania posted:But it is just so much more impressive to say something ostentatiously verbose like "use a Proxy Pattern" rather than "use a proxy". I think this level of verbosity required to be a Java programmer. You should be able to skim the wikipedia article for the book Design Patterns and get enough for an interview.
|
# ? May 30, 2012 21:36 |
|
|
# ? Apr 25, 2024 20:49 |
|
Cicero posted:Honestly all the design patterns start to feel like the same after a while, so I think it's kind of dumb to just say "What's pattern X?" instead of just saying "You're in this situation, what would you do design-wise?". The other big thing is that half of these don't make sense in all contexts. There are a lot of places that they work and a lot of places where you can take the lessons from it and apply them, but there are also times when you can work out a custom solution and have it fit much better.
|
# ? May 30, 2012 22:42 |
|
NovemberMike posted:I'm not really a fan of questions like that because it's mostly a familiarity thing. I'd read through "Design Patterns: Elements of Reusable Object-Oriented Software" though to get an overview, I think that's the standard still.
|
# ? May 31, 2012 02:23 |
|
aBagorn posted:I know he asked me what I knew about Factory Method, Observer, Mediator, and maybe one other (Builder?) Dodged a Bullet There.
|
# ? May 31, 2012 11:31 |
|
tef posted:Dodged a Bullet There. Oh?
|
# ? May 31, 2012 15:05 |
Yeah, I'm not really seeing how he "dodged a bullet." aBagorn, practical knowledge of best practices wrt OO design will only come with experience. That is, building actual products used in the real world by actual users, dealing with requirement changes, testing environments etc.
|
|
# ? May 31, 2012 16:25 |
|
A MIRACLE posted:Yeah, I'm not really seeing how he "dodged a bullet." aBagorn, practical knowledge of best practices wrt OO design will only come with experience. That is, building actual products used in the real world by actual users, dealing with requirement changes, testing environments etc. If the company equates "knowledge of OO practices" with "knowing some tricks created to hack around missing language features", then yeah, aBagorn most certainly dodged a bullet.
|
# ? May 31, 2012 19:11 |
|
Everybody just uses Singleton pattern anyways.
|
# ? May 31, 2012 19:59 |
|
Kim Jong III posted:If the company equates "knowledge of OO practices" with "knowing some tricks created to hack around missing language features", then yeah, aBagorn most certainly dodged a bullet. Can you give me some examples of design patterns that are used to hack around missing language features? I've never heard that before and it sounds kind of neat.
|
# ? May 31, 2012 20:53 |
|
Strong Sauce posted:Everybody just uses Singleton pattern anyways. I made a Sigh Expression as I sipped my Coffee Fluid.
|
# ? May 31, 2012 21:46 |
|
Safe and Secure! posted:Can you give me some examples of design patterns that are used to hack around missing language features? I've never heard that before and it sounds kind of neat. All of them http://norvig.com/design-patterns/ I wrote this some time ago I swear I'm a broken record posted:A design pattern is an abstraction that the language enables but does not support. We chastise those who copy and paste code as beginners, but when experts do it is is a “design pattern”. edit: aha found it http://forums.somethingawful.com/showthread.php?threadid=2779598&pagenumber=171&perpage=40#post399457139 tef fucked around with this message at 21:51 on May 31, 2012 |
# ? May 31, 2012 21:47 |
|
Strong Sauce posted:Everybody just uses Singleton pattern anyways.
|
# ? May 31, 2012 21:53 |
|
^^^ drat it tef is there anything you don't beat me at?Safe and Secure! posted:Can you give me some examples of design patterns that are used to hack around missing language features? I've never heard that before and it sounds kind of neat. Pretty much all of them. Norvig found that of the 23 GoF patterns, 16 of them were trivial or even invisible in Lisp. The PPR talks about this a bit more too and (might) be even more readable than slides from 1996 vv
|
# ? May 31, 2012 21:54 |
|
Safe and Secure! posted:Can you give me some examples of design patterns that are used to hack around missing language features? I've never heard that before and it sounds kind of neat. For simplicity let's just consider iterating a linked list. In the pattern model you construct a class that implements some sort of IVisitor interface, and pass it to the list object via something like a iterate(IVisitor v) method. As the list iterates each node, it'll invoke the visitor's onVisit() method or something. This is all functionally equivalent to, but requiring a lot more mechanism to build up, than simply passing a function to an iterate method that would call it with each list element. But, in languages where you can't pass functions or define anonymous functions, you're stuck with building up all the Visitor mechanics. edit: teffu (and others)
|
# ? May 31, 2012 21:57 |
|
Strong Sauce posted:Everybody just uses Singleton pattern anyways. I loving hate singletons. Every time I see one, it means that it's going to be hard-verging-on-impossible to write good unit tests for anything that touches the singleton.
|
# ? May 31, 2012 22:50 |
|
Ithaqua posted:I loving hate singletons. Every time I see one, it means that it's going to be hard-verging-on-impossible to write good unit tests for anything that touches the singleton. I don't unit test because I am basically Satan, why does a singleton prevent good unit testing?
|
# ? Jun 1, 2012 01:12 |
|
baquerd posted:I don't unit test because I am basically Satan, why does a singleton prevent good unit testing?
|
# ? Jun 1, 2012 02:12 |
|
baquerd posted:I don't unit test because I am basically Satan, why does a singleton prevent good unit testing? Sedro pretty much covered it. The canonical implementation of a singleton is a hard dependency across your entire application. You cannot change its implementation, so it makes it really hard to write isolated unit tests for methods that rely on singletons. Look at this implementation in C# (stolen from Jon Skeet, of course): C# code:
2) The instance is private, so you can't replace it 3) It has a private constructor so you can't instantiate a "mock" version You can get around it -- I've done it by making an ISingleton interface and creating a SetSingletonInstance(ISingleton newSingleton) method, but it's still not ideal.
|
# ? Jun 1, 2012 02:22 |
|
Dijkstracula posted:For simplicity let's just consider iterating a linked list. In the pattern model you construct a class that implements some sort of IVisitor interface, and pass it to the list object via something like a iterate(IVisitor v) method. As the list iterates each node, it'll invoke the visitor's onVisit() method or something. That's not the Visitor pattern.
|
# ? Jun 1, 2012 05:12 |
|
Also y'all's design-pattern-hating worldview is stupid. Design patterns are not work-arounds for lack of language features. They are the exploitation of language features. (A "language feature" in Java or C++ that supplants something like the visitor pattern would be redundant syntactic sugar. The entire point of good programming language design is to have it be powerful and useful so that you can build on top of it.) The proper reason to hate "design patterns" is because design patternists overcomplicate the taxonomy of design patterns by inventing a lot of meaningless distinctions. There is almost one OOP-specific design pattern: the Visitor pattern. Because hey, our language don't got algebraic datatypes. The other design pattern might be "using virtual methods." That's literally more than half of the Gamma et al Design Patterns book. Other design patterns (the "structural") are stuff like "having the thing receive updates from the other thing" pattern and the like, which are, um, you might as well call using mutexes a design pattern.
|
# ? Jun 1, 2012 05:23 |
|
Ithaqua posted:You can get around it -- I've done it by making an ISingleton interface and creating a SetSingletonInstance(ISingleton newSingleton) method, but it's still not ideal.
|
# ? Jun 1, 2012 05:38 |
|
shrughes posted:Also y'all's design-pattern-hating worldview is stupid. Bingo. Welcome to the design pattern haters! quote:There is almost one OOP-specific design pattern: the Visitor pattern. Some will argue that this is a lack of multiple dispatch in the language quote:That's literally more than half of the Gamma et al Design Patterns book.
|
# ? Jun 1, 2012 10:57 |
|
Strong Sauce posted:Everybody just uses Singleton pattern anyways. I would happily fire anyone who used a singleton without a very good justification. On the topic of design patterns I would say they're not really there to make sure you write good code, you can still write awful code no matter what kind of pattern you're following. It's more so that other people can understand what the hell you're doing. If I present some code to someone and say this is using the Delegate pattern for example, they will instantly know the structure and/or nature of the code. If they need to extend or add functionality to the same product they can simply use the same pattern. Using them won't make you a better programmer though. Though absolutely not using them probably means you're a bad programmer. Aramoro fucked around with this message at 12:47 on Jun 1, 2012 |
# ? Jun 1, 2012 12:43 |
|
Sedro posted:You can get around it with a Service Locator, but that's also an antipattern because it hides dependencies. I don't want to instantiate something only to get an exception because of a missing dependency, tell me at compile time. How do you feel about dependency injection and run-time component wiring in general (as these "hide dependencies" at compile time) ?
|
# ? Jun 1, 2012 18:50 |
|
Paolomania posted:How do you feel about dependency injection and run-time component wiring in general (as these "hide dependencies" at compile time) ?
|
# ? Jun 1, 2012 20:11 |
|
Aramoro posted:I would happily fire anyone who used a singleton without a very good justification. So what is your definition of a "very good justification"?
|
# ? Jun 2, 2012 01:05 |
|
shrughes posted:That's not the Visitor pattern.
|
# ? Jun 2, 2012 21:57 |
|
I've been working in QA in web development for a year or 2, and tomorrow I am going for my first interview as a developer. It's a front-end role, so css, html, javascript etc, but I was told there would be a short test during the interview. Will this just be coding a site or something? Any advice or resources I could use to brush up for it? I've never done web development professionally before.
|
# ? Jun 3, 2012 03:58 |
|
I had an interview for a C# development position recently that I did rather badly at. I have a few years of C++ and Python experience under my belt from personal projects only, so I understand a lot of the basics of object-oriented programming and how to learn how to use new things when the need arises. Unfortunately, this interview, which included a 30 minute test and a 2 hour code test involved me touching on things I hadn't done in quite some time. The written test had 4 questions. The first involved identifying an error involving static and instance variables and what to do to fix it. It was an easy question, and I clearly identified the problem, but I didn't write how it would be fixed (like the question wanted) even though I knew how. Another one involved 3 classes (named Test, Test2 (inheriting Test), and Test3 (also inheriting Test). I botched that one because I mistakenly assumed Test3 inherited from Test2 so got the result of the expression wrong (which involved virtual methods). I think that was more of a result of how you just don't ever name classes that way so my eyes kind-of slid over that detail. The final question involved a deliberately unusual quicksort algorithm and specifying the state of the array being sorted and the bounds and pivot after each stage in the sort. I didn't even finish that one because I was rather out of my element and I kind of sabotaged myself by thinking about how bad I am at pure algorithmic things and figuring stuff out without a debugger. Though I think it was the time limit more than anything that made me nervous and do bad at this since I wasn't calm. The code test was the worst part. I basically had to make a C# console program that took person and address data from a database and printed it out to XML or HTML depending on user input. In this part I was required to use certain C# design things like interfaces and abstract classes to design the XML and HTML writer classes and use a factory that provided an interface for getting the writer. Simple things. I also had to have an ASP.NET portion that would allow new person and address entry by web form. It was nothing difficult if given time, unfortunately I was given 2 hours. I think the first 15-20 minutes were sent trying to get the server connection set up in Visual Studio 2010, I didn't know the user name or password, and even when I got help for that we (myself and the person testing me) had trouble connecting it due to the server name supposedly not working when it should be. Next, I had to set up tables and relationships in SQL Server. I had only previously used SQL Server Compact, so the interface (from within Visual Studio 2010) was familiar, but I still had to figure out how to do several things with that interface. I held off doing the ASP.NET part entirely because I was the least familiar with it so I wanted to save it until the end, so I just entered some test data manually into the database. Afterwards, I spent the rest of the time frantically trying to get the program working as fast as possible within the time limit. I didn't even get to creating the HTML writer, and the rest of my code looked like poo poo because I didn't have a lot of time to think about design. Basically, I did terribly because I was having to work with a lot of things that I hadn't touched in years, and I had no time to refresh myself in doing things the right way since I was under time limit and I just wanted to get it working quickly so I sacrificed design (which is something the interviewer wanted to look at, but didn't make that clear in the beginning). I could go own but I don't really want to think about it right now . Despite my failure I managed to get some good critique about what I did wrong, which helped me learn quickly, and made me believe that even a week or two of help/training could have brought me up to their (enterprise-level) standards very quickly, but I was not given that opportunity. Inverness fucked around with this message at 16:26 on Jun 3, 2012 |
# ? Jun 3, 2012 16:23 |
|
I'd say that the interview project was unreasonably complex for something being done in an unfamiliar environment, with an unfamiliar PC, while being watched by other people. It would've been an okay "take-home" exercise.
|
# ? Jun 3, 2012 21:50 |
|
Ithaqua posted:I'd say that the interview project was unreasonably complex for something being done in an unfamiliar environment, with an unfamiliar PC, while being watched by other people. It would've been an okay "take-home" exercise. I did convince the interviewer to let me take it home (it helps that I actually work at the place in a different position, but wanted to move into software development), so I was able to work on it more. Since I actually had time then I was able to bring myself up to speed with the various things involved, but unfortunately I only built on and refined upon the design I already had instead of redoing it from scratch like I should have. When we met again, maintainability and MVC were two things he brought up that my design was really lacking (that he hadn't brought up previously, either). And since I only refined what I had already done, which was built on the get it working as fast as possible in that time limit, it didn't make the cut. It is disappointing, because while what I did was lacking for various reasons, I also know that I would have worked differently had I been working with an already existing codebase with clear standards to follow.
|
# ? Jun 3, 2012 22:07 |
|
Inverness posted:During the test I had to work on a laptop with a little touch pad thing because they didn't have any other computers available. I didn't enjoy that at all, but it wasn't too big of a deal. Did you write unit tests? Always write unit tests. If the company doesn't unit test, don't work for them.
|
# ? Jun 3, 2012 22:18 |
|
hobbesmaster posted:So what is your definition of a "very good justification"? If you're writing an application which, for what ever reason, needs to have a global state. Very few complex applications need a global state in reality and all it serves to do is make the application very hard to unit test and creates big performance bottlenecks etc etc. You can get away with it in the factory method pattern but elsewhere? It's questionable.
|
# ? Jun 6, 2012 11:38 |
|
I've done a lot of interviews and given a lot of interviews in my time, so I can perhaps give some insight into what people will look for. Expect to write code in your interview, it might not happen but it's becoming more and more common. Even something an simple as FizzBuzz in what ever language you're interviewing for, right up to a small app perhaps implementing an abstract class or something. These tests usually have a pretty tight time pressure which you might think is unfair, that's just kinda tough though as some people will be able to do it fine. Normally I would set the time limit to be about double what I would do it in myself. I usually just do something noddy, 20mins of work max. It might seem obvious but comment your code sample, don't use short hand not matter how common place you think it might be. Also don't do what you've not been asked for. I once asked for the FizzBuzz app in java to print out the numbers from 1 to 100, that is all. The guy spent the full time limit doing it and produced something which took 4 parameters, start, end, fizz number and buzz number. Now it was great and all that, but not what was asked for. Expect to at least know your UML at a basic a level. They might not be big on modelling but they might be and if you're shown a sequence diagram you need to know what you're looking at. With both of those, be adaptable. You might blank on the code section or just not be familiar enough with it to do it right in the time. In that case pseudo-code it in comments to show what you were trying to do at the very least. Most importantly be personable, they're interviewing you which means they probably think you're a good candidate. What they're looking for is people who have lied on their CV (see the programming tests) and people who can fit into a team. No one is going to hire the savant programmer who doesn't know what a shower or a sentence is. No one cares what your qualifications and experience are at that stage of the process, it's on your CV, so don't tell people over and over again, just chat and be yourself*. *Unless yourself is a horrible human being, in which case be someone else
|
# ? Jun 6, 2012 11:59 |
|
Ranma posted:Based purely on my own experience: Sort of old, but are front end web developers really in high demand? I had an absolute blast in my CSS and JavaScript classes.
|
# ? Jun 6, 2012 14:02 |
|
Shoeonhead22 posted:Sort of old, but are front end web developers really in high demand? I had an absolute blast in my CSS and JavaScript classes. Yes, front end is huge right now. JavaScript is a highly marketable skill as long as you actually can do it well. Note: I cannot do it well.
|
# ? Jun 6, 2012 15:57 |
|
Aramoro posted:I've done a lot of interviews and given a lot of interviews in my time, so I can perhaps give some insight into what people will look for. Why would you need to comment coding tests in an interview? You complain about the guy creating extraneous parameters but you want people to comment during an interview? That just seems superfluous. I mean you are the one asking the question so you know what it's suppose to do. And considering his code is just going to be tossed after the interview, what's the point? Also most of the people interviewing me are just told to interview me and are given my resume at the time of the interview, I've always been told to talk about my experiences or what I did at company X. Besides even if they have read your resume, they definitely care about your qualifications/experience. For example if they ask you a question which you can relate back to your experience. You're suppose to be promoting yourself so you should be telling people why you're qualified for the job. Obviously though don't repeat stuff over and over again.
|
# ? Jun 6, 2012 18:05 |
|
Strong Sauce posted:Why would you need to comment coding tests in an interview? You complain about the guy creating extraneous parameters but you want people to comment during an interview? That just seems superfluous. I mean you are the one asking the question so you know what it's suppose to do. And considering his code is just going to be tossed after the interview, what's the point? def tree_height(t): # base case: height of an empty tree is 0 if t is None: return 0 # recursive case: this tree's height is one higher than the tallest child return max(tree_height(t.left), tree_height(t.right)) which is handy because in this case notice I made a dumb coding error but at least then the interviewer can say "does the code match the comment, heh, oops!" as opposed to "well, *sigh*, let's see if you can spot the bug...". (Also, FWIW, while I certainly had my fare share of OO-gore questions, I never had to approach anything near UML. In fact I forgot that UML was a thing until it was mentioned a few posts back.)
|
# ? Jun 6, 2012 19:34 |
|
Here's where the difference comes in (in my opinion). When an interviewer tells you to implement fizz buzz as spitting out the sequence for 1 to 100, he wants you to follow that spec. You shouldn't deviate from it and your underlying implementation should be targeted at fulfilling the spec, not everything under the sun. Interviewers also want to know that you write good code. This means well commented, either through good comments or good variable/function/method names (or both!), and code that runs well and is accepted as good practice in that language. This last part could mean making sure you use correct method calls like each with a block in Ruby or making sure you have destructors in your C++ code. This also means you try and get the best algorithmic runtime, but you should have had that beat into your head by now. In short, meet the spec but do not purposefully exceed it and make sure your code is something they'd want in their codebase. EDIT: Like the guy above me says, use it to your advantage. By making a comment outline and filling it in, you know exactly what is left to fill and it can help with spotting errors. FamDav fucked around with this message at 00:10 on Jun 7, 2012 |
# ? Jun 7, 2012 00:07 |
|
|
# ? Apr 25, 2024 20:49 |
|
Strong Sauce posted:Why would you need to comment coding tests in an interview? You complain about the guy creating extraneous parameters but you want people to comment during an interview? That just seems superfluous. I mean you are the one asking the question so you know what it's suppose to do. And considering his code is just going to be tossed after the interview, what's the point? The point is showing you are a good coder, your going to produce code which is not only good but maintainable. If you have a choice between the guy who wrote some fairly mundane comments on a simple bit of code and the guy who didn't bother because it doesn't really matter then there's only one winner there. With the implimentation you have to follow the spec, by all means say how it can be improved but don't just do it because you thought it would be better. Strong Sauce posted:Also most of the people interviewing me are just told to interview me and are given my resume at the time of the interview, I've always been told to talk about my experiences or what I did at company X. I don't think I explained that well really. They care what your qualifications are and your experience obviously but they already know the facts. They don't want to know what you did but rather how you did it. You want to be talking about how you work, how you're great at being a programmer not just the bare facts of what you've done.
|
# ? Jun 7, 2012 00:30 |