5 ms·

Hello Ezekg, I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways

by ammon 9y ago

Hello Ezekg, I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways is being really good at CS (and to people who want skills in CS, talking about DFS is a reasonable low-bar question). However, another way is writing great, well-structured rails code. We work with people all the time who don't have CS backgrounds (we help them get jobs at companies that don't care about CS). The intent of our process is to measure both CS and practical skills (we actually break it down on more axes, but you get the idea). This does mean that if you go through our process, you will be asked CS questions. But you'll also be asked to code. And not knowing the CS questions is not an obstacle to passing.

mattmanser 9y ago
Do you truly believe that being really good at CS will magically make you a skilled programmer? Are they not different skill sets? One is a practical skill, the other an academic one. I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag. I've watched online lectures where Doctors of Computer Science lecture about OO but clearly have no understanding of what works and what doesn't. I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains. I suspect I could add the word small to advantage and subset and that statement would still be true.
- aerovistae 9y ago
  I mean, you're speaking as if you had the magic cure-all to technical interviewing, and if you did I'm sure you'd be telling us what it is instead of somewhat condescendingly criticizing someone else's methodology.
  - mattmanser 9y ago
    I certainly didn't mean my reply to be condescending. Are you objecting to the word magically? He literally says that one way to be a skilled programmer is to be really good at CS. How is that not magically? What word would you have used? Unfortunately, your reply is clearly condescending. And adds nothing to the discussion.
- Silhouette 9y ago
  Do you truly believe that being really good at CS will magically make you a skilled programmer? Isn't the problem more often that lacking awareness of theoretical CS issues can limit your potential as a programmer? For example, someone with that awareness would immediately recognise some of the later questions as standard graph theory problems and could then solve them appropriately. Without that context, maybe a good programmer could still figure out a working solution from first principles, but it would surely take them longer. And while I don't suppose many of us will be working on intergalactic transport infrastructure any time soon, similar recognition scenarios do come up in plenty of day-to-day programming jobs.
  - ezekg 9y ago
    There's a difference between expecting candidates to know when to recognize graph theory problems and expecting candidates to know (and implement) Dijkstra's algorithm as the correct solution to some abstract problem. I don't remember what Dijkstra's algorithm is exactly off the top of my head (all I remember is that it's for graph traversal and has a memorable name), but I do know when to recognize graph theory problems so I can start looking for the correct solution. I definitely agree that general CS knowledge is highly beneficial (it's why I put in the time to learn), but knowing implementations for specific algos doesn't seem as important in the day-to-day as interviews make it out to be.
    - poikniok 9y ago
      That is nice, however when hiring people it is useful to get somebody who can actually implement the solution too, rather than just sitting back smugly having identified a problem as "Dijkstra's".
      - mindcrime 9y ago
        If somebody can get as far as recognizing the problem as requiring Dijkstra's algorithm, they can go pull a book off the shelf, or use Google, and find the details of the implementation. Or, more likely, find a pre-existing implementation[1] that can be re-used. Personally, I doubt that many people are walking around with the deep details of Dijkstra's memorized and readily available, unless they have a job that very specifically focuses on graph operations and they do nothing else day in and day out. So you could memorize it just for the interview, and then forget it again by the next day. But is there really any point to all that? [1]: https://www.google.com/search?num=30&q=graph+algorithm+library+"open+source" https://www.google.com/search?num=30&q=graph+algorithm+libra...
- fwefwwfe 9y ago
  > Are they not different skill sets? One is a practical skill, the other an academic one. I'd like to see you design and program a P2P networked program without any CS knowledge, like Kazaa or Bit Torrent, that actually works as well as they do. > I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag. That's true for lots of fields, but it's not hard to see that that doesn't mean theoretical knowledge isn't useful.
  - squeaky-clean 9y ago
    > that actually works as well as they do. I doubt most CS grads could do this. One hard part of it is the p2p (but that's already been solved [0]). Having a project that large where you don't eventually shoot yourself in the foot because of architecture and finish in a reasonable time without using too many resources on a user's computer is also a hard part. [0] https://github.com/bittorrent/libutp https://github.com/bittorrent/libutp
    - fwefwwfe 9y ago
      > I doubt most CS grads could do this. Of course not, but the point is that the information can be valuable for making real things.
  - jaggederest 9y ago
    It's a lot, lot easier to read papers on the algorithms needed by, and understand the specific requirements of, a particular project than it is to learn the entirety of software development outside algorithms ad hoc. Honestly, even though I do know a fair bit about the Bit Torrent algorithms, I wouldn't trust that knowledge since it's most likely out of date or incomplete. It's deserving of research for anyone, even people who 'know it already'. That's why I don't understand these narrow algorithmic tests - very, very seldom is a priori knowledge about DFS vs BFS going to be something that makes or breaks a project. It would be akin to testing civil engineers on the memorization of precise ratios of the ingredients of concrete in current usage, instead of on the broad applicability of particular materials to particular purposes.
- fwefwwfe 9y ago
  > I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains. > I suspect I could add the word small to advantage and subset and that statement would still be true. I doubt that's even close to true. You need CS knowledge to optimize programs and to design reliable services. It would only be true if you squint really hard and cherry pick some domains where CS knowledge isn't valuable and cherry pick what counts as 'academic CS knowledge'. I would have edited my previous reply, but it was too late.
- flai 9y ago
  No, but I believe that not being able to figure out the runtime-complexity of easy algorithms hinders you as a programmer. Being able to reason about these things is important for a lot of different tasks that can and will occur in most projects, and are very crucial for some.
- EpicEng 9y ago
  >I suspect I could add the word small to advantage and subset and that statement would still be true. Sounds like you're only familiar with programming to solve easy problems. Lots (most) of us do it, and that's fine, but there are a large number who tackle the more complex domains and need both skills.
  - mattmanser 9y ago
    It's because I do realise there are a small number of domains that do benefit from formal CS knowledge that I couched it that way. You are, after all, agreeing with me. Most.
    - EpicEng 9y ago
      I'm disagreeing that I don't believe it is a 'small' number of domains, only that they are domains you're not familiar with (or aware of.) Other than that though, yes, we agree.

by ammon 9y ago

mattmanser 9y ago

Do you truly believe that being really good at CS will magically make you a skilled programmer? Are they not different skill sets? One is a practical skill, the other an academic one. I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag. I've watched online lectures where Doctors of Computer Science lecture about OO but clearly have no understanding of what works and what doesn't. I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains. I suspect I could add the word small to advantage and subset and that statement would still be true.

aerovistae 9y ago
I mean, you're speaking as if you had the magic cure-all to technical interviewing, and if you did I'm sure you'd be telling us what it is instead of somewhat condescendingly criticizing someone else's methodology.
- mattmanser 9y ago
  I certainly didn't mean my reply to be condescending. Are you objecting to the word magically? He literally says that one way to be a skilled programmer is to be really good at CS. How is that not magically? What word would you have used? Unfortunately, your reply is clearly condescending. And adds nothing to the discussion.
Silhouette 9y ago
Do you truly believe that being really good at CS will magically make you a skilled programmer? Isn't the problem more often that lacking awareness of theoretical CS issues can limit your potential as a programmer? For example, someone with that awareness would immediately recognise some of the later questions as standard graph theory problems and could then solve them appropriately. Without that context, maybe a good programmer could still figure out a working solution from first principles, but it would surely take them longer. And while I don't suppose many of us will be working on intergalactic transport infrastructure any time soon, similar recognition scenarios do come up in plenty of day-to-day programming jobs.
- ezekg 9y ago
  There's a difference between expecting candidates to know when to recognize graph theory problems and expecting candidates to know (and implement) Dijkstra's algorithm as the correct solution to some abstract problem. I don't remember what Dijkstra's algorithm is exactly off the top of my head (all I remember is that it's for graph traversal and has a memorable name), but I do know when to recognize graph theory problems so I can start looking for the correct solution. I definitely agree that general CS knowledge is highly beneficial (it's why I put in the time to learn), but knowing implementations for specific algos doesn't seem as important in the day-to-day as interviews make it out to be.
  - poikniok 9y ago
    That is nice, however when hiring people it is useful to get somebody who can actually implement the solution too, rather than just sitting back smugly having identified a problem as "Dijkstra's".
    - mindcrime 9y ago
      If somebody can get as far as recognizing the problem as requiring Dijkstra's algorithm, they can go pull a book off the shelf, or use Google, and find the details of the implementation. Or, more likely, find a pre-existing implementation[1] that can be re-used. Personally, I doubt that many people are walking around with the deep details of Dijkstra's memorized and readily available, unless they have a job that very specifically focuses on graph operations and they do nothing else day in and day out. So you could memorize it just for the interview, and then forget it again by the next day. But is there really any point to all that? [1]: https://www.google.com/search?num=30&q=graph+algorithm+library+"open+source" https://www.google.com/search?num=30&q=graph+algorithm+libra...
fwefwwfe 9y ago
> Are they not different skill sets? One is a practical skill, the other an academic one. I'd like to see you design and program a P2P networked program without any CS knowledge, like Kazaa or Bit Torrent, that actually works as well as they do. > I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag. That's true for lots of fields, but it's not hard to see that that doesn't mean theoretical knowledge isn't useful.
- squeaky-clean 9y ago
  > that actually works as well as they do. I doubt most CS grads could do this. One hard part of it is the p2p (but that's already been solved [0]). Having a project that large where you don't eventually shoot yourself in the foot because of architecture and finish in a reasonable time without using too many resources on a user's computer is also a hard part. [0] https://github.com/bittorrent/libutp https://github.com/bittorrent/libutp
  - fwefwwfe 9y ago
    > I doubt most CS grads could do this. Of course not, but the point is that the information can be valuable for making real things.
- jaggederest 9y ago
  It's a lot, lot easier to read papers on the algorithms needed by, and understand the specific requirements of, a particular project than it is to learn the entirety of software development outside algorithms ad hoc. Honestly, even though I do know a fair bit about the Bit Torrent algorithms, I wouldn't trust that knowledge since it's most likely out of date or incomplete. It's deserving of research for anyone, even people who 'know it already'. That's why I don't understand these narrow algorithmic tests - very, very seldom is a priori knowledge about DFS vs BFS going to be something that makes or breaks a project. It would be akin to testing civil engineers on the memorization of precise ratios of the ingredients of concrete in current usage, instead of on the broad applicability of particular materials to particular purposes.
fwefwwfe 9y ago
> I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains. > I suspect I could add the word small to advantage and subset and that statement would still be true. I doubt that's even close to true. You need CS knowledge to optimize programs and to design reliable services. It would only be true if you squint really hard and cherry pick some domains where CS knowledge isn't valuable and cherry pick what counts as 'academic CS knowledge'. I would have edited my previous reply, but it was too late.
flai 9y ago
No, but I believe that not being able to figure out the runtime-complexity of easy algorithms hinders you as a programmer. Being able to reason about these things is important for a lot of different tasks that can and will occur in most projects, and are very crucial for some.
EpicEng 9y ago
>I suspect I could add the word small to advantage and subset and that statement would still be true. Sounds like you're only familiar with programming to solve easy problems. Lots (most) of us do it, and that's fine, but there are a large number who tackle the more complex domains and need both skills.
- mattmanser 9y ago
  It's because I do realise there are a small number of domains that do benefit from formal CS knowledge that I couched it that way. You are, after all, agreeing with me. Most.
  - EpicEng 9y ago
    I'm disagreeing that I don't believe it is a 'small' number of domains, only that they are domains you're not familiar with (or aware of.) Other than that though, yes, we agree.