8 ms·

I just graduated, so I'm not dealing with constant internship interviews anymore, but at the time I absolutely hated it. My frustration isn't exactly like your

I just graduated, so I'm not dealing with constant internship interviews anymore, but at the time I absolutely hated it. My frustration isn't exactly like yours (my time is probably a lot less valuable). I feel that the questions are all geared at puzzle solvers. If you're a puzzle solver, you love answers. You love digging into the details. You love finding out the basic components of a system. I think these are the people who excel in academics. Almost every other intern I met once I got to the bay area was a puzzle solver. They were also competitive and had amazing grades. And these people LOVED algo questions. Over lunch, they could go through half a dozen questions. I slipped through the cracks I guess. I'm bored by puzzles, have awful grades (and in a worse program), and not so competitive. What I do enjoy, however, is building up. I like modeling and being about to think at greater and greater levels of abstraction to solve problems that aren't puzzles, but instead open ended questions. Anyway, I think both of these types of people have a place is software, and only one is given attention

jsmeaton 8y ago
Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.
- SamReidHughes 8y ago
  If you can't handle simple data structures problems you need to stay far, far away from software architecture.
  - scarface74 8y ago
    In the real world software architecture is rarely about “data structures”. Software architecture is about teasing out the needs of the customer - whether that be internal or external - and knowing how to design systems that are maintainable, scalable, fault tolerant, etc.
    - SamReidHughes 8y ago
      Scalable, fault tolerant systems is a distributed systems problem, which is a harder form of data structures problem.
      - scarface74 8y ago
        Yes but unless you are actually working on creating the system that other people implement, you are just using work made by others. You don’t need to know the ins and outs of various gossip protocols.
    - rapind 8y ago
      Potentially two things here: 1) Gathering requirements. 2) Turning those requirements into data structures. I think a lot of companies will separate those into different roles, but I strongly believe that's a costly mistake in most situations. There's a feedback loop. Requirements inform your data structures, but your data structures help you contextualize (not pollute) your requirements. If you're working with an existing system, you also want to understand current structures in order to guide requirements. By guide, I don't mean to ignore pain, but if you're building a system to support multiple clients / users, then the real trick is to figure out how to do that in a cost-effective and elegant way. When these roles are separated, and the requirements are gathered without knowledge of the structures, I believe you're setting yourself for failure in the long term (spaghetti code / everyone gets something different). Getting these to gel is the puzzle I'm personally passionate about. I don't mind what I would call the math side of programming / code puzzles, but it simply doesn't give me the endorphin rush that building a system that elegantly ties things together does. The best is when you're working towards that or have achieved that and inspiration for further possibilities, improvements, efficiencies start popping up. I'm not sure how you test for this as part of the hiring process, at least not efficiently. I do think we get better at this with experience, but I doubt it's exclusive to seasoned developers.
      - scarface74 8y ago
        But still “data structures” in the context of most businesses are more Domain Driven Design “Domain Contexts”, “Aggregate Roots”, type structures than any type of complicated CS type data structures.
  - theoh 8y ago
    That depends on what is meant by software architecture. If you mean the structuring of a system to achieve good or (particularly) consistent worst-case performance, maybe you are right. But if architecture is used to mean the design of a system to satisfy users (and present a clean, extensible, meaningful interface) then it's really a conceptual job that has more to do with design skills than optimized algorithms.
    - SamReidHughes 8y ago
      Being able to make a clean interface, as in a clean API, or useful one, is a data structures/algorithms problem and often a distributed systems problem. Many API's are technically impossible to use correctly. For example they might not let you do two things atomically that need to be. Or they might suffer enormously because they don't version their information properly, resulting in client/server disagreements over the nature of reality that are impossible to avoid. Or you get components that are impossible to interrupt cleanly or shut down safely. It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.
      - theoh 8y ago
        Designing something on an architectural level really isn't always a data structures and algorithms problem. Take the web, for example. REST isn't complicated, but it does the job and it opened up more possibilities than any other invention since timesharing. As other commenters have noted, choosing an architecture for a system may have more to do with vision, common sense, and even imagination. And the web is such a great example of this, maybe the classic example. As you probably know, it's possible to write a webserver without having a clue about fancy data structures or algorithms. It's the imaginative composition of pre-existing features that creates the architecture. Another example would be the extensibility of Emacs through elisp. Consider the notion of hooks which essentially allow utility functions to be customized by the user. It's a purely architectural concept. Or the Unix philosophy: small utilities that read and write text, linked by pipes. Really no algorithmic complexity to it at all. It feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems. Vision and a perspective that differs from the norm are a lot rarer and potentially more valuable than the ability to apply software engineering principles. Architecture, in the broadest sense, is precisely the area where these "outside the box" contributions are likely to be valuable. Consider the invention of the Wiki. It came out of the pattern language world, it was a hugely beneficial innovation, and it has almost zero data structures/algorithms complexity behind it. I'd even argue that the examples of pitfalls that you list are more clerical matters of systems programming than cases where architectural design principles are lacking. (And even the professionals who can reliably grind out working code for large systems can get the architecture spectacularly wrong, as the case of the X window system: http://web.archive.org/web/20170920104011/https://minnie.tuhs.org//pipermail/tuhs/2017-September/010471.html http://web.archive.org/web/20170920104011/https://minnie.tuh... )
  - sn41 8y ago
    Not really, not at all. Software architecture is a lot about wisdom - how to anticipate future changes. Often user interfaces need to be carefully and gently designed so that the user has no surprises. Diligence from the user should not be assumed, the user interface must emphasize tricky parts and make choices less onerous, etc. Scalability is preferrably achieved by simple code + hardware/vms rather than overoptimized code which depends on "irreplaceable" programmers - what if they fall sick, or leave the company? etc. I think all of this is experience accrued over many years, and with facing many failures. I have found that the data structures that you need are often simple trees and hashes. Database design is probably more important. I often shake my head at students doing hours of dynamic programming to crack interviews. In the past year, how many problems in your company have you solved through dynamic programming? I suspect, not many.
  - nailer 8y ago
    Parent was discussing not being interested in algo design, rather than not knowing data structures.
- opportune 8y ago
  Is it possible to even get into software architecture without pretty significant experience? From my experience in the workplace anybody making purely architectural decisions without having to implement them is a team lead or higher in the organizational architecture.
  - notyourwork 8y ago
    Which makes sense right? Same reason a military general doesn’t start as a general. Architecture takes experience in the weeds to give a breadth you can leverage as you reason through architecture. Architecture isn’t aslways black and white decision making based on some specs which is where experience can help a ton.
    - Aeolun 8y ago
      Generals often start out as lieutenants though (e.g. officer academy drops you in on a higher rank).
      - skh 8y ago
        In the U.S. military this is not true. People graduating from OCS, ROTC, or one of the academies start off at O-1 (2nd Lieutenant).
        learc83 8y ago
        What's your disagreement? 1st Lieutenant vs 2nd Lieutenant? Lieutenant is commonly used to refer to both. Or are you saying that you start of at O-1 and not a higher paygrade? If that's the case, the OP was pointing out that you start off outranking enlisted service members, not that you start out above O-1.
        skh 8y ago
        Well, I misread the comment I responded to. I thought they said that academy graduates don’t start off at lieutenant and start off at a higher rate.
- nicoburns 8y ago
  I like roles where I get to do both! I've found that a lot of problems come from these being different roles, and the developers not really understanding or buying into the vision of the architects (who might be able to see the big picture, but can often make decisions that make no sense due to being removed from the details of the existing implementation). Of course in really large companies I suppose having these as a seperate role is a necessary evil. But I still think there should be much more collaboration and interaction between people in these different roles than I generally see.
- paulgrant999 8y ago
  my understanding is with the migration to thousands of "pizza" developer teams doing self-service, that "no one person understand the entire codebase" i.e. software architecting is dead. Am I in error to hold this belief?
holdenc 8y ago
I am like you. For me, the solution has been build something and show it off. Building a great and useful app rarely requires Herculean feats of logic and puzzle solving.
- nailer 8y ago
  Years ago I was rejected by Google for a permanent position, then a year later employed at a much better rate as a contractor in the same building I'd interviewed in. I'd built a relatively cool app (full stack, from Linux to Tornado to JavaScript to UX), like Secret or YikYak (but a few years before either). The people in Creative Lab were impressed with the ride range of knowledge I had, the SRE guys who rejected me got stuck into me for mixing up some VMware terminology.
- widforss 8y ago
  My current problem is that I built an app and showed of to some gov agencies, and now that demo app is solving their business problems.
turtlecloud 8y ago
I agree with you. The puzzle solver ABSOLUTELY hate it if you somehow say that the question is flawed. Ie if you think outside the box and render their hypothetical situation flawed. It’s as if they didn’t spend enough time to realize that they are missing the forest for the trees.
- paulgrant999 8y ago
  lol. I rolled something that was patentworthy by a researcher at one of the FANG-sized corps (from scratch). Corrected a theoretical flaw that rendered the algorithm request impossible mathematically. Detected and solved a much larger semantic problem (which fixed permanently the problem they were trying to solve). And the "coder" was only concerned about "why I chose to log" -- "so I can break the job down, pause and resume - since you didn't include ms timestamps I had to come up with a way to partition the log into parallelizable, resumable chunks". -- They were extremely upset about the flawed spec. They couldn't understand either the patentworthy algo; or most of the programs actual key details. -- Also, they lied about being a coder. - Now what, a I supposed to do with that. You asked, for a professional. You got one. Not my problem if you only hire hacks. -- Even worse on the devops side.
- Drdrdrq 8y ago
  To be fair, almost everyone hates it when you show them they are wrong. Especially in the setting where they are supposed to be judging you, remember? And even in normal settings it pays to think about how some critique will be received by the other side. It's a slippery slope in the interview... For me it would raise red flags if the flaw was pointed out in an inappropriate manner. After all, this is the person who would be involved in code reviews where sensitivity to other people's feelings (and egos) is very important.
  - Matumio 8y ago
    > they are supposed to be judging you, remember? It's actually supposed to be mutual judgement. But I agree: be respectful if you decide to drop a remark about the relevance of the question. There are enough reasons to treat people with respect even if you can afford to turn them down.
flatline 8y ago
I like solving puzzles. I like algorithms. Every once in a while I even get to use them at my job! Solving these kinds of things is at most 5-10% of a developer’s job, and that’s probably a stretch in reality. The number of times I’ve seen things like dynamic programming come up in a real world application are vanishingly small, and rarely will you need to roll your own implementation rather than using a third party library. Even if you’re working on a library like that, considerations of good software design principles, infrastructure and the like will consume a large portion of your time.
bg24 8y ago
>> "What I do enjoy, however, is building up. I like modeling and being about to think at greater and greater levels of abstraction to solve problems that aren't puzzles, but instead open ended questions." In my opinion, you will do well if you focus on building your own business sooner or later.
- solipsism 8y ago
  What an odd thing to suggest. Owning a business isn't for everyone. Not by a long shot.
  - krisoft 8y ago
    No, it is not. But grand parent comment was giving this advice based on the quoted specifics and not for everyone.
    - graphenus 8y ago
      And most importantly, the commenter gave one's suggestion based on representiveness, which are not facts. The rest follows from here.
  - GrzegorzWidla 8y ago
    But building something from scratch, even if non-profit, is the easiest way to get a job you really want. And at the same time you can find out that you like doing actual business and smoothly transition. It's a win-win IMO.
calf 8y ago
You're better suited for research which is about working long term on open problems.
- nitrogen 8y ago
  I think the opposite would be true; research might benefit from puzzle solving, and software engineering is precisely the discipline of building up and reasoning about layers of abstraction and components of a system.
  - LanceH 8y ago
    Research is a grind when it's not about writing grant proposals and then it's a different grind.
vpmpaul 8y ago
The puzzle solver obsession in SV has always confused me. Seems to me that you would only need a handful of those type of personalities at any software company. The majority of the work is just shoveling so to speak. I'm no expert but I know a logistics company that has the 30 workers 1 puzzle guy setup. He maybe writes 20 lines of code a week but its on stuff other people cant figure out. However if he was the only type there literally nothing would ever get done.

jsmeaton 8y ago

Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.

SamReidHughes 8y ago
If you can't handle simple data structures problems you need to stay far, far away from software architecture.
- scarface74 8y ago
  In the real world software architecture is rarely about “data structures”. Software architecture is about teasing out the needs of the customer - whether that be internal or external - and knowing how to design systems that are maintainable, scalable, fault tolerant, etc.
  - SamReidHughes 8y ago
    Scalable, fault tolerant systems is a distributed systems problem, which is a harder form of data structures problem.
    - scarface74 8y ago
      Yes but unless you are actually working on creating the system that other people implement, you are just using work made by others. You don’t need to know the ins and outs of various gossip protocols.
  - rapind 8y ago
    Potentially two things here: 1) Gathering requirements. 2) Turning those requirements into data structures. I think a lot of companies will separate those into different roles, but I strongly believe that's a costly mistake in most situations. There's a feedback loop. Requirements inform your data structures, but your data structures help you contextualize (not pollute) your requirements. If you're working with an existing system, you also want to understand current structures in order to guide requirements. By guide, I don't mean to ignore pain, but if you're building a system to support multiple clients / users, then the real trick is to figure out how to do that in a cost-effective and elegant way. When these roles are separated, and the requirements are gathered without knowledge of the structures, I believe you're setting yourself for failure in the long term (spaghetti code / everyone gets something different). Getting these to gel is the puzzle I'm personally passionate about. I don't mind what I would call the math side of programming / code puzzles, but it simply doesn't give me the endorphin rush that building a system that elegantly ties things together does. The best is when you're working towards that or have achieved that and inspiration for further possibilities, improvements, efficiencies start popping up. I'm not sure how you test for this as part of the hiring process, at least not efficiently. I do think we get better at this with experience, but I doubt it's exclusive to seasoned developers.
    - scarface74 8y ago
      But still “data structures” in the context of most businesses are more Domain Driven Design “Domain Contexts”, “Aggregate Roots”, type structures than any type of complicated CS type data structures.
- theoh 8y ago
  That depends on what is meant by software architecture. If you mean the structuring of a system to achieve good or (particularly) consistent worst-case performance, maybe you are right. But if architecture is used to mean the design of a system to satisfy users (and present a clean, extensible, meaningful interface) then it's really a conceptual job that has more to do with design skills than optimized algorithms.
  - SamReidHughes 8y ago
    Being able to make a clean interface, as in a clean API, or useful one, is a data structures/algorithms problem and often a distributed systems problem. Many API's are technically impossible to use correctly. For example they might not let you do two things atomically that need to be. Or they might suffer enormously because they don't version their information properly, resulting in client/server disagreements over the nature of reality that are impossible to avoid. Or you get components that are impossible to interrupt cleanly or shut down safely. It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.
    - theoh 8y ago
      Designing something on an architectural level really isn't always a data structures and algorithms problem. Take the web, for example. REST isn't complicated, but it does the job and it opened up more possibilities than any other invention since timesharing. As other commenters have noted, choosing an architecture for a system may have more to do with vision, common sense, and even imagination. And the web is such a great example of this, maybe the classic example. As you probably know, it's possible to write a webserver without having a clue about fancy data structures or algorithms. It's the imaginative composition of pre-existing features that creates the architecture. Another example would be the extensibility of Emacs through elisp. Consider the notion of hooks which essentially allow utility functions to be customized by the user. It's a purely architectural concept. Or the Unix philosophy: small utilities that read and write text, linked by pipes. Really no algorithmic complexity to it at all. It feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems. Vision and a perspective that differs from the norm are a lot rarer and potentially more valuable than the ability to apply software engineering principles. Architecture, in the broadest sense, is precisely the area where these "outside the box" contributions are likely to be valuable. Consider the invention of the Wiki. It came out of the pattern language world, it was a hugely beneficial innovation, and it has almost zero data structures/algorithms complexity behind it. I'd even argue that the examples of pitfalls that you list are more clerical matters of systems programming than cases where architectural design principles are lacking. (And even the professionals who can reliably grind out working code for large systems can get the architecture spectacularly wrong, as the case of the X window system: http://web.archive.org/web/20170920104011/https://minnie.tuhs.org//pipermail/tuhs/2017-September/010471.html http://web.archive.org/web/20170920104011/https://minnie.tuh... )
- sn41 8y ago
  Not really, not at all. Software architecture is a lot about wisdom - how to anticipate future changes. Often user interfaces need to be carefully and gently designed so that the user has no surprises. Diligence from the user should not be assumed, the user interface must emphasize tricky parts and make choices less onerous, etc. Scalability is preferrably achieved by simple code + hardware/vms rather than overoptimized code which depends on "irreplaceable" programmers - what if they fall sick, or leave the company? etc. I think all of this is experience accrued over many years, and with facing many failures. I have found that the data structures that you need are often simple trees and hashes. Database design is probably more important. I often shake my head at students doing hours of dynamic programming to crack interviews. In the past year, how many problems in your company have you solved through dynamic programming? I suspect, not many.
- nailer 8y ago
  Parent was discussing not being interested in algo design, rather than not knowing data structures.
opportune 8y ago
Is it possible to even get into software architecture without pretty significant experience? From my experience in the workplace anybody making purely architectural decisions without having to implement them is a team lead or higher in the organizational architecture.
- notyourwork 8y ago
  Which makes sense right? Same reason a military general doesn’t start as a general. Architecture takes experience in the weeds to give a breadth you can leverage as you reason through architecture. Architecture isn’t aslways black and white decision making based on some specs which is where experience can help a ton.
  - Aeolun 8y ago
    Generals often start out as lieutenants though (e.g. officer academy drops you in on a higher rank).
    - skh 8y ago
      In the U.S. military this is not true. People graduating from OCS, ROTC, or one of the academies start off at O-1 (2nd Lieutenant).
      - learc83 8y ago
        What's your disagreement? 1st Lieutenant vs 2nd Lieutenant? Lieutenant is commonly used to refer to both. Or are you saying that you start of at O-1 and not a higher paygrade? If that's the case, the OP was pointing out that you start off outranking enlisted service members, not that you start out above O-1.
        skh 8y ago
        Well, I misread the comment I responded to. I thought they said that academy graduates don’t start off at lieutenant and start off at a higher rate.
nicoburns 8y ago
I like roles where I get to do both! I've found that a lot of problems come from these being different roles, and the developers not really understanding or buying into the vision of the architects (who might be able to see the big picture, but can often make decisions that make no sense due to being removed from the details of the existing implementation). Of course in really large companies I suppose having these as a seperate role is a necessary evil. But I still think there should be much more collaboration and interaction between people in these different roles than I generally see.
paulgrant999 8y ago
my understanding is with the migration to thousands of "pizza" developer teams doing self-service, that "no one person understand the entire codebase" i.e. software architecting is dead. Am I in error to hold this belief?

holdenc 8y ago

I am like you. For me, the solution has been build something and show it off. Building a great and useful app rarely requires Herculean feats of logic and puzzle solving.

nailer 8y ago
Years ago I was rejected by Google for a permanent position, then a year later employed at a much better rate as a contractor in the same building I'd interviewed in. I'd built a relatively cool app (full stack, from Linux to Tornado to JavaScript to UX), like Secret or YikYak (but a few years before either). The people in Creative Lab were impressed with the ride range of knowledge I had, the SRE guys who rejected me got stuck into me for mixing up some VMware terminology.
widforss 8y ago
My current problem is that I built an app and showed of to some gov agencies, and now that demo app is solving their business problems.

turtlecloud 8y ago

I agree with you. The puzzle solver ABSOLUTELY hate it if you somehow say that the question is flawed. Ie if you think outside the box and render their hypothetical situation flawed. It’s as if they didn’t spend enough time to realize that they are missing the forest for the trees.

paulgrant999 8y ago
lol. I rolled something that was patentworthy by a researcher at one of the FANG-sized corps (from scratch). Corrected a theoretical flaw that rendered the algorithm request impossible mathematically. Detected and solved a much larger semantic problem (which fixed permanently the problem they were trying to solve). And the "coder" was only concerned about "why I chose to log" -- "so I can break the job down, pause and resume - since you didn't include ms timestamps I had to come up with a way to partition the log into parallelizable, resumable chunks". -- They were extremely upset about the flawed spec. They couldn't understand either the patentworthy algo; or most of the programs actual key details. -- Also, they lied about being a coder. - Now what, a I supposed to do with that. You asked, for a professional. You got one. Not my problem if you only hire hacks. -- Even worse on the devops side.
Drdrdrq 8y ago
To be fair, almost everyone hates it when you show them they are wrong. Especially in the setting where they are supposed to be judging you, remember? And even in normal settings it pays to think about how some critique will be received by the other side. It's a slippery slope in the interview... For me it would raise red flags if the flaw was pointed out in an inappropriate manner. After all, this is the person who would be involved in code reviews where sensitivity to other people's feelings (and egos) is very important.
- Matumio 8y ago
  > they are supposed to be judging you, remember? It's actually supposed to be mutual judgement. But I agree: be respectful if you decide to drop a remark about the relevance of the question. There are enough reasons to treat people with respect even if you can afford to turn them down.

flatline 8y ago

I like solving puzzles. I like algorithms. Every once in a while I even get to use them at my job! Solving these kinds of things is at most 5-10% of a developer’s job, and that’s probably a stretch in reality. The number of times I’ve seen things like dynamic programming come up in a real world application are vanishingly small, and rarely will you need to roll your own implementation rather than using a third party library. Even if you’re working on a library like that, considerations of good software design principles, infrastructure and the like will consume a large portion of your time.

bg24 8y ago

>> "What I do enjoy, however, is building up. I like modeling and being about to think at greater and greater levels of abstraction to solve problems that aren't puzzles, but instead open ended questions." In my opinion, you will do well if you focus on building your own business sooner or later.

solipsism 8y ago
What an odd thing to suggest. Owning a business isn't for everyone. Not by a long shot.
- krisoft 8y ago
  No, it is not. But grand parent comment was giving this advice based on the quoted specifics and not for everyone.
  - graphenus 8y ago
    And most importantly, the commenter gave one's suggestion based on representiveness, which are not facts. The rest follows from here.
- GrzegorzWidla 8y ago
  But building something from scratch, even if non-profit, is the easiest way to get a job you really want. And at the same time you can find out that you like doing actual business and smoothly transition. It's a win-win IMO.

calf 8y ago

You're better suited for research which is about working long term on open problems.

nitrogen 8y ago
I think the opposite would be true; research might benefit from puzzle solving, and software engineering is precisely the discipline of building up and reasoning about layers of abstraction and components of a system.
- LanceH 8y ago
  Research is a grind when it's not about writing grant proposals and then it's a different grind.

vpmpaul 8y ago

The puzzle solver obsession in SV has always confused me. Seems to me that you would only need a handful of those type of personalities at any software company. The majority of the work is just shoveling so to speak. I'm no expert but I know a logistics company that has the 30 workers 1 puzzle guy setup. He maybe writes 20 lines of code a week but its on stuff other people cant figure out. However if he was the only type there literally nothing would ever get done.