4 ms·

I'm sure this happens, yes. But, that's not what's going on here, IMHO. Asking a person to traverse and modify a linked-list (a very common problem) or to impl

by hcatlin 10y ago

I'm sure this happens, yes. But, that's not what's going on here, IMHO. Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job' Most of these interviews are more like math problems than anything a practical developer would encounter. Shit, if these interviews were "What do you think of node?" or "What is Go's concurrency model?" I think experienced people would do fine.

fecak 10y ago
I think my words may have been clumsy. My reference to "tech outside their job" was meant more about having relevant skills to a current job market (marketability), not the interview itself.
ashwinaj 10y ago
> Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job' No. No one in their daily jobs implements a linked list or B-Tree. There are predefined libraries in the languages or a user created library that people use. Do you really think every person in the company has his/her own version of a linked list in the same code base? This is a fallacy perpetuated time and again. (I'm not against these type of questions, but they don't represent someone's true ability) Building a product, app, project requires application of this knowledge: eg., I need to design a distributed data store, should I use hash map? What about collisions? Should the collisions be resolved by chaining (linked List) or another map? What kind of data am I storing? Can that be exploited to make this more efficient, synchronization of data across nodes (?), etc.. Many of these interviews completely overlook someone's design ability and harp on some straightforward (and some obscure) topics which IMO has little to no co-relation to someone's ability as a software engineer.
- mathgenius 10y ago
  > No one in their daily jobs implements a linked list or B-Tree. Counter case: HFT. Those guys really do implement this stuff. Again and again.
  - Terr_ 10y ago
    Which is why it's an outlier.
- thecrazyone 10y ago
  this, so this. Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done. I find the processes in a large company rather robotic (note: we're a startup, so my views might be biased).
  - RandomOpinion 10y ago
    >Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done. A person who can only use a pre-made wheel is a technician (regardless of how ostentatious their job title may be). A person who can invent the wheel on demand can also usually invent any other type of rolling mechanism one might encounter a need for and that makes that person a full-fledged engineer. No value judgement of either person is implied; it's simply a statement of capability. Which type of person is needed depends on the company and the position but it is becoming increasingly clear that the two roles in software are separate, just as they are in other engineering disciplines.
ubernostrum 10y ago
Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job' Yes, it is. More to the point, it's built-in bias toward recent college graduates. Once someone's actually been out in the real world programming for several years, any space in their brain's metaphorical working set that was ever dedicated to remembering how to do this stuff has long since been paged out in favor of the actual day-to-day knowledge they need to do their job. Implementing basic data structures and algorithms is not part of what they need to do their job; that stuff's already provided by the platforms they use. So when you get to the interview, if you just put someone on the spot and ask them to do one of these things, you're inherently biasing toward an inexperienced recent college graduate who will have this stuff close to the top of their head (on account of having just done it in school and not yet swapped it out of working memory through time on the job). Which is in turn why there are now books you study -- as an already-qualified programmer -- in order to freshen your memory and ability to quickly regurgitate problems that have nothing whatsoever to do with your day-to-day work, in order to be able to perform them on command in interviews.
- ktRolster 10y ago
  I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems. If you have trouble with those, I'm going to really wonder if your programming skills are really very good to begin with.
  - ubernostrum 10y ago
    Those are bad examples, but real interview questions tend to be "implement from scratch, live and without reference to any materials, these things you've forgotten about because you could take them for granted for such a long time". Also these days the trendy interview problem is longest common subsequence, which ends up testing "how recently did you review dynamic-programming techniques", not "can you code".
  - richmarr 10y ago
    > I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems I'll be honest, this is indistinguishable from "I am good at X and I'm great therefore X is a good measure of ability". Maybe worth rephrasing
VLM 10y ago
The problem is its possible to run a B-tree implementation and see if the unit tests pass or non-technical interviewers can compare the official solution to what the candidate is talking about fairly easily. I've never used Go, don't really plan to unless I have to, nothing wrong with it just not my area of expertise and I'm busy with other toys although I'm sure its a very nice language, and if I went up against a non-technical or technically weak interviewer (aka almost all of them) I could probably BS my way thru based on what I do know about concurrency in general. Although after decades of experience, the reason why I'm not still programming in 6502/Z80 assembler is I'm good at that whole "BS my way thru till I'm an actual expert" thing, so maybe I'm talking myself into agreeing for non obvious reason! BSing skill is under-rated. If you can't BS your way thru something that you don't entirely understand (because you're lazy), then when you're at the cutting edge developing or debugging you'll have trouble BSing about stuff that no one on the planet understands. Not all the worlds problems have a stack overflow question or a script reader at a support hotline, and how you deal with that gut check says a lot.
- collyw 10y ago
  Actually BSing in tech makes you look very poor if you don't come out with a convincing answer. (I listened to a training video given by a Marketing Cloud consultancy at my work. Someone asked "what is FTP" after seeing that as an option to upload files. Lots waffle including "the cloud" and no actual answer. The person asking the question was no wiser, and my opinion of the consultant went way down).

by hcatlin 10y ago

fecak 10y ago

I think my words may have been clumsy. My reference to "tech outside their job" was meant more about having relevant skills to a current job market (marketability), not the interview itself.

ashwinaj 10y ago

> Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job' No. No one in their daily jobs implements a linked list or B-Tree. There are predefined libraries in the languages or a user created library that people use. Do you really think every person in the company has his/her own version of a linked list in the same code base? This is a fallacy perpetuated time and again. (I'm not against these type of questions, but they don't represent someone's true ability) Building a product, app, project requires application of this knowledge: eg., I need to design a distributed data store, should I use hash map? What about collisions? Should the collisions be resolved by chaining (linked List) or another map? What kind of data am I storing? Can that be exploited to make this more efficient, synchronization of data across nodes (?), etc.. Many of these interviews completely overlook someone's design ability and harp on some straightforward (and some obscure) topics which IMO has little to no co-relation to someone's ability as a software engineer.

mathgenius 10y ago
> No one in their daily jobs implements a linked list or B-Tree. Counter case: HFT. Those guys really do implement this stuff. Again and again.
- Terr_ 10y ago
  Which is why it's an outlier.
thecrazyone 10y ago
this, so this. Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done. I find the processes in a large company rather robotic (note: we're a startup, so my views might be biased).
- RandomOpinion 10y ago
  >Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done. A person who can only use a pre-made wheel is a technician (regardless of how ostentatious their job title may be). A person who can invent the wheel on demand can also usually invent any other type of rolling mechanism one might encounter a need for and that makes that person a full-fledged engineer. No value judgement of either person is implied; it's simply a statement of capability. Which type of person is needed depends on the company and the position but it is becoming increasingly clear that the two roles in software are separate, just as they are in other engineering disciplines.

ubernostrum 10y ago

Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job' Yes, it is. More to the point, it's built-in bias toward recent college graduates. Once someone's actually been out in the real world programming for several years, any space in their brain's metaphorical working set that was ever dedicated to remembering how to do this stuff has long since been paged out in favor of the actual day-to-day knowledge they need to do their job. Implementing basic data structures and algorithms is not part of what they need to do their job; that stuff's already provided by the platforms they use. So when you get to the interview, if you just put someone on the spot and ask them to do one of these things, you're inherently biasing toward an inexperienced recent college graduate who will have this stuff close to the top of their head (on account of having just done it in school and not yet swapped it out of working memory through time on the job). Which is in turn why there are now books you study -- as an already-qualified programmer -- in order to freshen your memory and ability to quickly regurgitate problems that have nothing whatsoever to do with your day-to-day work, in order to be able to perform them on command in interviews.

ktRolster 10y ago
I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems. If you have trouble with those, I'm going to really wonder if your programming skills are really very good to begin with.
- ubernostrum 10y ago
  Those are bad examples, but real interview questions tend to be "implement from scratch, live and without reference to any materials, these things you've forgotten about because you could take them for granted for such a long time". Also these days the trendy interview problem is longest common subsequence, which ends up testing "how recently did you review dynamic-programming techniques", not "can you code".
- richmarr 10y ago
  > I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems I'll be honest, this is indistinguishable from "I am good at X and I'm great therefore X is a good measure of ability". Maybe worth rephrasing

VLM 10y ago

The problem is its possible to run a B-tree implementation and see if the unit tests pass or non-technical interviewers can compare the official solution to what the candidate is talking about fairly easily. I've never used Go, don't really plan to unless I have to, nothing wrong with it just not my area of expertise and I'm busy with other toys although I'm sure its a very nice language, and if I went up against a non-technical or technically weak interviewer (aka almost all of them) I could probably BS my way thru based on what I do know about concurrency in general. Although after decades of experience, the reason why I'm not still programming in 6502/Z80 assembler is I'm good at that whole "BS my way thru till I'm an actual expert" thing, so maybe I'm talking myself into agreeing for non obvious reason! BSing skill is under-rated. If you can't BS your way thru something that you don't entirely understand (because you're lazy), then when you're at the cutting edge developing or debugging you'll have trouble BSing about stuff that no one on the planet understands. Not all the worlds problems have a stack overflow question or a script reader at a support hotline, and how you deal with that gut check says a lot.

collyw 10y ago
Actually BSing in tech makes you look very poor if you don't come out with a convincing answer. (I listened to a training video given by a Marketing Cloud consultancy at my work. Someone asked "what is FTP" after seeing that as an option to upload files. Lots waffle including "the cloud" and no actual answer. The person asking the question was no wiser, and my opinion of the consultant went way down).