9 ms·

I could have written this piece. It hit that close to home. I'm 15 years into my IT career and I can honestly say it's not getting easier. I don't believe it

I could have written this piece. It hit that close to home. I'm 15 years into my IT career and I can honestly say it's not getting easier. I don't believe it's an ageism thing, but just a symtom of something I still cannot put my finger on. I put myself on sabbatical after realizing that my needs were not being met on a regular basis by my job. While I'll allow short-term ROI to be negative, I will never allow my long-term ROI to be negative [3]. I took some time out of my life to spend it with my wife and young daughter, something which I'd never done in my life. It is a blessing. However, in the first week of my sabbatical I get called up for an interview with Expedia for a senior Web dev position. I thought "hey, I've never worked in the USA before, this could be fun". My interviewer was a junior dev who, in the course of the interview, demonstrated that he had very little experience in interviewing (whereas I have conducted > 100 interviews). In the technical phone interview I was asked some esoteric questions about finding the intersection of two integer arrays, what the O-notation would be, and so forth. I came up with some half-assed answers, since it had been years since I thought of those things [1] and since I was tired (on sabbatical) and didn't care if I got the job I asked the interview plainly how often this type of problem comes up in his work routine. His answer: never. Not once. I mentioned to him that I don't understand asking these types of questions, and I have never asked something like that in an interview before. I thanked him for his time, and prompted removed my resume from the application process [2]. To wit, my phone interviewing tactics for a Web dev position contain the following questions: - when I type in a URL in my browser's address bar, press Enter, and then the page appears, tell me what happened technically in as low level as possible. - what are the main verbs used in the HTTP protocol. - something about CSS, JS, <backend language>, HTML - something about how to handle a situation like breakfix, sensitive data leakage, etc. Only after answering all of the questions in the phone interview properly, only then will I invite them in for an in-person interview. However, even an in-person interview doesn't contain stupid programming puzzles or tricks...merely practical examples of things that have happened on the job. [1] In other words, I think of O-notation in the back of my head when I code (loops within loops, etc), but I don't lead with it. [2] Oh my, they did not like this. Granted, I was working through their internal recruiting agency, but you'd think I just called their child ugly or something. [3] That's my corporate-speak coming out. Basically, short-term negative ROI is akin to working really hard and losing a bit of sleep to see a project to completion. Long-term negative ROI is when the hard-work you are doing is not noticed by upper manager and you are passed over for awards, congratulations, and other extrinsic things. Edit: clarity

boyter 13y ago
100% agree. For a web position I have no idea why you would ask them to write a tree parser or binary search algorithm which I experienced not that long ago. Asking about what happens at a low level when entering a URL however is a good question. Or perhaps asking how to do cross domain JSON requests etc...
- weareconvo 13y ago
  Absolutely the best questions to ask in interviews, in my opinion, are open-ended questions. The problem with those, however, is that the interviewer himself has to know enough to be able to correctly judge whether the candidate's answer is a reasonable one. Not only that, there are fewer language barriers when asking some canned binary tree bullshit. So a Chinese programmer doing an interview who barely speaks English can still proudly ask the candidate some crap about Heapsort and feel like he's done his job well.
  - swivelmaster 13y ago
    I've had some good luck with open-ended questions like "Tell me about a time when you had to deal with a scaling issue." How they define "scaling issue" often says just as much as their explanation as to how they solved it. I think I've had to ask for clarification a few times due to the interviewee answering the open-ended question with something I wasn't familiar with, but that's an excellent opportunity to gauge their explanatory skills anyway!
- fooooobar 13y ago
  I don't even know what a tree parser is, but how can anyone not be able to write a binary search algorithm?
- typicalrunt 13y ago
  Asking about what happens at a low level when entering a URL however is a good question. Or perhaps asking how to do cross domain JSON requests etc... The former is a question about fundamentals, whereas the latter is a question about specific implementations. I agree that as a Web developer you should probably need to know what JSONP is, but it's also something that could be learned in about 5 minutes from Google. I like it when a phone interview is basically a conversation. I don't like Spanish Inquisition-style interviews, so I like to start with something and watch it lead to other things. Of course, if the conversation drops dead I can refer to my notes and ask another question. With regard to the URL question, in the past I have allowed the interviewee to answer the URL question as best they can, and the ask questions to cover some of the gaps, and these questions can lead into JSONP handling and its ilk. As an aside and a <rant type=small />, interviewing like this ensures that there is a natural flow and I'm keeping my interviewee's brain jumping between similar contexts. I hate it when I've been interviewed and I'm expected to context switch between algorithms (mergesort) to best practises (SOLID) to programming (implement REST with Jersey+Servlets). And this is all in a 30-60 minute "conversation".

boyter 13y ago

100% agree. For a web position I have no idea why you would ask them to write a tree parser or binary search algorithm which I experienced not that long ago. Asking about what happens at a low level when entering a URL however is a good question. Or perhaps asking how to do cross domain JSON requests etc...

weareconvo 13y ago
Absolutely the best questions to ask in interviews, in my opinion, are open-ended questions. The problem with those, however, is that the interviewer himself has to know enough to be able to correctly judge whether the candidate's answer is a reasonable one. Not only that, there are fewer language barriers when asking some canned binary tree bullshit. So a Chinese programmer doing an interview who barely speaks English can still proudly ask the candidate some crap about Heapsort and feel like he's done his job well.
- swivelmaster 13y ago
  I've had some good luck with open-ended questions like "Tell me about a time when you had to deal with a scaling issue." How they define "scaling issue" often says just as much as their explanation as to how they solved it. I think I've had to ask for clarification a few times due to the interviewee answering the open-ended question with something I wasn't familiar with, but that's an excellent opportunity to gauge their explanatory skills anyway!
fooooobar 13y ago
I don't even know what a tree parser is, but how can anyone not be able to write a binary search algorithm?
typicalrunt 13y ago
Asking about what happens at a low level when entering a URL however is a good question. Or perhaps asking how to do cross domain JSON requests etc... The former is a question about fundamentals, whereas the latter is a question about specific implementations. I agree that as a Web developer you should probably need to know what JSONP is, but it's also something that could be learned in about 5 minutes from Google. I like it when a phone interview is basically a conversation. I don't like Spanish Inquisition-style interviews, so I like to start with something and watch it lead to other things. Of course, if the conversation drops dead I can refer to my notes and ask another question. With regard to the URL question, in the past I have allowed the interviewee to answer the URL question as best they can, and the ask questions to cover some of the gaps, and these questions can lead into JSONP handling and its ilk. As an aside and a <rant type=small />, interviewing like this ensures that there is a natural flow and I'm keeping my interviewee's brain jumping between similar contexts. I hate it when I've been interviewed and I'm expected to context switch between algorithms (mergesort) to best practises (SOLID) to programming (implement REST with Jersey+Servlets). And this is all in a 30-60 minute "conversation".