A rant about job interviews...
-
harold aptroot wrote:
http://msdn.microsoft.com/en-us/library/f7fta44c.aspx[^], remarks section.
Yes it kind of sucks, but that's not my point - I'm just saying, "yes .NET has a tree somewhere hidden inside it".Well, I'll be, that is what it says. I dunno what its problem is then, cuz that is the gosh darnest slowest data structure I've ever seen in .NET.
harold aptroot wrote:
How would you use a hashmap to create huffman codes? (edit: ok obviously you can do that, but I mean "with a dictionary replacing the (implicit) tree")
I don't :). I use .NET's built in compression stuff :). Anyways, ok, so .NET uses a tree internally. I've written plenty of UIs that have used tree controls, but never actually store the underlying data in a tree structure. I've also worked on a lot of back-end stuff and never had to implement my own tree.
SledgeHammer01 wrote:
I use .NET's built in compression stuff
It sucks. Badly.[^] Besides it has nothing to help with huffman coding - the only thing it's actually useful for is inflating some deflated data (and deflating if you don't care about the compression ratio). So it doesn't even solve the problem.
SledgeHammer01 wrote:
I've also worked on a lot of back-end stuff and never had to implement my own tree.
That's some sneaky wording there, whose tree did you use?
-
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
Even worse in my opinion is the long, multiple-interview processes that some of the more "desirable" employers have. It's not uncommon for there to be two phone screens, followed by a site visit, and then by another site visit or a business dinner. On at least two occassions, I have been in the midst of such a process, but have chosen to accept another offer from a company with a less convoluted hiring process. I really think these processes are set up to hire recent college graduates still living in a dormitory or with their parents. Who else has time for dinners, plane trips, interminable hair-splitting about Big O, etc.?
-
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
Quote:
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...
That's no guarantee... I've met several people who meet that exact description and have absolutely no idea what they're doing. They just hold their jobs for those 4 or 5 years because their managers know even less than they do. :rolleyes:
Be The Noise
-
Even worse in my opinion is the long, multiple-interview processes that some of the more "desirable" employers have. It's not uncommon for there to be two phone screens, followed by a site visit, and then by another site visit or a business dinner. On at least two occassions, I have been in the midst of such a process, but have chosen to accept another offer from a company with a less convoluted hiring process. I really think these processes are set up to hire recent college graduates still living in a dormitory or with their parents. Who else has time for dinners, plane trips, interminable hair-splitting about Big O, etc.?
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.
-
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.
Congrats on making it that far, however. Can you say what the potential position was?
The difficult we do right away... ...the impossible takes slightly longer.
-
Congrats on making it that far, however. Can you say what the potential position was?
The difficult we do right away... ...the impossible takes slightly longer.
Yeah, it was 2yrs ago. Google, much like Amazon doesn't hire you for a particular position. They only want generalists. "Generalists" to both of them basically means you are an AWESOME off the cuff algorithm guy. Big O notation, data structures, algorithm analysis, etc. They don't even care what language you use. They think if you are good at the Big O & data structures, you can do it in any language. None of the interviewers asked me anything about databases, UI design, MFC, browser plug-ins, etc (the actual description of the job I applied for). You'll notice most of their current job descriptions are just generic ads for software engineers. Seems like its mostly a Linux / Java shop now.
-
Congrats on making it that far, however. Can you say what the potential position was?
The difficult we do right away... ...the impossible takes slightly longer.
-
I can't speak for the OP, but every time I've tried to get on with one of those high-prestige tech companies, the job title has been "Software Engineer in Test".
I read that as "Software Engineer in Jest" :laugh:
The difficult we do right away... ...the impossible takes slightly longer.
-
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.
