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
Some checking is absolutely necessary. We had a guy once who could talk the talk, but not walk the walk. His bad coding influenced the entire team. After that I was asked to do a small tech review to filter out the talkers and figure out if (s)he was a walker. We asked a few basic questions and then let them lose on a small solution for half an hour (MSDN and google enabled !) You would be surprised how little people actually 'walk'... ;) (FYI: the excercise was to read in a txt file, do a simple string manipulation and show in a txtbox, including duration and a progressbar. Simple, basic stuff.)
V.
-
Ah... a list of available ranges. Makes perfect sense to me :). Obviously the interviewer had a different solution in mind. If I had to guess, I think he was looking for the range tree or interval tree data structure :). He probably spent the last month implementing it and was current on it. While I don't care about ping pong tables, etc... I do care about culture. I don't want to work at a place where its all old people or at a place where its all drunk party people, etc. Gotta be able to fit in :).
What about all drunk, partying old people?
-
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
Someone most likely already mentioned this but I have found that most of the people doing the interviews for "programming" jobs, are not programmers. In the trenches programmers have no time to interview so an HR type does it for them based on written specs by the programmer.
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) -
We ask complicated, convoluted questions ( aka silly ) programming questions when we interview, but this is only to gauge how well the interviewee copes with the question and how they well respond given the constraints. It's not a psychological test but just to find out what happens when they're facing an challenging situation. We ask complicated questions about data structures in C# and there will be several right answers ranging from simple to really complex to really well thought. In the end, the judgement is made based on how good the basics are, how fast they can learn, how fast they can adapt and how well they keep their composure through the process. Last but not the least, everyone in my team ( about 3-4 depending on the role ) will have a chat with the candidate to find out how well we think they person might fit in, and that will tilt the scale in the end. A really smart guy who exudes self importance will be lower down the order than the person who's suitably smart and gels well. I have been through interviews which ask seemingly convoluted questions and sometimes a candidate will blow his top and get aggressive or dig a hole and hush up. The dev interviews here aren't a formal process and they are a casual affair. As long as the candidate maintains his wit, we overlook possible wrong answers to the silly questions and really only judge on the important stuff.
SledgeHammer01 wrote:
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.
Any good company would ideally look at every employee as an investment. They may be hiring a code monkey today, but would probably look at him as a lead/manager/architect a few years from now and may want to get an idea if the person shows signs that he/she will fit into their long term goals. After all, the architects will only design the system, but it's the developer who will think about long term effects of the code he/she writes. Ability to read a spec and code will not make one a good developer.
SG Aham Brahmasmi!
SimulationofSai wrote:
We ask complicated, convoluted questions ( aka silly ) programming questions when we interview, but this is only to gauge how well the interviewee copes with the question and how they well respond given the constraints. It's not a psychological test but just to find out what happens when they're facing an challenging situation.
So you are one of those guys that likes to torture people during interviews :). Next time you do that, try thinking how you would like it if you were the interviewee. Honestly, as other people have said in this thread... this can have 2 outcomes: 1) sometimes you just can't get over the bitterness of the interview process and you walk away 2) sometimes you just can't get over the bitterness of the interview process, but take the job anyways for whatever reason and are bitter from day 1 and immediately start looking for a new job (wasting everybodys time and investment in the process).
SimulationofSai wrote:
Ability to read a spec and code will not make one a good developer.
I think you are confusing terms here. That is EXACTLY what makes a good DEVELOPER. It doesn't make a good architect though. Developer = Coder Monkey IMHO.
-
Some checking is absolutely necessary. We had a guy once who could talk the talk, but not walk the walk. His bad coding influenced the entire team. After that I was asked to do a small tech review to filter out the talkers and figure out if (s)he was a walker. We asked a few basic questions and then let them lose on a small solution for half an hour (MSDN and google enabled !) You would be surprised how little people actually 'walk'... ;) (FYI: the excercise was to read in a txt file, do a simple string manipulation and show in a txtbox, including duration and a progressbar. Simple, basic stuff.)
V.
This is kind of another thing that irks me. How many developers use google / msdn during the day? 100%? But during an interview, you are often not even given a PC / compiler, but expected to write it out on the whiteboard. Not a very real world scenario during the job. I'm not opposed to asking somebody technical questions, but really, you can ask them general questions about their experience and if you can't determine from that if they are BSing you without hammering them with technical questions, then I dunno... For example, if a guy says he worked on the core development team for Adobe Photoshop and he didn't seem too knowledgable about graphics algorithms, you'd think it'd be obvious he was BSing you. Thats different from asking him to go up on the board and write out the transformation matrices for a water effect with the sun at 137 degrees :). My boss doesn't care about having elegant code, he only cares about it working. Does it work? Sure... but everybody in the company hates even looking at anything he has touched.
-
Someone most likely already mentioned this but I have found that most of the people doing the interviews for "programming" jobs, are not programmers. In the trenches programmers have no time to interview so an HR type does it for them based on written specs by the programmer.
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011)Really? I find the exact opposite problem. Interviews are conducted by software engineers who have had zero training on how to interview people. The boss just comes by and tells some random guy "hey, check out this guy and see if he is any good!", so naturally the engineer googles "C# interview questions" and wants to go through all of them. Often the people interviewing you are very arrogant if they are hammering you with questions non stop. Another poster said it best: maybe you don't want to work with those kinds of people if thats how you are treated during the interview. Good advise sometimes... I interviewed with a fly by night company and was treated like crap from the first round and went through 5 rounds (including a last minute Friday night call to come in the next day -- SATURDAY!!). Guess what? I was treated like crap as an employee from day one too. I was bitter from the interview process, he was bitter because I was like his 27th choice and the other 26 guys didn't work out, etc. We all pretty much hated each other from the get go. All their fault though.
-
SimulationofSai wrote:
We ask complicated, convoluted questions ( aka silly ) programming questions when we interview, but this is only to gauge how well the interviewee copes with the question and how they well respond given the constraints. It's not a psychological test but just to find out what happens when they're facing an challenging situation.
So you are one of those guys that likes to torture people during interviews :). Next time you do that, try thinking how you would like it if you were the interviewee. Honestly, as other people have said in this thread... this can have 2 outcomes: 1) sometimes you just can't get over the bitterness of the interview process and you walk away 2) sometimes you just can't get over the bitterness of the interview process, but take the job anyways for whatever reason and are bitter from day 1 and immediately start looking for a new job (wasting everybodys time and investment in the process).
SimulationofSai wrote:
Ability to read a spec and code will not make one a good developer.
I think you are confusing terms here. That is EXACTLY what makes a good DEVELOPER. It doesn't make a good architect though. Developer = Coder Monkey IMHO.
SledgeHammer01 wrote:
So you are one of those guys that likes to torture people during interviews :) . Next time you do that, try thinking how you would like it if you were the interviewee.
Nah, not true. I only ask such questions 15-20 minutes after the interview has started and only after I feel the candidate can take it without feeling cornered. And it's just 1 or 2 confusing questions or a puzzle, the rest of the interview is just programming questions or questions about their resume.
SledgeHammer01 wrote:
I think you are confusing terms here. That is EXACTLY what makes a good DEVELOPER. It doesn't make a good architect though. Developer = Coder Monkey IMHO.
I guess the definition varies from company to company I guess. It's a small team and a code monkey will be as good a fit here as cat in a dog house.
SG Aham Brahmasmi!
-
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.
I "enjoyed" one phone interview with a drone from HR who was working through a series of screening questions. The fun started when the accepted answer they were looking for was wrong. Since it was HR, I couldn't give any argument as to why it was wrong. I was moderately happy I did not progress further within the interview process. But one really "fun" interview with an HR drone dealt with the question of "How many Z-80 programs have you written?" I had been programming in assembler languages for multiple CPUs for several years and had just finished a 9 month project on a monster embedded application written for the Z-80, so the truthful answer was "One." No matter how massive the application, no matter how much experience I had, "One" was not an acceptable answer. As I was leaving, I saw an acquaintance in the waiting room. I knew he also had written in Z-80, but his programs tended to be no more than 50 lines of code, so I knew then he would be hired because he would answer "Hundreds", even though they did very little and were written as hobby on his TRS-80. But the worst interview I had was one I didn't know was going to be the worst at the time. The interviewer was going to be my supervisor and was very attentive and respectful all during the interview. Once I was hired, that all vanished, she was the boss and was not going to let me forget it. She was respectful during the interview because we were basically peers and she had no authority over me at that time.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
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
These jerkoff interviewers ,that you described, are doing you a favor. You don't want to work there. And you are finding out early. Move on. -KOT
Mac
-
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
-
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.
"How is a hashmap not comparable to a tree?" A tree grows dynamically as data is added. A hash table must be preallocated. As data is added, the hash table's performance degrades, and all the data must be copied and reinserted into a new larger hash table. The choice depends on the application.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
-
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.
Another reason to be familiar with run-time complexity is to recognize when you have an NP-complete problem which CAN'T be completely solved in a reasonable amount of time. It that situation, you use heuristics to come up with a "good" solution, instead of wasting time trying to write a "perfect" solution.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
-
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
110% agree, you learn a lot more asking questions about previous projects, and general chit chat. It's more important that people know how and where to get information, than to be able to write a regex (simple or otherwise). The answer I would expect is 'would need to look that up to make sure I get it right' - that's the person I want designing/coding for me! But the real test is will they be any good when it's their turn to make the coffee - serious stuff 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
Oh, this is one of my favorite rants. As the software industry has grown from a few thousand practicing developers in 1980 to like 2.5 million today, the average intelligence of developers has declined from something like 130 to (as you'd guess) around 100. That means the chance of interviewing a moron who doesn't know what he is doing is far higher today than it was 25 years ago. Prospective employers must at least attempt to screen out the morons and poseurs to try to find the actual capable developers. In 1980 there were no standard libraries. Everyone knew big-O notation and a long list of algorithms because everyone needed to know. Today we have two tiers of developers; those who just plug standard library code together in long tedious strings of login pages and add/change/delete screens, and a small core who actually do new and different stuff. A prospective employer wants to know which kind of developer you are, so they can set your pay accordingly. So yeah, you don't need to know big-O notation to get a job, only if you want a good job at a top company that won't get outsourced next month. Remember what I said about I.Q.s dropping? Same thing applies to managers (though perhaps from a lower initial level :-)). So you get coding tests, which don't screen very well and which filter out experienced devs who have a few more years between them and their data structures class. It's easy to administer a coding test. It's gratifying to the managers' ego to watch candidates squirm when they know the answer already (sometimes). But you know what? You're selling and they're buying. If that's what they want to buy, that's what you have to sell. Suck it up and deal with it. You get paid rather handsomely to meet their stupid expectations and pass their stupid coding tests.
-
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
For most professionals, if you got selected for a person-to-person interview, it means that they thought you were qualified for the job they had in mind. Now they want to find out if you can "fit" into their environment. The candidate needs to understand that the interview process is hard for both the interviewer and the candidate. If you are asked a question and you do not know the answer, simply explain that you do not know the answer! It is really that simple! If you do know the answer, try to pretend that you are an expert in that particular subject and answer it directly with authority in your voice. When the interviewer is talking, let him/her talk, and talk, and talk. They will convince themselves that you are the ideal candidate. Never interrupt unless you are peeing your pants. It was Benjamin Franklin who once stated; It is better to remain quiet and be thought a fool, then to open ones mouth and remove all doubt!" For the most part, when an interview turns sour it is because the candidate didn't understand the interview process. The candidate blames the loss on "stupid" questions or other incidentals. I am 68 years of age and have been working as an engineer since I was twenty. I have been on both sides of the fence and I have never been on an interview in which I was not ultimately offered a job! Learn about the process and go easy on yourself and the interviewer. You should show up with a knowledge of the company. You should show them how you can help.
-
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")
Lets just say for argument sake, The candidate can't explain Big O notation, or perhaps has never heard of it. Is that a reason to fail the person? If not, then why ARE you asking it? Considering that the resume and background should prove that the person is able to do the job at hand, then the question becomes; How do they fit in our environment? Its nice to be important, but its more important to be nice. The business programmer must adhere to Standard like Source Control, Unit testing, Coding Convention/standards, Rules for deployment, tickets, forms, requests, testers, business people... before he ever gets to show off his precious B-tree sort. And if he cant do the sort, but he does the rest, then I will show him how ONCE, and he will know it forever. We all cannot hope that we all know everything there is to know, in detail. Maybe you know more about Outlook than I do. maybe I know more about Jquery.. it takes a team to build software, not a team of people who all have mastered knowledge of Big O notation in great detail.
Where there's smoke, there's a Blue Screen of death.
-
Lets just say for argument sake, The candidate can't explain Big O notation, or perhaps has never heard of it. Is that a reason to fail the person? If not, then why ARE you asking it? Considering that the resume and background should prove that the person is able to do the job at hand, then the question becomes; How do they fit in our environment? Its nice to be important, but its more important to be nice. The business programmer must adhere to Standard like Source Control, Unit testing, Coding Convention/standards, Rules for deployment, tickets, forms, requests, testers, business people... before he ever gets to show off his precious B-tree sort. And if he cant do the sort, but he does the rest, then I will show him how ONCE, and he will know it forever. We all cannot hope that we all know everything there is to know, in detail. Maybe you know more about Outlook than I do. maybe I know more about Jquery.. it takes a team to build software, not a team of people who all have mastered knowledge of Big O notation in great detail.
Where there's smoke, there's a Blue Screen of death.
-
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 have the unhappy duty of performing many of the phone screenings at my company. I believe in the interview process we have in place, but I don’t relish the prospect of putting a candidate through hell. Whether the process is just or not, there is no joy in seeing a candidate crumble or get upset. After all, the hope is we are going to find a successful candidate and I will be working with this individual possibly for years. I am rooting for the canidate because a hire means less technical screenings I have to give. I would like to run through my screening process to this audience as, like you, I’ve been subjected to horrible interviews. I’d be interested in knowing if the following sounds fair while gathering the necessary information to judge a candidate. Personally, I too feel that I never shine in interviews but typically prove myself to be a MVP in my team or department within 6 months of starting a new job. Nobody likes being asked them, but I believe in the technical questions I ask. I’ve helped shape the technical screening process which is customized for each candidate. It is 30 minute screening which breaks down as follows: • Establish adequate place to talk; put candidate at ease (2 min) • Quick run through CV establishing levels of experience. Ask a few questions about interesting technical accomplishments. Don’t let the candidate talk about a project or company, but press candidate in to divulging details of personal contributions. If candidate persists in talking big picture, skip this step. (6 min) • Ask a half dozen probing questions from a list of 50 which assess the candidate’s soft skills. This set of questions is customized per role and experience. General questions gauge interest in various aspects of technology, pitch general scenario what if’s, and allow candidate to deep-dive on specific technical accomplishments where I encourage details. This is where seniors shine and where juniors don’t but the importance of this section is weighted based on this candidates skills and salary expectations. (12 min) • A series of quick-fire .NET / DB questions ranked by difficulty and sorted by category. Junior candidates do best at these as they sometimes cram them. But this is where they need to shine as they probably won’t have much to offer in the probing questions above. If any particular skills, say threading or Linq, are mentioned above in the CV I make sure to ask questions on that area here. I endeavour to put the candidate at ease by saying no one gets everything righ
-
I "enjoyed" one phone interview with a drone from HR who was working through a series of screening questions. The fun started when the accepted answer they were looking for was wrong. Since it was HR, I couldn't give any argument as to why it was wrong. I was moderately happy I did not progress further within the interview process. But one really "fun" interview with an HR drone dealt with the question of "How many Z-80 programs have you written?" I had been programming in assembler languages for multiple CPUs for several years and had just finished a 9 month project on a monster embedded application written for the Z-80, so the truthful answer was "One." No matter how massive the application, no matter how much experience I had, "One" was not an acceptable answer. As I was leaving, I saw an acquaintance in the waiting room. I knew he also had written in Z-80, but his programs tended to be no more than 50 lines of code, so I knew then he would be hired because he would answer "Hundreds", even though they did very little and were written as hobby on his TRS-80. But the worst interview I had was one I didn't know was going to be the worst at the time. The interviewer was going to be my supervisor and was very attentive and respectful all during the interview. Once I was hired, that all vanished, she was the boss and was not going to let me forget it. She was respectful during the interview because we were basically peers and she had no authority over me at that time.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
Hmm... I've never had HR ask me any serious questions. That would be very odd. Everything I'm usually asked by HR is stuff thats clearly on my resume or salary requirements. I've had quite a few HR people pressure me into interviewing for a job that I had no business interviewing for or had no interest in. One small company was writing a stock market analysis tool and wanted me to contract for 2 weeks. I basically said "no thanks". The HR guy wouldn't take no for answer. Kept begging with me, pleading with me to come in. Even became a bit beligerent. Finally I just went in. Didn't take the job and wasn't offered on either. Haha.
-
Lets just say for argument sake, The candidate can't explain Big O notation, or perhaps has never heard of it. Is that a reason to fail the person? If not, then why ARE you asking it? Considering that the resume and background should prove that the person is able to do the job at hand, then the question becomes; How do they fit in our environment? Its nice to be important, but its more important to be nice. The business programmer must adhere to Standard like Source Control, Unit testing, Coding Convention/standards, Rules for deployment, tickets, forms, requests, testers, business people... before he ever gets to show off his precious B-tree sort. And if he cant do the sort, but he does the rest, then I will show him how ONCE, and he will know it forever. We all cannot hope that we all know everything there is to know, in detail. Maybe you know more about Outlook than I do. maybe I know more about Jquery.. it takes a team to build software, not a team of people who all have mastered knowledge of Big O notation in great detail.
Where there's smoke, there's a Blue Screen of death.
Ok, so a friend of mine can write TCP/IP networking code, algorithms, data structures, etc. all day long without breaking a sweat, but couldn't put together a Windows app to save his life. He wouldn't ask you about how you would write custom controls even if that was the job description. He'd ask you how you'd implement a 3-pronged Bavarian Basket Sort.