4 ms·

Is there a problem with operating at that level of abstraction? Are we here to serve our egos, or business needs? I'm sure I could implement one, but it'd requ

Is there a problem with operating at that level of abstraction? Are we here to serve our egos, or business needs? I'm sure I could implement one, but it'd require googling. If that ever kept me from a position, they could gladly keep it.

teacup50 10y ago
A linked list is so simple that you should know how to implement one off the top of your head. It's literally: struct list_node { struct list_node *next; ... }; There, you know how linked lists work :)
- quaunaut 10y ago
  That's what I came up with in my head, but my issue is, in an interview I'd not be confident with that kind of an answer. I've never done that before, I've never had a reason to do that before. I've contributed to Rails, graphing libraries, written docs for complex JS projects, implemented caching solutions, written authentication and authorization backends- but this here is like asking an architect to cut down a tree. Sure, he can figure it out, but he's gonna look stupid for the first few minutes.
  - sulam 10y ago
    The figuring it out is entirely the point of the interview. When I interview someone, I need to work on a problem with them. The simpler the problem we can work on together, the more likely that I'll learn what they're like to work with, not whether or not they've memorized some trivia like how to implement quicksort in 10 lines of Python.
    - quaunaut 10y ago
      That's fair, and a totally valid way of going about it. But if I'd been devving for a few years and hadn't heard the term "linked list", and the interviewer scoffed at having to answer the question of what it was, I get uninterested real fast.
  - deleted 10y ago
    [deleted]
mseebach 10y ago
Sure, if what you're doing is trivial, and remains trivial, you can get by with low skills, that's tautological. It's just that people rarely really know the limit of their skills, and end up doing things they think are trivial, but aren't, and boom, you have a seemingly trivial screen in your app that takes 45 seconds once there are 2000 row in some table, and you have no idea why. There are pretty simple things that will blow up in your face performance-wise even at rather modest scale if you don't know what's going on under the hood. Do you know why you're not supposed to concate strings, especially at scale/in loops? Do you know what the N+1 performance problem is? I've seen simple webapps take out beefy servers at modest load because a dev didn't. So yeah, we're here to serve business needs, and for that we need devs who can reason at the most basic level of abstraction about what's going on under the hood.
- quaunaut 10y ago
  The N+1 issue is one that everyone ends up learning and understanding on the job fairly quickly. It doesn't require anything abstract to understand- "You're constantly hitting it over and over instead of doing things in one or two passes." Modern programming generally has you approaching any obscure issues like this the same way: You profile your code, figure out where something is going horribly wrong, then try to look up answers for why. If I noticed that my string concatenation was taking an inordinate amount of time, it'd probably take me under 5 minutes to figure out why via Google alone. Hell, I'd significantly wonder what someone was doing if they were concatenating strings enough to cause performance issues. I can't imagine any business need, for anyone, that could be brought together by that.

teacup50 10y ago

A linked list is so simple that you should know how to implement one off the top of your head. It's literally: struct list_node { struct list_node *next; ... }; There, you know how linked lists work :)

quaunaut 10y ago
That's what I came up with in my head, but my issue is, in an interview I'd not be confident with that kind of an answer. I've never done that before, I've never had a reason to do that before. I've contributed to Rails, graphing libraries, written docs for complex JS projects, implemented caching solutions, written authentication and authorization backends- but this here is like asking an architect to cut down a tree. Sure, he can figure it out, but he's gonna look stupid for the first few minutes.
- sulam 10y ago
  The figuring it out is entirely the point of the interview. When I interview someone, I need to work on a problem with them. The simpler the problem we can work on together, the more likely that I'll learn what they're like to work with, not whether or not they've memorized some trivia like how to implement quicksort in 10 lines of Python.
  - quaunaut 10y ago
    That's fair, and a totally valid way of going about it. But if I'd been devving for a few years and hadn't heard the term "linked list", and the interviewer scoffed at having to answer the question of what it was, I get uninterested real fast.
- deleted 10y ago
  [deleted]

mseebach 10y ago

Sure, if what you're doing is trivial, and remains trivial, you can get by with low skills, that's tautological. It's just that people rarely really know the limit of their skills, and end up doing things they think are trivial, but aren't, and boom, you have a seemingly trivial screen in your app that takes 45 seconds once there are 2000 row in some table, and you have no idea why. There are pretty simple things that will blow up in your face performance-wise even at rather modest scale if you don't know what's going on under the hood. Do you know why you're not supposed to concate strings, especially at scale/in loops? Do you know what the N+1 performance problem is? I've seen simple webapps take out beefy servers at modest load because a dev didn't. So yeah, we're here to serve business needs, and for that we need devs who can reason at the most basic level of abstraction about what's going on under the hood.

quaunaut 10y ago
The N+1 issue is one that everyone ends up learning and understanding on the job fairly quickly. It doesn't require anything abstract to understand- "You're constantly hitting it over and over instead of doing things in one or two passes." Modern programming generally has you approaching any obscure issues like this the same way: You profile your code, figure out where something is going horribly wrong, then try to look up answers for why. If I noticed that my string concatenation was taking an inordinate amount of time, it'd probably take me under 5 minutes to figure out why via Google alone. Hell, I'd significantly wonder what someone was doing if they were concatenating strings enough to cause performance issues. I can't imagine any business need, for anyone, that could be brought together by that.