30 ms·

I was interviewed recently. I was asked to implement a solution in Java. It was essentially a stack-based computation engine. The interviewer posed a question a

I was interviewed recently. I was asked to implement a solution in Java. It was essentially a stack-based computation engine. The interviewer posed a question and there were enough tacit hints for me to see what he really wanted: an "OO" approach using a type hierarchy + command pattern. He offered unsolicited prompts and I took them: I coupled the command objects to the engine. He liked that. What we ended up with was O(n) _classes_ (where n = the number of computation operations). I remained in Java, but took a functional and dynamic approach yielding a three-line implementation of the engine where each command was simply a function. All the tests passed. I was kind of holding my breath at this point. What will he say? We just went from this huge implementation to three lines. I thought he was going to love it. The crazy simplicity of it all. But to my draw-dropping surprise he muttered something about adding new types and how he liked that the commands were coupled to the engine. Is this complexity worship? Or what is this? It's almost as if his brain was refusing to see the solution. Like it couldn't possibly believe that the solution could be that simple. So it just ejected it, put a big black censorship block over it. I'm currently reading a book on brain hemispheres. Apparently experiments have shown that the left hemisphere will completely and blatantly reject obvious evidence even if the right hemisphere 'has a clear counter proof'. Sometimes I think our industry suffers from an abundance of left hemispheric dominance. Or something like this...

twtw 8y ago
> What we ended up with was O(n) _classes_ (where n = the number of computation operations). Speaking of complexity worship... Big O notation seems totally irrelevant here, unless the question involved scaling to arbitrary number of types of operations. Why not just say "we ended up with a class for every operation?"
- robotresearcher 8y ago
  Perhaps because they had a number of classes per operation, but that number was not important. Statements like this is what big-O is for.
- TeMPOraL 8y ago
  The use of that notation implies the number of classes was proportional to number of operations (+/- constant factor), not that it was equal to number of operations. O(n) works both if there's 1 class per operation, and if there's 5 classes per operation.
  - twtw 8y ago
    Ok. O(n) also through a away a lot of useful information. It seems simpler in every sense to just say "several classes for every operation."
    - TeMPOraL 8y ago
      Again, you're absolutely right wrt. proper, formal usage. But big-O is also a part of programmer slang now. The OP used it in this form. (It's also faster to write, or even say out loud, "O(n)", than it is to write/say "proportional to number of").
      - deleted 8y ago
        [deleted]
    - derefr 8y ago
      Frequently when writing O(n), the writer is making a comparison. e.g. "The GC was O(n log n) wrt memory, but now it's just O(log n)." That expands to a lot more text. Or, to put that another way: there is a constant cost in human parsing complexity when writing "O(n)", but the number of parse-nodes in the text when using "O(n)" only increases as O(n), whereas without "O(n)", it increases with O(n^1.3). ;)
- wellpast 8y ago
  Big-O applied to code artifacts-to-manage-over-time is very relevant here. If not the common usage of Big-O, which is in terms of algorithmic steps. But still highly relevant. A system that has O(n) code artifacts for n "business requirements" (e.g.) is far more costly than one that has O(1), say.
  - twtw 8y ago
    > A system that has O(n) code artifacts for n "business requirements" (e.g.) is far more costly than one that has O(1), say. I understand what you are saying, I'm just objecting to how you are saying it. Unless you are interested in the limiting behavior as the number of "business requirements" goes to infinity, big O is the wrong tool. An O(1) approach that requires a foundation of 1M LOC is probably worse than an O(n) approach that requires 100 LOC per business requirement. Sorry to obsess over the details here - I just think big O is overused in general and saw an opportunity to make a bad pun on complexity worship.
    - TeMPOraL 8y ago
      "Big O" has evolved beyond its original intended usage. In informal and semi-formal setting, it just means "roughy proportional to". It's showcasing the first-order shape of growth, not just inviting to do analysis in the limit. I.e. it's coder slang now.
      - twtw 8y ago
        I understand and I'm well aware that it has become "coder slang" - that's my point. On a thread about complexity worship, the first comment I saw was an unnecessary use of jargon that complicates things without new meaning. That, in my mind, results from a culture of complexity worship. > Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent. - orwell
        TeMPOraL 8y ago
        I think the slang version of "big O" is so common that there's no chance of misunderstanding. If anything, it serves as more of a shibboleth - if you don't get it, you're not part of the group the story is intended for. RE that Orwell quote, I have mixed feelings. I agree with it in so far as it means "pick easiest words for your audience at the precision level you need". But in general, words are not equivalents, even if they're listed as synonyms - each word has its own specific connotation. Say, "car" and "automobile". Technically, they refer to the same thing, but they feel different. That subtle emotional difference may not be important in formal setting, but it's an extra dimension of communication in informal cases (like e.g. this comment thread).
jcelerier 8y ago
> I remained in Java, but took a functional and dynamic approach yielding a three-line implementation of the engine where each command was simply a function. okay, so what do I do when I need to dynamically load an additional command by name from an external .jar ? that's like, the most basic thing Java was meant for.
- TeMPOraL 8y ago
  This should be in requirements. It apparently wasn't in the ones OP was given. Also, the answer should not be "large dependency injection framework".
  - wellpast 8y ago
    Also I would say the answer is better left independent of the runtime environment. Yes you can load Java classes into the JVM. But why not have a serialization format that is independent of the vagaries and specifities of the JVM? Still, even if you lean on the JVM, that changes nothing about this particular problem. You don't need command pattern. You don't need a type hierarchy.
- emsy 8y ago
  The author describes a YAGNI approach. The interviewer and you seem to want a solution that's already generalized and future proof. YAGNI is always the right approach to take at the beginning of a problem. But that's one of the insights that often come with programming experience and reflection. Unfortunately, seniority is an unreliable indicator for either attribute.
  - tabtab 8y ago
    Perhaps one should ask the interviewer whether they want a YAGNI-style solution or a more general/abstract solution. If you can give both, you may really impress the interviewer. Asking first to understand the needs and intention of the application should be a first step anyhow. Diving into the deep-end face first and coding is rarely the correct approach (except maybe a startup racing for market-share).
bena 8y ago
Don't over-complicate the reason. ;) It's quite possible he was trying to test something else and the answer you gave didn't give him a meaningful answer to that question. So while your solution may have been fine, it's not something you're going to run into in production code. But that hierarchy+command pattern is probably used in a more appropriate situation. And he wanted to see if you could deal with the pattern itself. Of course, I could be wrong. He could just be enamored with the overly complex solution because it's more "clever". Interviews are weird.
- wellpast 8y ago
  To be fair, I "passed" the interview. So he got what he was looking for. I argue however that he was preferring complexity over simplicity anyway.
wwweston 8y ago
Is that the correct hemisphere association? I have a vague idea it'd be the other way around (left has clear proof, right rejects). And what's the book? I've noticed in myself a tendency towards programming "aesthetics" that just "feel" right. Sometimes that intuition seems to overlap with faculties that help avoid complexity and find elegant solutions... but there's also plenty of times when it's either habit based in a collection of odd assumptions or even apparently arbitrary, and so it's something I've been working to interrogate. OO approaches specifically have something like three decades of pop-tech discussion as being professional and sophisticated. That's a kind of conditioning that's hard to overcome.
- wellpast 8y ago
  Yes I referred to the correct hemisphere. The right hemisphere is visuospatial. Also, the right hemisphere 'sees' time/process. The left hemisphere puts together contextless symbolic model. So I see where your question comes from: the left hemisphere can do the contextless proofs. In this case (and in many cases) the more complex solution "works" and the left brain can "prove" it works. But a 'simplicity' proof seems better suited to the right hemisphere (I am no expert here, mind you) .... So in my anecdote the "simpler" solution is the one that I would guess the right brain "sees" as simpler: i.e., it is visually much smaller, also much easier to manipulate (over time), etc. The book is "The Master and His Emissary".
- charlixcx 8y ago
  The whole hemisphere theory is bshit. https://www.theguardian.com/commentisfree/2013/nov/16/left-right-brain-distinction-myth https://www.theguardian.com/commentisfree/2013/nov/16/left-r... You can find a lot of articles online. I don't know why people keep talking abt it.
sonnyblarney 8y ago
Hmmmm ... The point of a 'command pattern' is in effect it's generality, i.e. it implies less coupling in the scenario. The most classic example would be the 'action' that might be passed to a UI button when it's clicked. So, if the situation calls for command pattern, use it, if not, don't. It's not a matter of 'in your face complexity'. The notion of doing '3 things with 3 functions' is pedantic: it's obvious. It wouldn't make the basis of a 'question' so it'd be rather pointless to do it. Maybe there was some confusion as to the point of the question ...
- wellpast 8y ago
  You can slap "command pattern" on anything. But I'm speaking directly in the traditional form that implies a OO type hierarchy. You don't need that at all. Here is a "proof" of sorts: http://mishadoff.com/blog/clojure-design-patterns/#episode-1-command http://mishadoff.com/blog/clojure-design-patterns/#episode-1...
  - TeMPOraL 8y ago
    Yup. Command pattern is short for "my language doesn't have first-class closures".
  - sonnyblarney 8y ago
    I'm aware. But either it makes sense to use Command Pattern or not in any given situation and it has nothing to do with complexity really. I don't see how someone could possibly use a command pattern when simple function would do - that would be beyond pointless. Which makes me believe that there must have been something to the nature of the problem question ... (Though Lambda's wipe out so many of the simpler use cases of command pattern ...)
    - je42 8y ago
      i think even if you use lambda's - i would still call it a command pattern - if you used lambdas to implement the command class.
crimsonalucard 8y ago
A 3 line simple solution is obviously better than the original solution. He knows this, Anybody knows this. What happened was that you showed off how you're better than him at finding a better solution. He's probably a top dog looking for underlings. That's the reality of this world.
- wellpast 8y ago
  I can appreciate your somewhat cynical assessment, but I also think we're still squarely in the right/left brain hemisphere: empirically speaking, the left hemisphere has quite the ego. We're both saying a very similar thing.
exabrial 8y ago
I was asked in a Google interview to randomize a List. I wrote Collections.shuffle(list); The interviewer was not pleased.
- nambit 8y ago
  To be fair, using a library to do what you want is not what they're asking for. This is completely different from the functional vs OO discussion above.
  - exabrial 8y ago
    On the contrary, if someone that worked for me needed to randomize a List and implemented their own function, I would be gravely concerned about the rest of work and what they're spending their time on.
    - ummonk 8y ago
      And when Google implemented Java for Android, how, pray tell, should they have implemented Collections.shuffle?
      - uryga 8y ago
        Implementing a stdlib isn't a thing you do every day. Presumably GP was referring to more common situations, where using the stdlib is (usually) preferable to rolling your own solution.
        anyfoo 8y ago
        They were interviewing for Google. It's not uncommon to have to implement a standard library function (or not be able to use one) in many contexts at Google. Besides, the question is just the most basic setup to assess how a candidate would fare in comparable situations.
        8y ago
phaedrus 8y ago
A few years ago I needed an emulator for version N of a popular microcontroller. I found an emulator (written in Java) for version N-1 of the same microcontroller. It was written in the style you describe: one derived class per machine instruction type; program to run in emulation is a collection of these via their abstract base class. It was quite pleasant to extend, actually: I simply made classes for the new instructions available in the new version of the microcontroller, added instances of them to the giant table mapping codes to instruction objects, and It Just Worked. I do note that that is an atypical experience to extending programs in general, and I don't have the alternate, functional approach to compare it to (the emulator was written in a very old version of Java + Swing).
- TeMPOraL 8y ago
  In functional style, you'd probably have a table mapping machine instruction type to a function. These days, even Java (since version 8) supports that, and it roughly compiles down to the same thing (due to how Java implements lambdas). This case sounds simple, but I still expect the functional approach to save you from a lot of line noise coming from Java class bureaucracy. But in more complex cases, it may be a difference between a couple dozen lines and a couple dozen files.
  - phaedrus 8y ago
    On the other hand, the OOP approach allows you to add printing the function name (for disassembly views), metadata attributes about what flags are affected, clock cycles, etc. You could argue that each of those could be separate tables. Funny how it comes back to the array-of-structs vs struct-of-arrays design question, or maybe I'm just seeing that everywhere because of thinking about Mike Acton's Data Oriented Programming talk.
    - iLemming 8y ago
      Clojure. Clojure is extremely data oriented.
      - 8y ago
ummonk 8y ago
This sounds like a good example of everything wrong with the cult of Java programming / design patterns.
- tralarpa 8y ago
  Does it? The class-based solution looks very convenient to me for large projects. Let's say I am new to the project and I don't know what commands exist. I just ask the IDE to show me all sub classes of the command super class. That sounds much better than searching the functions implementing the different operations everywhere in the source code. Not everything that is easier to write is easier to read two years later (even if it has much less lines).
  - TeMPOraL 8y ago
    Unless there's some magic involved (like pulling code from strings at runtime, via reflection), you'll have a place in which all those functions show up together. A central table, a switch statement in a factory method, or something. You'll have it in either the class-based or function-based implementation.
    - tralarpa 8y ago
      > you'll have a place in which all those functions show up I don't see why. For example, imagine a graphical editor. GUI events will trigger some actions and those actions will trigger some commands being execute (and placed in an undo buffer etc.). I don't see where that central place should be and why you would need it at all. And now imagine a large project with different ways to execute commands ("execute", "executeWithUndo", "executeInTransaction",...), people composing new commands from existing ones, etc. Soon grep becomes your best friend. Or just press Ctrl-H or whatever in your favorite Java IDE to see the class hierarchy.
      - TeMPOraL 8y ago
        > and why you would need it at all. Because in the functional model, you're not abusing the filesystem or inheritance hierarchy to do your bookkeeping. Also, I said functions, not necessarily anonymous ones. There are ways to solve this use case. You can stash your actions as named public static functions in a "Commands" class. Or you can create one dummy class with @Functional on its only method, that essentially forwards the call. So in your UI handlers, you do button.setOnAction(new Command(someFunctionSomewhere));, instead of having a separate class for every possible action. You can now find all actions by looking up calls to Command c-tor(s), and you can build subtypes of Command as you need some special functionality. Note that this way, you don't commit yourself early to a huge type hierarchy. In my experience, even in large projects, Command objects tend to sit in the filesystem, wasting space and people's time. But if you're absolutely sure you'll need this pattern, then go ahead and use it. It just shouldn't be the default, go-to way of solving this problem.
phkahler 8y ago
When I was in college one of the candidates for some open position in the engineering school gave an open talk which I attended. He had this whole thing where he researched the right/left brain tendencies of engineering students. He actually had two axis on his pictures but I don't recall what the other axis was so lets keep to the the left/right (logical/creative) axis. He said most students entering engineering were more left brained. He also said retesting people exiting engineering has shifted. Not that the right brains dropped out, but that the same students tested more to the left after an engineering education. It wasn't clear if that was a shift in thinking or just improving ones skills at a particular way of thinking. In other words, no evidence of any loss just a shift in score on a right/left test. The other notable thing he said is that the right brained people who complete an engineering degree were rather likely to spend some time working in the field and then just change to something completely different. I remember this well because I tested as a dominant right-brain thinker and have always had this odd feeling that I might want to just stop and do something completely different. Fortunately I've been able to find ways to use creativity in engineering :-)
- Finch2193 8y ago
  Is there really such a thing as left or right brained? Here's [1] an article discussing this. In this talk, what defined a person as "left brained" or "right brained" 1: https://www.health.harvard.edu/blog/right-brainleft-brain-right-2017082512222 https://www.health.harvard.edu/blog/right-brainleft-brain-ri...
  - rabidrat 8y ago
    Such a left-brained thing to say :)
  - otabdeveloper2 8y ago
    > Is there really such a thing as left or right brained? Yes, there really is, but the way it's described in American media is a load of crap. I don't think anybody published actual real science about this in English.
- otabdeveloper2 8y ago
torbjorn 8y ago
Are you by chance reading "The Master and His Emissary"?
- wellpast 8y ago
  Yes that’s the book!
Apaec 8y ago
What that kind of people need to understand is that "code is a liability, not an asset". Every piece of adhoc code is added maintenance cost, hence the less code the better, no matter the programming language or paradigm.
- samontar 8y ago
  That’s what I feel too. It’s like in The Goal by Eli Goldratt. The machinery of building product is all cost. Inventory is cost. Machinery is cost. Only finished sold product is revenue. Analogously, code is cost, infra is cost, only our sold product is revenue. A thing I did not understand for a long time is the effect this has on value. Something that produces a low value over a long time may well have been value-negative over the period because of the hidden carrying cost.
- plopilop 8y ago
  I overall agree but I'd like to add some nuance: one-liners are hella compact but no way near maintainable in many cases. For instance 100% of code golf competition results should never be allowed in production. Also there may be a balance between "some hierarchy in the code so it can evolve" and adhoc code that just works for the current problem. Only having to write a new class for a new feature because everything else is handed smoothly is a bliss.
  - bal00ns 8y ago
    I have to agree with this comment. More often than not one-liner rewrites of even trivial functions are unreadable and can't easily be modified, all for the sake of having the appearance of elegance. It's more important to have code that is easily understandable and extendable, which isn't always the case with fewer lines of code. For example I could write a massive list comprehension in Python in one line that could solve my problem, but it would be much more difficult to read and would be a pain to modify. I'd much rather work with the 10 lines of code it would take to actually spell it out.
  - Apaec 8y ago
    Wanted to state the main idea first. I definitely agree about one-liners, Perl and APL come to mind. There are some other aspects to this idea of code economy: correctness and reusability. This definitely depends on the programming language. In Java(or oop for that matter) you can get correctness but to get reusability you need a whole hierarchy of classes, lots of added code/cost. In Python you get more reusability out of the box but to get correctness you need to add swaths of unit tests, lots of cost. In contrast with a functional language such as Haskell you get both with less effort, fp plus a rich type system reduce code enourmosly.
zmmmmm 8y ago
Very likely the interviewer was posing to you the exact design that they have already implemented, which they did for good reasons, and very likely your trivial solution would not scale up to the complexity of their needs. So you might have proved you could simplify the problem at hand but failed to demonstrate that you would know how to deal with more complex requirements of a larger system. For example if the commands themselves are quite complicated and have their own relationships and state then how would that be modeled? Eg. how do commands with shared behavior share it? Of course it can all be done in a functional style if you are determined enough, but it could be somewhat awkward and sounds like it wouldn't fit at all with their style of programming. I assume you probably didn't want the job in the end but if you did I would say you didn't do yourself any favors.
choot 8y ago
One of my friend who was not so strong in programming was never short of any jobs that were available to him. He told me he took a ukulele to the interview. Each time when interviewer asked him a question, he would play ukulele untill he found the answer. He got the job even when his interviews went wrong. His job offer arrived months after an interview because he was the only guy who the interviewer could remember. Often you hire for a spot in a company, after sometime that person leaves and management asks you to name any other person and when you try to recall last interviewee batch, the ukulele guy is only one the interviewer is able to remember.
- Unknoob 8y ago
  Your friend is a mad genius. That's so brilliantly absurd but aligns so well with my experience in interviews that I can't dispute it.
- mercer 8y ago
  That's awesome, and there must be more stories you can tell about this guy. If so, do tell!
- heavenlyblue 8y ago
  I've spent a fair amount of time interviewing in London a few years ago. I would literally go to any company that send me an e-mail or contacted me via recruiters. I didn't have enough money to buy new clothes at the time, so instead I've picked the shoes with the largest amount of holes and would never do any grooming before hands. I would come stoned to the interview. So the gist: instead of trying to appear on the lower mid end, I went all the way through to the lowest low end. Thinking retrospectively I think that's pretty much the reason why I barely received any negative responses unless I had miserably failed at the technical side of things (e.g. I didn't know how to use generators in Python at the time and the whole list of questions would be about them and their syntax). I have to admit that in this scenario I was quite good at the technical side of things. But the general philosophy was that if I don't try to appear too good - people will assume that I was better. Put humility and definite sprinkle of character on top of that.
gaius 8y ago
I'm currently reading a book on brain hemispheres. Apparently experiments have shown that the left hemisphere will completely and blatantly reject obvious evidence even if the right hemisphere 'has a clear counter proof'. Sometimes I think our industry suffers from an abundance of left hemispheric dominance. I have two monitors on my desk. If I am stuck on anything I drag my emacs from one side to the other and look at the same code there. It works pretty well!
dave_sid 8y ago
I think I can explain this. At some point in the past the interviewer has had to get to grips with OO programming. This isn’t easily for everyone, myself included. But eventually it all clicks. And it’s a great thing. Then you start learning about design patterns. You struggle to get to grips with these, you try to memorise them, you don’t quite feel comfortable with them; but one day, it all clicks. And they are great. And you feel a massive sense of accomplishment. In software development, everything moves so fast, but the feeling that you have actually learned something that is almost timeless and will outlast languages and frameworks that come and go every week is a rare feeling. And I really feel that knowledge is priceless. Try then telling them not to bother with all that and write 3 lines of code :-D If someone has invested a lot of time trying to understand OO and design patterns like this, and had the feeling of accomplishment when it all comes together, then the are going to want to apply them where they can. I think all that stuff is invaluable knowledge but people shouldn’t fall into the trap of doing something one way just because they have invested the most time in learning how to do it that way. Also, many software professionals probably find simplicity boring. Simplicity should be taken more seriously as a goal in software development. Sigh.
- ripsawridge 8y ago
  Wonderful insight!
Annatar 8y ago
Your situation was a perfect example of why I so violently, vehemently oppose object oriented programming and why I fight the people trying to promote it at every turn and opportunity (often in person and it can get extremely ugly -- and that is good so). Object oriented code is a nightmare to debug -- I've wasted countless years stepping through the debugger trying to follow the complex state machines I was debugging. Data hiding, one of the main selling points of this programming technique, makes it even worse with regard to building a mental model of the state of the machine. Resolving what the data is in order to understand where the problem resides ends up being extremely tedious and painful. It's like they are trying to prove that they are really, really smart without anyone asking them to prove it. But here is my challenge: anyone can overcomplicate anything, but if one is really smart, make a complex thing simple.
- charlixcx 8y ago
  Jesus christ get some chill. sometimes it works, there's no perfect paradigm.
ensiferum 8y ago
You forgot some Factories and Factory Factories ;-)
netcan 8y ago
There might be some sort of cognitive bias going on here. But, I think the greater driver is more "political." Complexity creates opportunities for fiefs, little areas only one person understands. I think we don't recognize what drives a good portion of people, in the tech industry. People pretend to, and are often expected to understand more than they do. Complexity helps us when reporting or manage (up and down). It's harder to grill you, challenge you or commit you to things when everything is complex. Complex requires more people, which is the main scorecard for corporate success. It's also just unintuitive that simple is harder and better than complicated. Even if you get it, someone else won't.
- darkerside 8y ago
  And those little fiefdoms, well maintained, can be easy domains to control and reshape according to the needs of relevant stakeholders. Whereas an over simple solution can end up doing one job well but too difficult to modify or extend without rather rewriting it. Depends on the problem you're solving.
- i_made_a_booboo 8y ago
  What led you to this conclusion? I've come to the same one. I think it explains a great deal of what we see. Even in the hiring process and such. It's actually very primitive at its core. Who's part of who's tribe and who is jockeying for status in that tribe.
DanielBMarkham 8y ago
I had a job working for a large Canadian company several years ago. Coming in, I was told that the specs were difficult, the tech had to be nailed, and they had already tried and failed. I took a week getting used to the customer, stack, and team. Digging through what they had? They needed two lines of code. It was the same exact situation. That was one of the more difficult consulting assignments I had. It took me quite a while to gently get the lead architect on-board. I had to position it so it looked like his idea. If I would have pushed hard, he would have pushed back...perhaps getting rid of me and hiring more of a team player. I've seen this a lot, in a lot of teams, and I think it has its roots in OO/Platonism, although it happens all over. I think the key things most of these teams are missing is that all structure is derivative. That is, there's not a line of code that's in your app that isn't in there for a reason. You're either really careful about that reason....or you add stuff because it looks good or you might need it someday, you can "imagine" how it might be helpful, the guy sitting next to you said you had to have it, and so on.
brightball 8y ago
The longer I've been in programming, the more I've noticed just how much people defend "their way" of solving a problem. If you do it differently or with a different language, there must be some negativity to latch onto in order to justify the way they did it. The simple ability to say "Oh...cool! Hey Bob, come look at what Jim figured out!" is a rare find.
dkarl 8y ago
I had a similar but inverted interview experience years ago. The interviewer asked me how I would implement a system for selling concert tickets online. I suspected, and quickly confirmed, that he wasn't interested in the UI, just the back end systems for supporting the UI. I quickly sketched out a system and described how I would serve up information about the available concerts and tickets and implement the process of buying a ticket. Then I asked the interviewer if he wanted me to go into more detail on any particular component of the system. He was NOT pleased. Then began a long process of "don't you think that's unnecessary?" and "what in the world is this for?" As I explained the need for each part of the system, he started incrementally removing all the requirements implicit in his description of the problem. First to go was the distinction between accessible and non-accessible seating, partially obscured views, basically any extra info about seats except their identity. Okay, great, that simplifies things. Likewise any idea of redundancy or failover. "Just let the process restart. You should be able to ensure no failures anyway." Okay, that's kind of opposite to how I've thought in the past, but I'll keep my mouth shut and roll with it. Just to check, I asked if I should support a concept of buying tickets for assigned seats. Nope, no assigned seating. Okay... so are there different price classes for each event? "No, the tickets are all the same!" Okay. Each event has a single price and a single pool of tickets. But to sell the ticket the user has to be able to buy it, right? Nope. No payment process. Great! I said. So there's no need to put a hold on a ticket while the user has it in his cart. The interviewer looked like he was going to burst a blood vessel. Then I said, okay, at minimum I think we need to record who we've sold tickets to so we can send them tickets or in some way ensure that the right people can be let into the concert and people who haven't bought tickets can be turned away. Um... right? "No, don't bother. If they say they bought a ticket, they did." Okay. Moving on. You wouldn't think the requirements could get much simpler than that, but you would be wrong. It turns out that the system didn't need to know when a concert was happening so it could stop selling tickets at some point. Ticket sales for a concert would go on forever. What should I do if the concert sells out? "Don't worry about that. It won't happen." At this point, I wanted to scream, "Your honor, permission to treat the witness as hostile!" It also turned out there was no need to track different events or venues. There's only one concert, it has an unlimited capacity, and it never happens. In the end it emerged that he just wanted a simple TCP service that listened on a port and served a random long integer (a "ticket") to anyone who connected without repeating the same value, unless it got rebooted, in which case it was okay to potentially serve some of the same numbers that it served during its last lifetime, as long as it didn't exhibit any patterns that might enable an attacker to predict upcoming values. What #%$%ing similarity does that have to selling concert tickets? I mean, in the phrase "sell" "concert" "tickets" "online" three out of the four words were completely irrelevant and misleading. I'm guessing it was just what he was working on that week, and in his system the values were called "tickets" so he threw out "let's sell concert tickets" in an interview hoping I would solve his problem for him. We were out of time, so we didn't have time to discuss it. I didn't get an offer and wouldn't have accepted one.

twtw 8y ago

> What we ended up with was O(n) _classes_ (where n = the number of computation operations). Speaking of complexity worship... Big O notation seems totally irrelevant here, unless the question involved scaling to arbitrary number of types of operations. Why not just say "we ended up with a class for every operation?"

robotresearcher 8y ago
Perhaps because they had a number of classes per operation, but that number was not important. Statements like this is what big-O is for.
TeMPOraL 8y ago
The use of that notation implies the number of classes was proportional to number of operations (+/- constant factor), not that it was equal to number of operations. O(n) works both if there's 1 class per operation, and if there's 5 classes per operation.
- twtw 8y ago
  Ok. O(n) also through a away a lot of useful information. It seems simpler in every sense to just say "several classes for every operation."
  - TeMPOraL 8y ago
    Again, you're absolutely right wrt. proper, formal usage. But big-O is also a part of programmer slang now. The OP used it in this form. (It's also faster to write, or even say out loud, "O(n)", than it is to write/say "proportional to number of").
    - deleted 8y ago
      [deleted]
  - derefr 8y ago
    Frequently when writing O(n), the writer is making a comparison. e.g. "The GC was O(n log n) wrt memory, but now it's just O(log n)." That expands to a lot more text. Or, to put that another way: there is a constant cost in human parsing complexity when writing "O(n)", but the number of parse-nodes in the text when using "O(n)" only increases as O(n), whereas without "O(n)", it increases with O(n^1.3). ;)
wellpast 8y ago
Big-O applied to code artifacts-to-manage-over-time is very relevant here. If not the common usage of Big-O, which is in terms of algorithmic steps. But still highly relevant. A system that has O(n) code artifacts for n "business requirements" (e.g.) is far more costly than one that has O(1), say.
- twtw 8y ago
  > A system that has O(n) code artifacts for n "business requirements" (e.g.) is far more costly than one that has O(1), say. I understand what you are saying, I'm just objecting to how you are saying it. Unless you are interested in the limiting behavior as the number of "business requirements" goes to infinity, big O is the wrong tool. An O(1) approach that requires a foundation of 1M LOC is probably worse than an O(n) approach that requires 100 LOC per business requirement. Sorry to obsess over the details here - I just think big O is overused in general and saw an opportunity to make a bad pun on complexity worship.
  - TeMPOraL 8y ago
    "Big O" has evolved beyond its original intended usage. In informal and semi-formal setting, it just means "roughy proportional to". It's showcasing the first-order shape of growth, not just inviting to do analysis in the limit. I.e. it's coder slang now.
    - twtw 8y ago
      I understand and I'm well aware that it has become "coder slang" - that's my point. On a thread about complexity worship, the first comment I saw was an unnecessary use of jargon that complicates things without new meaning. That, in my mind, results from a culture of complexity worship. > Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent. - orwell
      - TeMPOraL 8y ago
        I think the slang version of "big O" is so common that there's no chance of misunderstanding. If anything, it serves as more of a shibboleth - if you don't get it, you're not part of the group the story is intended for. RE that Orwell quote, I have mixed feelings. I agree with it in so far as it means "pick easiest words for your audience at the precision level you need". But in general, words are not equivalents, even if they're listed as synonyms - each word has its own specific connotation. Say, "car" and "automobile". Technically, they refer to the same thing, but they feel different. That subtle emotional difference may not be important in formal setting, but it's an extra dimension of communication in informal cases (like e.g. this comment thread).

jcelerier 8y ago

> I remained in Java, but took a functional and dynamic approach yielding a three-line implementation of the engine where each command was simply a function. okay, so what do I do when I need to dynamically load an additional command by name from an external .jar ? that's like, the most basic thing Java was meant for.

TeMPOraL 8y ago
This should be in requirements. It apparently wasn't in the ones OP was given. Also, the answer should not be "large dependency injection framework".
- wellpast 8y ago
  Also I would say the answer is better left independent of the runtime environment. Yes you can load Java classes into the JVM. But why not have a serialization format that is independent of the vagaries and specifities of the JVM? Still, even if you lean on the JVM, that changes nothing about this particular problem. You don't need command pattern. You don't need a type hierarchy.
emsy 8y ago
The author describes a YAGNI approach. The interviewer and you seem to want a solution that's already generalized and future proof. YAGNI is always the right approach to take at the beginning of a problem. But that's one of the insights that often come with programming experience and reflection. Unfortunately, seniority is an unreliable indicator for either attribute.
- tabtab 8y ago
  Perhaps one should ask the interviewer whether they want a YAGNI-style solution or a more general/abstract solution. If you can give both, you may really impress the interviewer. Asking first to understand the needs and intention of the application should be a first step anyhow. Diving into the deep-end face first and coding is rarely the correct approach (except maybe a startup racing for market-share).

bena 8y ago

Don't over-complicate the reason. ;) It's quite possible he was trying to test something else and the answer you gave didn't give him a meaningful answer to that question. So while your solution may have been fine, it's not something you're going to run into in production code. But that hierarchy+command pattern is probably used in a more appropriate situation. And he wanted to see if you could deal with the pattern itself. Of course, I could be wrong. He could just be enamored with the overly complex solution because it's more "clever". Interviews are weird.

wellpast 8y ago
To be fair, I "passed" the interview. So he got what he was looking for. I argue however that he was preferring complexity over simplicity anyway.

wwweston 8y ago

Is that the correct hemisphere association? I have a vague idea it'd be the other way around (left has clear proof, right rejects). And what's the book? I've noticed in myself a tendency towards programming "aesthetics" that just "feel" right. Sometimes that intuition seems to overlap with faculties that help avoid complexity and find elegant solutions... but there's also plenty of times when it's either habit based in a collection of odd assumptions or even apparently arbitrary, and so it's something I've been working to interrogate. OO approaches specifically have something like three decades of pop-tech discussion as being professional and sophisticated. That's a kind of conditioning that's hard to overcome.

wellpast 8y ago
Yes I referred to the correct hemisphere. The right hemisphere is visuospatial. Also, the right hemisphere 'sees' time/process. The left hemisphere puts together contextless symbolic model. So I see where your question comes from: the left hemisphere can do the contextless proofs. In this case (and in many cases) the more complex solution "works" and the left brain can "prove" it works. But a 'simplicity' proof seems better suited to the right hemisphere (I am no expert here, mind you) .... So in my anecdote the "simpler" solution is the one that I would guess the right brain "sees" as simpler: i.e., it is visually much smaller, also much easier to manipulate (over time), etc. The book is "The Master and His Emissary".
charlixcx 8y ago
The whole hemisphere theory is bshit. https://www.theguardian.com/commentisfree/2013/nov/16/left-right-brain-distinction-myth https://www.theguardian.com/commentisfree/2013/nov/16/left-r... You can find a lot of articles online. I don't know why people keep talking abt it.

sonnyblarney 8y ago

Hmmmm ... The point of a 'command pattern' is in effect it's generality, i.e. it implies less coupling in the scenario. The most classic example would be the 'action' that might be passed to a UI button when it's clicked. So, if the situation calls for command pattern, use it, if not, don't. It's not a matter of 'in your face complexity'. The notion of doing '3 things with 3 functions' is pedantic: it's obvious. It wouldn't make the basis of a 'question' so it'd be rather pointless to do it. Maybe there was some confusion as to the point of the question ...

wellpast 8y ago
You can slap "command pattern" on anything. But I'm speaking directly in the traditional form that implies a OO type hierarchy. You don't need that at all. Here is a "proof" of sorts: http://mishadoff.com/blog/clojure-design-patterns/#episode-1-command http://mishadoff.com/blog/clojure-design-patterns/#episode-1...
- TeMPOraL 8y ago
  Yup. Command pattern is short for "my language doesn't have first-class closures".
- sonnyblarney 8y ago
  I'm aware. But either it makes sense to use Command Pattern or not in any given situation and it has nothing to do with complexity really. I don't see how someone could possibly use a command pattern when simple function would do - that would be beyond pointless. Which makes me believe that there must have been something to the nature of the problem question ... (Though Lambda's wipe out so many of the simpler use cases of command pattern ...)
  - je42 8y ago
    i think even if you use lambda's - i would still call it a command pattern - if you used lambdas to implement the command class.

crimsonalucard 8y ago

A 3 line simple solution is obviously better than the original solution. He knows this, Anybody knows this. What happened was that you showed off how you're better than him at finding a better solution. He's probably a top dog looking for underlings. That's the reality of this world.

wellpast 8y ago
I can appreciate your somewhat cynical assessment, but I also think we're still squarely in the right/left brain hemisphere: empirically speaking, the left hemisphere has quite the ego. We're both saying a very similar thing.

exabrial 8y ago

I was asked in a Google interview to randomize a List. I wrote Collections.shuffle(list); The interviewer was not pleased.

nambit 8y ago
To be fair, using a library to do what you want is not what they're asking for. This is completely different from the functional vs OO discussion above.
- exabrial 8y ago
  On the contrary, if someone that worked for me needed to randomize a List and implemented their own function, I would be gravely concerned about the rest of work and what they're spending their time on.
  - ummonk 8y ago
    And when Google implemented Java for Android, how, pray tell, should they have implemented Collections.shuffle?
    - uryga 8y ago
      Implementing a stdlib isn't a thing you do every day. Presumably GP was referring to more common situations, where using the stdlib is (usually) preferable to rolling your own solution.
      - anyfoo 8y ago
        They were interviewing for Google. It's not uncommon to have to implement a standard library function (or not be able to use one) in many contexts at Google. Besides, the question is just the most basic setup to assess how a candidate would fare in comparable situations.
        8y ago

phaedrus 8y ago

A few years ago I needed an emulator for version N of a popular microcontroller. I found an emulator (written in Java) for version N-1 of the same microcontroller. It was written in the style you describe: one derived class per machine instruction type; program to run in emulation is a collection of these via their abstract base class. It was quite pleasant to extend, actually: I simply made classes for the new instructions available in the new version of the microcontroller, added instances of them to the giant table mapping codes to instruction objects, and It Just Worked. I do note that that is an atypical experience to extending programs in general, and I don't have the alternate, functional approach to compare it to (the emulator was written in a very old version of Java + Swing).

TeMPOraL 8y ago
In functional style, you'd probably have a table mapping machine instruction type to a function. These days, even Java (since version 8) supports that, and it roughly compiles down to the same thing (due to how Java implements lambdas). This case sounds simple, but I still expect the functional approach to save you from a lot of line noise coming from Java class bureaucracy. But in more complex cases, it may be a difference between a couple dozen lines and a couple dozen files.
- phaedrus 8y ago
  On the other hand, the OOP approach allows you to add printing the function name (for disassembly views), metadata attributes about what flags are affected, clock cycles, etc. You could argue that each of those could be separate tables. Funny how it comes back to the array-of-structs vs struct-of-arrays design question, or maybe I'm just seeing that everywhere because of thinking about Mike Acton's Data Oriented Programming talk.
  - iLemming 8y ago
    Clojure. Clojure is extremely data oriented.
    - 8y ago

ummonk 8y ago

This sounds like a good example of everything wrong with the cult of Java programming / design patterns.

tralarpa 8y ago
Does it? The class-based solution looks very convenient to me for large projects. Let's say I am new to the project and I don't know what commands exist. I just ask the IDE to show me all sub classes of the command super class. That sounds much better than searching the functions implementing the different operations everywhere in the source code. Not everything that is easier to write is easier to read two years later (even if it has much less lines).
- TeMPOraL 8y ago
  Unless there's some magic involved (like pulling code from strings at runtime, via reflection), you'll have a place in which all those functions show up together. A central table, a switch statement in a factory method, or something. You'll have it in either the class-based or function-based implementation.
  - tralarpa 8y ago
    > you'll have a place in which all those functions show up I don't see why. For example, imagine a graphical editor. GUI events will trigger some actions and those actions will trigger some commands being execute (and placed in an undo buffer etc.). I don't see where that central place should be and why you would need it at all. And now imagine a large project with different ways to execute commands ("execute", "executeWithUndo", "executeInTransaction",...), people composing new commands from existing ones, etc. Soon grep becomes your best friend. Or just press Ctrl-H or whatever in your favorite Java IDE to see the class hierarchy.
    - TeMPOraL 8y ago
      > and why you would need it at all. Because in the functional model, you're not abusing the filesystem or inheritance hierarchy to do your bookkeeping. Also, I said functions, not necessarily anonymous ones. There are ways to solve this use case. You can stash your actions as named public static functions in a "Commands" class. Or you can create one dummy class with @Functional on its only method, that essentially forwards the call. So in your UI handlers, you do button.setOnAction(new Command(someFunctionSomewhere));, instead of having a separate class for every possible action. You can now find all actions by looking up calls to Command c-tor(s), and you can build subtypes of Command as you need some special functionality. Note that this way, you don't commit yourself early to a huge type hierarchy. In my experience, even in large projects, Command objects tend to sit in the filesystem, wasting space and people's time. But if you're absolutely sure you'll need this pattern, then go ahead and use it. It just shouldn't be the default, go-to way of solving this problem.

phkahler 8y ago

When I was in college one of the candidates for some open position in the engineering school gave an open talk which I attended. He had this whole thing where he researched the right/left brain tendencies of engineering students. He actually had two axis on his pictures but I don't recall what the other axis was so lets keep to the the left/right (logical/creative) axis. He said most students entering engineering were more left brained. He also said retesting people exiting engineering has shifted. Not that the right brains dropped out, but that the same students tested more to the left after an engineering education. It wasn't clear if that was a shift in thinking or just improving ones skills at a particular way of thinking. In other words, no evidence of any loss just a shift in score on a right/left test. The other notable thing he said is that the right brained people who complete an engineering degree were rather likely to spend some time working in the field and then just change to something completely different. I remember this well because I tested as a dominant right-brain thinker and have always had this odd feeling that I might want to just stop and do something completely different. Fortunately I've been able to find ways to use creativity in engineering :-)

Finch2193 8y ago
Is there really such a thing as left or right brained? Here's [1] an article discussing this. In this talk, what defined a person as "left brained" or "right brained" 1: https://www.health.harvard.edu/blog/right-brainleft-brain-right-2017082512222 https://www.health.harvard.edu/blog/right-brainleft-brain-ri...
- rabidrat 8y ago
  Such a left-brained thing to say :)
- otabdeveloper2 8y ago
  > Is there really such a thing as left or right brained? Yes, there really is, but the way it's described in American media is a load of crap. I don't think anybody published actual real science about this in English.
otabdeveloper2 8y ago

torbjorn 8y ago

Are you by chance reading "The Master and His Emissary"?

wellpast 8y ago
Yes that’s the book!

Apaec 8y ago

What that kind of people need to understand is that "code is a liability, not an asset". Every piece of adhoc code is added maintenance cost, hence the less code the better, no matter the programming language or paradigm.

samontar 8y ago
That’s what I feel too. It’s like in The Goal by Eli Goldratt. The machinery of building product is all cost. Inventory is cost. Machinery is cost. Only finished sold product is revenue. Analogously, code is cost, infra is cost, only our sold product is revenue. A thing I did not understand for a long time is the effect this has on value. Something that produces a low value over a long time may well have been value-negative over the period because of the hidden carrying cost.
plopilop 8y ago
I overall agree but I'd like to add some nuance: one-liners are hella compact but no way near maintainable in many cases. For instance 100% of code golf competition results should never be allowed in production. Also there may be a balance between "some hierarchy in the code so it can evolve" and adhoc code that just works for the current problem. Only having to write a new class for a new feature because everything else is handed smoothly is a bliss.
- bal00ns 8y ago
  I have to agree with this comment. More often than not one-liner rewrites of even trivial functions are unreadable and can't easily be modified, all for the sake of having the appearance of elegance. It's more important to have code that is easily understandable and extendable, which isn't always the case with fewer lines of code. For example I could write a massive list comprehension in Python in one line that could solve my problem, but it would be much more difficult to read and would be a pain to modify. I'd much rather work with the 10 lines of code it would take to actually spell it out.
- Apaec 8y ago
  Wanted to state the main idea first. I definitely agree about one-liners, Perl and APL come to mind. There are some other aspects to this idea of code economy: correctness and reusability. This definitely depends on the programming language. In Java(or oop for that matter) you can get correctness but to get reusability you need a whole hierarchy of classes, lots of added code/cost. In Python you get more reusability out of the box but to get correctness you need to add swaths of unit tests, lots of cost. In contrast with a functional language such as Haskell you get both with less effort, fp plus a rich type system reduce code enourmosly.

zmmmmm 8y ago

Very likely the interviewer was posing to you the exact design that they have already implemented, which they did for good reasons, and very likely your trivial solution would not scale up to the complexity of their needs. So you might have proved you could simplify the problem at hand but failed to demonstrate that you would know how to deal with more complex requirements of a larger system. For example if the commands themselves are quite complicated and have their own relationships and state then how would that be modeled? Eg. how do commands with shared behavior share it? Of course it can all be done in a functional style if you are determined enough, but it could be somewhat awkward and sounds like it wouldn't fit at all with their style of programming. I assume you probably didn't want the job in the end but if you did I would say you didn't do yourself any favors.

choot 8y ago

One of my friend who was not so strong in programming was never short of any jobs that were available to him. He told me he took a ukulele to the interview. Each time when interviewer asked him a question, he would play ukulele untill he found the answer. He got the job even when his interviews went wrong. His job offer arrived months after an interview because he was the only guy who the interviewer could remember. Often you hire for a spot in a company, after sometime that person leaves and management asks you to name any other person and when you try to recall last interviewee batch, the ukulele guy is only one the interviewer is able to remember.

Unknoob 8y ago
Your friend is a mad genius. That's so brilliantly absurd but aligns so well with my experience in interviews that I can't dispute it.
mercer 8y ago
That's awesome, and there must be more stories you can tell about this guy. If so, do tell!
heavenlyblue 8y ago
I've spent a fair amount of time interviewing in London a few years ago. I would literally go to any company that send me an e-mail or contacted me via recruiters. I didn't have enough money to buy new clothes at the time, so instead I've picked the shoes with the largest amount of holes and would never do any grooming before hands. I would come stoned to the interview. So the gist: instead of trying to appear on the lower mid end, I went all the way through to the lowest low end. Thinking retrospectively I think that's pretty much the reason why I barely received any negative responses unless I had miserably failed at the technical side of things (e.g. I didn't know how to use generators in Python at the time and the whole list of questions would be about them and their syntax). I have to admit that in this scenario I was quite good at the technical side of things. But the general philosophy was that if I don't try to appear too good - people will assume that I was better. Put humility and definite sprinkle of character on top of that.

gaius 8y ago

I'm currently reading a book on brain hemispheres. Apparently experiments have shown that the left hemisphere will completely and blatantly reject obvious evidence even if the right hemisphere 'has a clear counter proof'. Sometimes I think our industry suffers from an abundance of left hemispheric dominance. I have two monitors on my desk. If I am stuck on anything I drag my emacs from one side to the other and look at the same code there. It works pretty well!

dave_sid 8y ago

I think I can explain this. At some point in the past the interviewer has had to get to grips with OO programming. This isn’t easily for everyone, myself included. But eventually it all clicks. And it’s a great thing. Then you start learning about design patterns. You struggle to get to grips with these, you try to memorise them, you don’t quite feel comfortable with them; but one day, it all clicks. And they are great. And you feel a massive sense of accomplishment. In software development, everything moves so fast, but the feeling that you have actually learned something that is almost timeless and will outlast languages and frameworks that come and go every week is a rare feeling. And I really feel that knowledge is priceless. Try then telling them not to bother with all that and write 3 lines of code :-D If someone has invested a lot of time trying to understand OO and design patterns like this, and had the feeling of accomplishment when it all comes together, then the are going to want to apply them where they can. I think all that stuff is invaluable knowledge but people shouldn’t fall into the trap of doing something one way just because they have invested the most time in learning how to do it that way. Also, many software professionals probably find simplicity boring. Simplicity should be taken more seriously as a goal in software development. Sigh.

ripsawridge 8y ago
Wonderful insight!

Annatar 8y ago

Your situation was a perfect example of why I so violently, vehemently oppose object oriented programming and why I fight the people trying to promote it at every turn and opportunity (often in person and it can get extremely ugly -- and that is good so). Object oriented code is a nightmare to debug -- I've wasted countless years stepping through the debugger trying to follow the complex state machines I was debugging. Data hiding, one of the main selling points of this programming technique, makes it even worse with regard to building a mental model of the state of the machine. Resolving what the data is in order to understand where the problem resides ends up being extremely tedious and painful. It's like they are trying to prove that they are really, really smart without anyone asking them to prove it. But here is my challenge: anyone can overcomplicate anything, but if one is really smart, make a complex thing simple.

charlixcx 8y ago
Jesus christ get some chill. sometimes it works, there's no perfect paradigm.

ensiferum 8y ago

You forgot some Factories and Factory Factories ;-)

netcan 8y ago

There might be some sort of cognitive bias going on here. But, I think the greater driver is more "political." Complexity creates opportunities for fiefs, little areas only one person understands. I think we don't recognize what drives a good portion of people, in the tech industry. People pretend to, and are often expected to understand more than they do. Complexity helps us when reporting or manage (up and down). It's harder to grill you, challenge you or commit you to things when everything is complex. Complex requires more people, which is the main scorecard for corporate success. It's also just unintuitive that simple is harder and better than complicated. Even if you get it, someone else won't.

darkerside 8y ago
And those little fiefdoms, well maintained, can be easy domains to control and reshape according to the needs of relevant stakeholders. Whereas an over simple solution can end up doing one job well but too difficult to modify or extend without rather rewriting it. Depends on the problem you're solving.
i_made_a_booboo 8y ago
What led you to this conclusion? I've come to the same one. I think it explains a great deal of what we see. Even in the hiring process and such. It's actually very primitive at its core. Who's part of who's tribe and who is jockeying for status in that tribe.

DanielBMarkham 8y ago

I had a job working for a large Canadian company several years ago. Coming in, I was told that the specs were difficult, the tech had to be nailed, and they had already tried and failed. I took a week getting used to the customer, stack, and team. Digging through what they had? They needed two lines of code. It was the same exact situation. That was one of the more difficult consulting assignments I had. It took me quite a while to gently get the lead architect on-board. I had to position it so it looked like his idea. If I would have pushed hard, he would have pushed back...perhaps getting rid of me and hiring more of a team player. I've seen this a lot, in a lot of teams, and I think it has its roots in OO/Platonism, although it happens all over. I think the key things most of these teams are missing is that all structure is derivative. That is, there's not a line of code that's in your app that isn't in there for a reason. You're either really careful about that reason....or you add stuff because it looks good or you might need it someday, you can "imagine" how it might be helpful, the guy sitting next to you said you had to have it, and so on.

brightball 8y ago

The longer I've been in programming, the more I've noticed just how much people defend "their way" of solving a problem. If you do it differently or with a different language, there must be some negativity to latch onto in order to justify the way they did it. The simple ability to say "Oh...cool! Hey Bob, come look at what Jim figured out!" is a rare find.

dkarl 8y ago

I had a similar but inverted interview experience years ago. The interviewer asked me how I would implement a system for selling concert tickets online. I suspected, and quickly confirmed, that he wasn't interested in the UI, just the back end systems for supporting the UI. I quickly sketched out a system and described how I would serve up information about the available concerts and tickets and implement the process of buying a ticket. Then I asked the interviewer if he wanted me to go into more detail on any particular component of the system. He was NOT pleased. Then began a long process of "don't you think that's unnecessary?" and "what in the world is this for?" As I explained the need for each part of the system, he started incrementally removing all the requirements implicit in his description of the problem. First to go was the distinction between accessible and non-accessible seating, partially obscured views, basically any extra info about seats except their identity. Okay, great, that simplifies things. Likewise any idea of redundancy or failover. "Just let the process restart. You should be able to ensure no failures anyway." Okay, that's kind of opposite to how I've thought in the past, but I'll keep my mouth shut and roll with it. Just to check, I asked if I should support a concept of buying tickets for assigned seats. Nope, no assigned seating. Okay... so are there different price classes for each event? "No, the tickets are all the same!" Okay. Each event has a single price and a single pool of tickets. But to sell the ticket the user has to be able to buy it, right? Nope. No payment process. Great! I said. So there's no need to put a hold on a ticket while the user has it in his cart. The interviewer looked like he was going to burst a blood vessel. Then I said, okay, at minimum I think we need to record who we've sold tickets to so we can send them tickets or in some way ensure that the right people can be let into the concert and people who haven't bought tickets can be turned away. Um... right? "No, don't bother. If they say they bought a ticket, they did." Okay. Moving on. You wouldn't think the requirements could get much simpler than that, but you would be wrong. It turns out that the system didn't need to know when a concert was happening so it could stop selling tickets at some point. Ticket sales for a concert would go on forever. What should I do if the concert sells out? "Don't worry about that. It won't happen." At this point, I wanted to scream, "Your honor, permission to treat the witness as hostile!" It also turned out there was no need to track different events or venues. There's only one concert, it has an unlimited capacity, and it never happens. In the end it emerged that he just wanted a simple TCP service that listened on a port and served a random long integer (a "ticket") to anyone who connected without repeating the same value, unless it got rebooted, in which case it was okay to potentially serve some of the same numbers that it served during its last lifetime, as long as it didn't exhibit any patterns that might enable an attacker to predict upcoming values. What #%$%ing similarity does that have to selling concert tickets? I mean, in the phrase "sell" "concert" "tickets" "online" three out of the four words were completely irrelevant and misleading. I'm guessing it was just what he was working on that week, and in his system the values were called "tickets" so he threw out "let's sell concert tickets" in an interview hoping I would solve his problem for him. We were out of time, so we didn't have time to discuss it. I didn't get an offer and wouldn't have accepted one.