A rant about job interviews...
-
I read that as "Software Engineer in Jest" :laugh:
The difficult we do right away... ...the impossible takes slightly longer.
-
Yes! I live in Southern California and had an interview with Google (in the local office). Obviously, a desirable place to work. Their interview process is as follows: 1) submit resume <3 **month** wait> 2) "hello from google" email wanting to schedule an HR screen... reply back with your availability for the next 2 weeks... I respond back immediately. <1 **week** wait> 3) get a response from the HR guy scheduling my HR screen for a week and a half out <1.5 **week** wait> 4) 30 minute HR screen asking me mostly useless questions (where did you work last, etc.) <2 week wait> 5) another email from google saying they want to schedule a technical phone screen, reply back with your availability for the next 2 weeks. Again I respond immediately. <2 week wait> 6) get a response from the HR guy scheduling my technical phone screen (1hr) for a week out <1 week wait> 7) technical phone screen... not really brutal at all, kind of just gave me one problem and asked how I would solve it and then delved in deeper <2 week wait> 8) hear back from google, they want to bring me in... except even though I'll be working in an office 5 minutes from my house, the interview must be done at HQ, so they need to know the closest airport and how many days I need to stay, etc. <1 week wait> 9) hear back with my hotel and flight arrangements <2 week wait + have to take 2 days off work> 10) fly up to Northern Cal the night before and stay in the hotel... have to pay for my own rental car that will be re-embursed later on 11) 8 hour interview 12) fly back home All in all, I spent close to 6 **MONTHS** from resume submittal to getting turned down. What an utter and complete waste of time. It took another 1 month to get re-embursed for my expenses. While I obviously would have taken the job, I was still highly annoyed at the long, drawn out procedure. Interviewed with Amazon and didn't get past the phone screen, but that was 2 or 3 weeks for 1 HR screen and 2 tech screens. They responded to my resume after 2 or 3 days.
I actually tried to turn down a Microsoft recruiter one time, saying something like "I don't do well with those long interview processes." They persisted, though, and I eventually did go through a phone screen. I don't remember who ended up turning down whom; in all likelihood, I was already drawing a paycheck elsewhere by the time they even started to think about me. At around the same time, I was going through the Amazon process. They eventually turned me down, as I see it, for being unable to articulate what was really a good solution to the problem I was given. As I remember it, I was asked how I would keep track of available vehicle registration numbers (for what we call "license plates" in the US). I immediately settled on something like a memory allocator. There would be a linked list of "available block" descriptors, e.g. one of them might convey the fact that "numbers 000 000 through 000 099 are available", and it might point to a "next" node indicating that "numbers 001 001 through ZZZ ZZZ are available". This is compact, relatively easy to search within, and so on. I just could not make the interviewer see what I was talking about, though, in spite of his apparent gift for theory, and my previous confidence in my mastery of plain English. I think this really gets at the crux of the problem here: that interviewer had a solution in mind already. Was it as elegant as mine? I don't see how it could have been, although we'll never know. Did what I was trying to tell him finally "click" for him mentally, 4 days later, in the "Playstation Room"? Quite possibly, but none of this does me any good. I don't blame the interviewer; he was a working within a broken system. The proverbial "silver lining" is that there are plenty of people willing to compete with Google, Amazon, etc. in terms of salary. They just don't have the prestige or the Ping-Pong tables.
-
Well, I was out of work for a long time when Google came knocking, so I happily went through the process, but I obviously kept looking. I certainly wouldn't waste 6 months on that when I have a job. The Amazon job fell through (that was from my current search). Got one more company in my current queue. Thats the one I prefered over Amazon anyways. The Amazon job would have meant dumping Windows and moving to Java / Linux. Waiting to do an on site with the other company... got delayed a bit cuz of the holidays :(. I would have taken either opportunity, but I guess Amazon made it easy for me haha... assuming I get the other one.
-
I actually tried to turn down a Microsoft recruiter one time, saying something like "I don't do well with those long interview processes." They persisted, though, and I eventually did go through a phone screen. I don't remember who ended up turning down whom; in all likelihood, I was already drawing a paycheck elsewhere by the time they even started to think about me. At around the same time, I was going through the Amazon process. They eventually turned me down, as I see it, for being unable to articulate what was really a good solution to the problem I was given. As I remember it, I was asked how I would keep track of available vehicle registration numbers (for what we call "license plates" in the US). I immediately settled on something like a memory allocator. There would be a linked list of "available block" descriptors, e.g. one of them might convey the fact that "numbers 000 000 through 000 099 are available", and it might point to a "next" node indicating that "numbers 001 001 through ZZZ ZZZ are available". This is compact, relatively easy to search within, and so on. I just could not make the interviewer see what I was talking about, though, in spite of his apparent gift for theory, and my previous confidence in my mastery of plain English. I think this really gets at the crux of the problem here: that interviewer had a solution in mind already. Was it as elegant as mine? I don't see how it could have been, although we'll never know. Did what I was trying to tell him finally "click" for him mentally, 4 days later, in the "Playstation Room"? Quite possibly, but none of this does me any good. I don't blame the interviewer; he was a working within a broken system. The proverbial "silver lining" is that there are plenty of people willing to compete with Google, Amazon, etc. in terms of salary. They just don't have the prestige or the Ping-Pong tables.
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 :).
-
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
Thank you :) thank you so very much. This rant so made my day. If I could buy you a beer, I would :)
///////////////// -Negative, I am a meat popsicle.
-
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
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!
-
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!
-
This is a prime example of knowing .NET and knowing REAL WORLD runtime. If you've ever used SortedDictionary, you'd know its VERY, VERY slow. I don't believe its implemented using a tree. Its much faster to use a regular dictionary and sort it once at the end. How is a hashmap not comparable to a tree? Both store "nodes". Most hashmap operations are O ( 1 ) while a b-tree for example is n log n on the insert. Now, don't get me wrong, I know they offer additional features that the other doesn't, but in terms of general insertion, deletion and searching, the hash map is faster. Hash map is also simpler to implement IMO.
SledgeHammer01 wrote:
a b-tree for example is n log n on the insert
Just to be pedantic, wouldn't it be closer to log(n) for a single insert? For multiple inserts, it would be closer to m * log(n) (n is the number of total items, m is the number of inserted items).
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
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!"
