A rant about job interviews...
-
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.
-
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
1/2 yes, 1/2 no. I'd probably still want to work at Amazon and Google, but AutoByTel and Western Dental? Probably Not So Much :).
-
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.
Yeah, I'll admit, I haven't invented anything entirely new and different and I don't have any patents. Like you said, all the data structures are pretty much written for you. That guy at Google who interviewed me and turned me down because I wasn't super familiar with the skip list? Great! I'd be willing to bet he googled C# skip list implementation or found one in another language and ported it. He certainly didn't invent the data structure.
-
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.
Haha :), yeah, I guess I am blaming it on "stupid" questions. I guess if people start to ask me stuff I don't know, I get all nervous and it comes out in my voice. I certainly don't have a 100% hit rate in my interviews like you do though. Its just not something everybody excels at. I'm great / expert at coding, but have crumbled a lot during interviews.
-
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
newkie wrote:
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.
I've never had any complaints about my work. Gotten a few complaints that I am too detail oriented a few times over the years :).
newkie wrote:
Ask a half dozen probing questions from a list of 50 which
This is where interviews fall apart. You are asking a "stock question" and expecting a "stock answer".
newkie wrote:
A series of quick-fire .NET / DB questions
I wouldn't be able to answer some of those cuz I'm not a web guy.
newkie wrote:
However what niggles me is you mentioned if the difference in performance between two approaches was 59min vs. 60min who cares? I do. Unless you were consistently making clear your senior qualities of managing cost and time I would be concerned with that attitude.
Sorry, I gotta disagree here. This is a value-add / bang for the buck situation. If it takes me 4hrs of coding to shave off 1 minute (1.6%), I'd question the value of the change. Add in QA time, testing, etc. If it takes 10 minutes to make the change, sure, I'd do it... I think you'll find that you'd get in trouble with most managers for not having your priorities straight if you spent 4hrs shaving 1minute off a 60min process :).
-
Haha :), yeah, I guess I am blaming it on "stupid" questions. I guess if people start to ask me stuff I don't know, I get all nervous and it comes out in my voice. I certainly don't have a 100% hit rate in my interviews like you do though. Its just not something everybody excels at. I'm great / expert at coding, but have crumbled a lot during interviews.
You probably did not know that once you get selected for an in-person interview, they already think you are qualified. I learned about the "shut up and let the interviewer talk" bit when I took my very first flight test back in the stone age. To become a pilot, even a private pilot requires three tests; The written test, the aural Test, and the practical test. My first flight instructor when preparing me for the aural and flight test said; "If the examiner is talking during the aural part, let him keep talking. That way, you won't give him any wrong answers." This worked for my Private license and also for my instrument rating and also for my Commercial test. All three examiners thought I was brilliant because I never gave them any wrong answers. I also never gave them ANY answers! I just let them talk and talk and convince themselves that I was qualified. Most of us, including me, know very little about a project before we start. We have a basic understanding of the use of certain tools, some understanding of broad technical issues, but we do not know anything about "name your project." When I helped design Analogic's first CAT Scanner, I had no clue how they worked. In fact, my lack of knowledge of the subject helped me create some new innovation leading to one of my patents. Do not be afraid of new technology. You will learn it as needed while getting paid in the process! One of my best mentors was Bernard Gordon (Bernie to his engineers). He was Analogic's founder. He emphasized what he called intellectual honesty. It was okay to tell him, "I don't know" as long as it was followed by. "I'll find out." engineering, including software engineering is a lifetime pursuit. You even get better with age in spite of the fact you might forget more than you learn. You start to understand that nobody knows how to write that code better than you, even though you do not (yet) have a clue how to create that algorithm. Lessee... What the 'ell is convolution?
-
Yeah, I'll admit, I haven't invented anything entirely new and different and I don't have any patents. Like you said, all the data structures are pretty much written for you. That guy at Google who interviewed me and turned me down because I wasn't super familiar with the skip list? Great! I'd be willing to bet he googled C# skip list implementation or found one in another language and ported it. He certainly didn't invent the data structure.
In my humble opinion, you oughtta know about skip lists. You should have learned about them in Data Structures class. You need to know their average and worst-case performance, and generally how they're built. But you don't need to know how to code them; that's what the internet and standard libraries are for. I've ranted at length about coding tests here. If you've been working for 10 years, you may be a little rusty. But google warned you (didn't they? They sent me an email about it) to brush up on your data structures before the interview. Here is some advice on how to focus your attention when reviewing your data structures. It happens so often at google that good people fail an interview that they will interview you over and over. Wait three months and apply again.
-
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.
I disagree. People hiring software engineers are obsessively focused on detecting posers. There is no reason for five hours of coding tests, it shows an embarrassing lack of coordination on the part of the interview process. One test is usually enough to find out if you can code. These days, by the time you arrive at the in-house, you've probably already been subjected to one or more coding tests. Yeah, if you make the in-house, it means they didn't find a reason to reject you. But most interviews are still more focused on coding skills than on human skills. They are more focused on weeding out than on hiring. This seems very broken to me. It seems to me that the software world is becoming stratified into managers who want to keep all power and creativity, and coding monkeys, expected to keep their heads down doing just exactly what they're told. I don't want to believe this is down to the declining average I.Q. of managers. I want to think that something about the world has changed so that this is a successful management technique. But I can't think of any good reason that explains it.