A rant about job interviews...
-
Am I the only one who is annoyed by techie interviews? If you are in sales / marketing, your job interview is basically one where they see if your personality will mesh with the manager / team / company. If you don't make quota they get rid of you. If you are a manager / project manager / program manager / scrum master / human resources, etc. those too are generally personality fit questions. If you are in IT (network admin, desktop support, tech support, etc), they might ask you a few technical questions, or put you on a "test call". So why is it that software engineer interviews are "brutal"? I've been on some where you have a gang of 5+ people just hurling questions at you non stop til you are forced into the fetal position sucking your thumb and crying. I've been a software engineer for 17 yrs and have worked at several jobs for 4 or 5 yrs, so obviously I know what I'm doing, but I just had a phone screen where I was ridiculously hammered with big O questions and low level data structure questions. Ridiculous. When was the last time I wrote my own data structure and didn't use one provided by .NET? Probably 6 to 10yrs ago!! When was the last time I cared about big O notation? Probably 20 yrs ago in school! Big O notation doesn't have much use in the real world. I can easily write O(n ^ 3) that runs in 1ms vs. O(1) that takes an hour. Me personally, I generally write code using my first approach and then test it with real data... if it runs too slow, I'll optimize it. The process of optimizing is almost NEVER calculating the big O and unwinding complexity... its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature. How about asking questions that are actually relevant to the job??? I had one guy turn me down because I couldn't go on the white board and write a regex to validate an email address off the top of my head (and I don't mean just something simple like a@a.com, he wanted almost full RFC spec validation). Now I get it... maybe you want to make sure the guy has good designs, etc. Unless he's an architect or team lead, I've almost never seen a mid level or even a sr guy "design" anything important. Its always by the principal guys and the architects and the lower level guys are just coders. Ok, so you don't want crappy code written? Unless you don't outsource, that ain't gonna happen. I know a guy who is much better then me at coming up with off the top of his head algorithms, but you would never want to use his code in production becaus
Agreed. When I first started out, I worked with a guy who could sling code that was damn near perfect. Everyone loved his code. If you start quizzing him on things? He clammed right up and couldn't answer a thing. He would be stamemring and not making sense. Some people just can't handle the interrogation, nor should we. Basic concepts is fine, but I couldn't write a regex without a tool to help me to save my life.
-
Am I the only one who is annoyed by techie interviews? If you are in sales / marketing, your job interview is basically one where they see if your personality will mesh with the manager / team / company. If you don't make quota they get rid of you. If you are a manager / project manager / program manager / scrum master / human resources, etc. those too are generally personality fit questions. If you are in IT (network admin, desktop support, tech support, etc), they might ask you a few technical questions, or put you on a "test call". So why is it that software engineer interviews are "brutal"? I've been on some where you have a gang of 5+ people just hurling questions at you non stop til you are forced into the fetal position sucking your thumb and crying. I've been a software engineer for 17 yrs and have worked at several jobs for 4 or 5 yrs, so obviously I know what I'm doing, but I just had a phone screen where I was ridiculously hammered with big O questions and low level data structure questions. Ridiculous. When was the last time I wrote my own data structure and didn't use one provided by .NET? Probably 6 to 10yrs ago!! When was the last time I cared about big O notation? Probably 20 yrs ago in school! Big O notation doesn't have much use in the real world. I can easily write O(n ^ 3) that runs in 1ms vs. O(1) that takes an hour. Me personally, I generally write code using my first approach and then test it with real data... if it runs too slow, I'll optimize it. The process of optimizing is almost NEVER calculating the big O and unwinding complexity... its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature. How about asking questions that are actually relevant to the job??? I had one guy turn me down because I couldn't go on the white board and write a regex to validate an email address off the top of my head (and I don't mean just something simple like a@a.com, he wanted almost full RFC spec validation). Now I get it... maybe you want to make sure the guy has good designs, etc. Unless he's an architect or team lead, I've almost never seen a mid level or even a sr guy "design" anything important. Its always by the principal guys and the architects and the lower level guys are just coders. Ok, so you don't want crappy code written? Unless you don't outsource, that ain't gonna happen. I know a guy who is much better then me at coming up with off the top of his head algorithms, but you would never want to use his code in production becaus
SledgeHammer01 wrote:
The process of optimizing is almost NEVER calculating the big O and unwinding complexity..its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature
that's what you do when you have the best algorithm you can come up with. if you put your O(n^2) Gaussian blur up against my O(1) implementation, you'll lose no matter what you've done to your convolution loops - because i don't have any such loops to optimize. but yeah, i've been on far too many of those 5-on-1 interviews, and i've suffered through some killer phone screens, too. but, those probably weren't jobs i would've enjoyed even if i had passed whatever threshold they were holding me to. if the boss is obnoxious in the interview... well, first impressions and all that.
-
Am I the only one who is annoyed by techie interviews? If you are in sales / marketing, your job interview is basically one where they see if your personality will mesh with the manager / team / company. If you don't make quota they get rid of you. If you are a manager / project manager / program manager / scrum master / human resources, etc. those too are generally personality fit questions. If you are in IT (network admin, desktop support, tech support, etc), they might ask you a few technical questions, or put you on a "test call". So why is it that software engineer interviews are "brutal"? I've been on some where you have a gang of 5+ people just hurling questions at you non stop til you are forced into the fetal position sucking your thumb and crying. I've been a software engineer for 17 yrs and have worked at several jobs for 4 or 5 yrs, so obviously I know what I'm doing, but I just had a phone screen where I was ridiculously hammered with big O questions and low level data structure questions. Ridiculous. When was the last time I wrote my own data structure and didn't use one provided by .NET? Probably 6 to 10yrs ago!! When was the last time I cared about big O notation? Probably 20 yrs ago in school! Big O notation doesn't have much use in the real world. I can easily write O(n ^ 3) that runs in 1ms vs. O(1) that takes an hour. Me personally, I generally write code using my first approach and then test it with real data... if it runs too slow, I'll optimize it. The process of optimizing is almost NEVER calculating the big O and unwinding complexity... its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature. How about asking questions that are actually relevant to the job??? I had one guy turn me down because I couldn't go on the white board and write a regex to validate an email address off the top of my head (and I don't mean just something simple like a@a.com, he wanted almost full RFC spec validation). Now I get it... maybe you want to make sure the guy has good designs, etc. Unless he's an architect or team lead, I've almost never seen a mid level or even a sr guy "design" anything important. Its always by the principal guys and the architects and the lower level guys are just coders. Ok, so you don't want crappy code written? Unless you don't outsource, that ain't gonna happen. I know a guy who is much better then me at coming up with off the top of his head algorithms, but you would never want to use his code in production becaus
I actually disagree with your opinion about Big O notation for the most part. Ultimately, Big O is useful for keeping a context of how things behave as you put 'real world data' against it. If you're keeping a list of customers and you're expecting to have a few thousand in it, you probably want to use some sort of hash if you're going to perform lookups on it regularly. There isn't often a one size fits all solution to every problem, but Big O is just one measure of how a problem will behave. I believe they were just attempting to gauge how effective you are at identifying the right tool for the right job. I've also heard that people use the interview tactics you described to weed out people who present themselves as an expert in something they're not. Perhaps, that is why they treated you as such, they wanted to probe the extent of your knowledge. Ultimately, the great thing about interviews is this. You have the choice to turn them down, just as much as they do you.
-
Am I the only one who is annoyed by techie interviews? If you are in sales / marketing, your job interview is basically one where they see if your personality will mesh with the manager / team / company. If you don't make quota they get rid of you. If you are a manager / project manager / program manager / scrum master / human resources, etc. those too are generally personality fit questions. If you are in IT (network admin, desktop support, tech support, etc), they might ask you a few technical questions, or put you on a "test call". So why is it that software engineer interviews are "brutal"? I've been on some where you have a gang of 5+ people just hurling questions at you non stop til you are forced into the fetal position sucking your thumb and crying. I've been a software engineer for 17 yrs and have worked at several jobs for 4 or 5 yrs, so obviously I know what I'm doing, but I just had a phone screen where I was ridiculously hammered with big O questions and low level data structure questions. Ridiculous. When was the last time I wrote my own data structure and didn't use one provided by .NET? Probably 6 to 10yrs ago!! When was the last time I cared about big O notation? Probably 20 yrs ago in school! Big O notation doesn't have much use in the real world. I can easily write O(n ^ 3) that runs in 1ms vs. O(1) that takes an hour. Me personally, I generally write code using my first approach and then test it with real data... if it runs too slow, I'll optimize it. The process of optimizing is almost NEVER calculating the big O and unwinding complexity... its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature. How about asking questions that are actually relevant to the job??? I had one guy turn me down because I couldn't go on the white board and write a regex to validate an email address off the top of my head (and I don't mean just something simple like a@a.com, he wanted almost full RFC spec validation). Now I get it... maybe you want to make sure the guy has good designs, etc. Unless he's an architect or team lead, I've almost never seen a mid level or even a sr guy "design" anything important. Its always by the principal guys and the architects and the lower level guys are just coders. Ok, so you don't want crappy code written? Unless you don't outsource, that ain't gonna happen. I know a guy who is much better then me at coming up with off the top of his head algorithms, but you would never want to use his code in production becaus
That's the sign of an interviewer who just wants to show how clever they are compared to everybody else. If you ever get interviewed by somebody like this, run away - they will be an absolute nightmare to work with. It's fine to ask a probing question as long as it's relavent, but offer hints as to the type of answer you're looking for.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Agreed. When I first started out, I worked with a guy who could sling code that was damn near perfect. Everyone loved his code. If you start quizzing him on things? He clammed right up and couldn't answer a thing. He would be stamemring and not making sense. Some people just can't handle the interrogation, nor should we. Basic concepts is fine, but I couldn't write a regex without a tool to help me to save my life.
Yeah, that's exactly where I fail. I can write great code and have good designs and my apps almost never crash because I test them a lot myself before giving them to QA. But the interrogation from 5 guys at once? I definitely get all nervous and start stammering.
-
Am I the only one who is annoyed by techie interviews? If you are in sales / marketing, your job interview is basically one where they see if your personality will mesh with the manager / team / company. If you don't make quota they get rid of you. If you are a manager / project manager / program manager / scrum master / human resources, etc. those too are generally personality fit questions. If you are in IT (network admin, desktop support, tech support, etc), they might ask you a few technical questions, or put you on a "test call". So why is it that software engineer interviews are "brutal"? I've been on some where you have a gang of 5+ people just hurling questions at you non stop til you are forced into the fetal position sucking your thumb and crying. I've been a software engineer for 17 yrs and have worked at several jobs for 4 or 5 yrs, so obviously I know what I'm doing, but I just had a phone screen where I was ridiculously hammered with big O questions and low level data structure questions. Ridiculous. When was the last time I wrote my own data structure and didn't use one provided by .NET? Probably 6 to 10yrs ago!! When was the last time I cared about big O notation? Probably 20 yrs ago in school! Big O notation doesn't have much use in the real world. I can easily write O(n ^ 3) that runs in 1ms vs. O(1) that takes an hour. Me personally, I generally write code using my first approach and then test it with real data... if it runs too slow, I'll optimize it. The process of optimizing is almost NEVER calculating the big O and unwinding complexity... its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature. How about asking questions that are actually relevant to the job??? I had one guy turn me down because I couldn't go on the white board and write a regex to validate an email address off the top of my head (and I don't mean just something simple like a@a.com, he wanted almost full RFC spec validation). Now I get it... maybe you want to make sure the guy has good designs, etc. Unless he's an architect or team lead, I've almost never seen a mid level or even a sr guy "design" anything important. Its always by the principal guys and the architects and the lower level guys are just coders. Ok, so you don't want crappy code written? Unless you don't outsource, that ain't gonna happen. I know a guy who is much better then me at coming up with off the top of his head algorithms, but you would never want to use his code in production becaus
I hate when people interview candidates to have them fail miserably; and if you pass the interview, you are so pissed off that you wonder why you do not accept the offers. Remember, that something the way you answer questions will say more about you than the actual answer. And I don't agree with your assessment of the Big O relevancy. ( I think C Losinger sums it up nicely).
Watched code never compiles.
-
SledgeHammer01 wrote:
The process of optimizing is almost NEVER calculating the big O and unwinding complexity..its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature
that's what you do when you have the best algorithm you can come up with. if you put your O(n^2) Gaussian blur up against my O(1) implementation, you'll lose no matter what you've done to your convolution loops - because i don't have any such loops to optimize. but yeah, i've been on far too many of those 5-on-1 interviews, and i've suffered through some killer phone screens, too. but, those probably weren't jobs i would've enjoyed even if i had passed whatever threshold they were holding me to. if the boss is obnoxious in the interview... well, first impressions and all that.
Chris Losinger wrote:
that's what you do when you have the best algorithm you can come up with. if you put your O(n^2) Gaussian blur up against my O(1) implementation, you'll lose no matter what you've done to your convolution loops - because i don't have any such loops to optimize.
Well, yeah, I didn't mean to imply that a O(n ^ 2) would always (or even regularly) beat a O(1) algorithm. I meant to say that it is a) a possibility and runtime benchmarking is more important b) sometimes a complete waste of time to unroll complexity since in the real world that may translate to 1 second or 1 minute over 1 million whatevers. If the process takes 1hr using one algorithm and 59m using another, who cares? If you can get it down to 30minutes? Yeah, thats something.
Chris Losinger wrote:
but yeah, i've been on far too many of those 5-on-1 interviews, and i've suffered through some killer phone screens, too. but, those probably weren't jobs i would've enjoyed even if i had passed whatever threshold they were holding me to. if the boss is obnoxious in the interview... well, first impressions and all that.
You'll find they do these at a lot of companies that you would want to work at... say Google and Amazon. Had it done to me for an MFC job at Broadcom where the manager actually asked me if I would be ok with being considered "scum" since the hardware guys are the rockstars there. Haha.
-
I actually disagree with your opinion about Big O notation for the most part. Ultimately, Big O is useful for keeping a context of how things behave as you put 'real world data' against it. If you're keeping a list of customers and you're expecting to have a few thousand in it, you probably want to use some sort of hash if you're going to perform lookups on it regularly. There isn't often a one size fits all solution to every problem, but Big O is just one measure of how a problem will behave. I believe they were just attempting to gauge how effective you are at identifying the right tool for the right job. I've also heard that people use the interview tactics you described to weed out people who present themselves as an expert in something they're not. Perhaps, that is why they treated you as such, they wanted to probe the extent of your knowledge. Ultimately, the great thing about interviews is this. You have the choice to turn them down, just as much as they do you.
Yes, but if you have 1000 customers stored locally in memory, the difference between a hash map and say a linear search is big in the big O world O (1) vs. O(n)... in the real world? You might shave a few hundred milliseconds off. Now if you have a million customers, ok, then theres something :).
-
Am I the only one who is annoyed by techie interviews? If you are in sales / marketing, your job interview is basically one where they see if your personality will mesh with the manager / team / company. If you don't make quota they get rid of you. If you are a manager / project manager / program manager / scrum master / human resources, etc. those too are generally personality fit questions. If you are in IT (network admin, desktop support, tech support, etc), they might ask you a few technical questions, or put you on a "test call". So why is it that software engineer interviews are "brutal"? I've been on some where you have a gang of 5+ people just hurling questions at you non stop til you are forced into the fetal position sucking your thumb and crying. I've been a software engineer for 17 yrs and have worked at several jobs for 4 or 5 yrs, so obviously I know what I'm doing, but I just had a phone screen where I was ridiculously hammered with big O questions and low level data structure questions. Ridiculous. When was the last time I wrote my own data structure and didn't use one provided by .NET? Probably 6 to 10yrs ago!! When was the last time I cared about big O notation? Probably 20 yrs ago in school! Big O notation doesn't have much use in the real world. I can easily write O(n ^ 3) that runs in 1ms vs. O(1) that takes an hour. Me personally, I generally write code using my first approach and then test it with real data... if it runs too slow, I'll optimize it. The process of optimizing is almost NEVER calculating the big O and unwinding complexity... its usually moving expensive calls out of the loop or fixing a stored proc or something of that nature. How about asking questions that are actually relevant to the job??? I had one guy turn me down because I couldn't go on the white board and write a regex to validate an email address off the top of my head (and I don't mean just something simple like a@a.com, he wanted almost full RFC spec validation). Now I get it... maybe you want to make sure the guy has good designs, etc. Unless he's an architect or team lead, I've almost never seen a mid level or even a sr guy "design" anything important. Its always by the principal guys and the architects and the lower level guys are just coders. Ok, so you don't want crappy code written? Unless you don't outsource, that ain't gonna happen. I know a guy who is much better then me at coming up with off the top of his head algorithms, but you would never want to use his code in production becaus
-
That's the sign of an interviewer who just wants to show how clever they are compared to everybody else. If you ever get interviewed by somebody like this, run away - they will be an absolute nightmare to work with. It's fine to ask a probing question as long as it's relavent, but offer hints as to the type of answer you're looking for.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Haha... I got hired at a place once where it went the other way... it was for an MFC job and I was an expert at it and knew it inside and out because I had worked with the internals for 10+ yrs... they were throwing questions at me for 5hrs non stop and I beat them back without breaking a sweat. When I got hired, one of the guys told me they almost didn't hire me because I was too cocky in the interview. Haha...
-
I hate when people interview candidates to have them fail miserably; and if you pass the interview, you are so pissed off that you wonder why you do not accept the offers. Remember, that something the way you answer questions will say more about you than the actual answer. And I don't agree with your assessment of the Big O relevancy. ( I think C Losinger sums it up nicely).
Watched code never compiles.
Yeah, if you are treated like crap during the interview, you are likely to hate the job and the people from day one. A few months before 9/11, I was laid off and panicked when 9/11 happened that people would stop hiring... interviewed with this one crap hole 10 person company... 3 phone screens + 4 in persons (including one on SATURDAY) + 50% pay CUT. I got turned down. A few weeks later they called me back and said the guy they wanted failed his background check, so I can have the job. Haha... I took it, but only lasted there 3 months due to manager abuse and bitterness.
-
I don't see how you could possibly have avoided trees and graphs for 6 years. They're bound to come up sooner or later, probably sooner. And .NET does not provide them.
harold aptroot wrote:
I don't see how you could possibly have avoided trees and graphs for 6 years. They're bound to come up sooner or later, probably sooner. And .NET does not provide them.
You just nailed it right on the head. .NET does NOT provide trees. You know why? Because they prefer to use Dictionaries. Dictionaries are faster look up (according to big O :)) and simpler. I did implement a B-tree and an AVL tree in C++, but never had a real use for either in my 17yrs. Note: using a tree just for the heck of it is probably not a real use. I'm sure there are real uses for it in some of the higher level graphics algorithms or something like that... but I've never come across them.
-
Yes, but if you have 1000 customers stored locally in memory, the difference between a hash map and say a linear search is big in the big O world O (1) vs. O(n)... in the real world? You might shave a few hundred milliseconds off. Now if you have a million customers, ok, then theres something :).
Right, but that is exactly what they want to know that you understand the basic concepts. Plus, depending on the application, a few hundred milliseconds can add up quick. Especially with the advent of cloud computing, you can get charged for how much CPU you use - little things like that can add up to big costs down the road. It is one of those things that needs to be evaluated in context, with a dash of reality (to taste of course).
-
Yeah, that's exactly where I fail. I can write great code and have good designs and my apps almost never crash because I test them a lot myself before giving them to QA. But the interrogation from 5 guys at once? I definitely get all nervous and start stammering.
Most technical individuals are introverts, so highly charged social situations like an interview typically don't bode well. I would just take it as a challenge to stretch myself, if I felt nervous in such a situation. You have the experience, so you shouldn't be doubting your expertise. So, then its just a matter of overcoming the jitters and having fun with it. Granted, if you're out of work, the 'jitters' may not fully encompass the gravity of the situation. Good luck though.
-
harold aptroot wrote:
I don't see how you could possibly have avoided trees and graphs for 6 years. They're bound to come up sooner or later, probably sooner. And .NET does not provide them.
You just nailed it right on the head. .NET does NOT provide trees. You know why? Because they prefer to use Dictionaries. Dictionaries are faster look up (according to big O :)) and simpler. I did implement a B-tree and an AVL tree in C++, but never had a real use for either in my 17yrs. Note: using a tree just for the heck of it is probably not a real use. I'm sure there are real uses for it in some of the higher level graphics algorithms or something like that... but I've never come across them.
Actually there is SortedDistionary, which is some kind of binary search tree.. But I don't mean binary search trees. Just any plain old tree. Here's the actual why: they're trivial to implement. Have a class that has a/several member(s) of its own type? Congratulations, you have a graph and possibly a tree, depending on the layout of the graph. Actually I suppose you might call it a tree/graph even if the nodes are not of the same types. Then if you use OOP at all you will have a graph/tree. But IMO that doesn't really count here. It wouldn't really be a data structure. Hashmaps aren't faster or simpler than trees - they're unrelated and therefore not comparable.
-
Actually there is SortedDistionary, which is some kind of binary search tree.. But I don't mean binary search trees. Just any plain old tree. Here's the actual why: they're trivial to implement. Have a class that has a/several member(s) of its own type? Congratulations, you have a graph and possibly a tree, depending on the layout of the graph. Actually I suppose you might call it a tree/graph even if the nodes are not of the same types. Then if you use OOP at all you will have a graph/tree. But IMO that doesn't really count here. It wouldn't really be a data structure. Hashmaps aren't faster or simpler than trees - they're unrelated and therefore not comparable.
This is a prime example of knowing .NET and knowing REAL WORLD runtime. If you've ever used SortedDictionary, you'd know its VERY, VERY slow. I don't believe its implemented using a tree. Its much faster to use a regular dictionary and sort it once at the end. How is a hashmap not comparable to a tree? Both store "nodes". Most hashmap operations are O ( 1 ) while a b-tree for example is n log n on the insert. Now, don't get me wrong, I know they offer additional features that the other doesn't, but in terms of general insertion, deletion and searching, the hash map is faster. Hash map is also simpler to implement IMO.
-
This is a prime example of knowing .NET and knowing REAL WORLD runtime. If you've ever used SortedDictionary, you'd know its VERY, VERY slow. I don't believe its implemented using a tree. Its much faster to use a regular dictionary and sort it once at the end. How is a hashmap not comparable to a tree? Both store "nodes". Most hashmap operations are O ( 1 ) while a b-tree for example is n log n on the insert. Now, don't get me wrong, I know they offer additional features that the other doesn't, but in terms of general insertion, deletion and searching, the hash map is faster. Hash map is also simpler to implement IMO.
SledgeHammer01 wrote:
I don't believe its implemented using a tree.
http://msdn.microsoft.com/en-us/library/f7fta44c.aspx[^], remarks section. Yes it kind of sucks, but that's not my point - I'm just saying, "yes .NET has a tree somewhere hidden inside it".
SledgeHammer01 wrote:
How is a hashmap not comparable to a tree?
Because you're still thinking "binary search tree". How would you use a hashmap to create huffman codes? (edit: ok obviously you can do that, but I mean "with a dictionary replacing the (implicit) tree")
-
This is a prime example of knowing .NET and knowing REAL WORLD runtime. If you've ever used SortedDictionary, you'd know its VERY, VERY slow. I don't believe its implemented using a tree. Its much faster to use a regular dictionary and sort it once at the end. How is a hashmap not comparable to a tree? Both store "nodes". Most hashmap operations are O ( 1 ) while a b-tree for example is n log n on the insert. Now, don't get me wrong, I know they offer additional features that the other doesn't, but in terms of general insertion, deletion and searching, the hash map is faster. Hash map is also simpler to implement IMO.
-
SledgeHammer01 wrote:
I don't believe its implemented using a tree.
http://msdn.microsoft.com/en-us/library/f7fta44c.aspx[^], remarks section. Yes it kind of sucks, but that's not my point - I'm just saying, "yes .NET has a tree somewhere hidden inside it".
SledgeHammer01 wrote:
How is a hashmap not comparable to a tree?
Because you're still thinking "binary search tree". How would you use a hashmap to create huffman codes? (edit: ok obviously you can do that, but I mean "with a dictionary replacing the (implicit) tree")
Bah, beaten to the punch. :D
-
SledgeHammer01 wrote:
I don't believe its implemented using a tree.
http://msdn.microsoft.com/en-us/library/f7fta44c.aspx[^], remarks section. Yes it kind of sucks, but that's not my point - I'm just saying, "yes .NET has a tree somewhere hidden inside it".
SledgeHammer01 wrote:
How is a hashmap not comparable to a tree?
Because you're still thinking "binary search tree". How would you use a hashmap to create huffman codes? (edit: ok obviously you can do that, but I mean "with a dictionary replacing the (implicit) tree")
harold aptroot wrote:
http://msdn.microsoft.com/en-us/library/f7fta44c.aspx[^], remarks section.
Yes it kind of sucks, but that's not my point - I'm just saying, "yes .NET has a tree somewhere hidden inside it".Well, I'll be, that is what it says. I dunno what its problem is then, cuz that is the gosh darnest slowest data structure I've ever seen in .NET.
harold aptroot wrote:
How would you use a hashmap to create huffman codes? (edit: ok obviously you can do that, but I mean "with a dictionary replacing the (implicit) tree")
I don't :). I use .NET's built in compression stuff :). Anyways, ok, so .NET uses a tree internally. I've written plenty of UIs that have used tree controls, but never actually store the underlying data in a tree structure. I've also worked on a lot of back-end stuff and never had to implement my own tree.