I'm a full stack developer. Currently focusing on iOS. Interview questions should really depend on the expectations of the type of software being developed.
I've been to a couple interviews lately and this has been the first time (in my career) that I have been tested (with time constraints too, mind you). I was either pointed to a whiteboard, or sat in a room with nothing but a couple sheets of blank (unruled) paper, a non-erasable pen, and a list of ~10 algorithms questions with a few to be implemented and their running time, and memory footprint to be explained.
I was not prepared, at all.
I have been developing software for about 17 years. Do you have any idea how many times in my career I have been asked to write a heap sort, a trie, or create a power set? Never. So, I had forgotten some of the specifics of how to implement them. Let alone on paper. A quick note... My handwriting is atrocious. I'm 41 and I am extremely embarrassed as to how bad it is. I can play classical guitar, but I screw up everything I write or attempt to draw. I thought it was a dyslexia thing or something, but I don't seem to have enough of the symptoms for that. That's pretty much why I liked using a computer when I was younger; I could fix my mistakes. So, needless to say, when I am asked to write stuff down I kind of freak out.
Anyway, there is a reason I have reference materials and the Internet. If I don't remember the specifics of something, I go look it up. I know what a lot of data structures and algorithms are, but I just don't bother memorizing all their specifics. I know what to look for. I read the description and can decide what the best thing to do is. Sure, I remember the basics of the major algorithms and data structures, and some of their their Big O characteristics. Implementing these isn't really what I do on just about any given day.
So, what have I been doing about it? I've been spending the last couple weeks going back over the "Algorithms" book (http://algs4.cs.princeton.edu/home/) and grabbed all the videos from the Coursera courses on the same book/topic.
I admit it's all my fault. I have written a lot of very successful applications over my career. These have fulfilled requirements for power generation, real estate, healthcare, search engine, and marketing companies. Using higher level abstractions (like using an OO language) with industry tested APIs for sorting, lists, trees etc.. kind of makes you push that stuff to the side because for 95% of the development, that kind of low level detail is just not necessary.
Now, of course, this really depends also on what type of development you do. Sure, if you are writing a lot of C code, you may need to manually write these structures. Or, if you are writing low level code (game event loops, collision detection, file system stuff, you know) that needs to run as optimally as possible, sure. A lot of us write applications that take in data, and spew it back out. Heck, a lot of developers are forced to write just a hell of a lot of SQL queries and they'll never see a data structure beyond a class file, an array list, and a result set.
Again, I am attempting to better myself now. I don't know how long it will be before I can answer some of the more crazy questions I have been asked though.
The problem is that there is a belief in the industry that 15-30 minutes of technical interviewing tells more about a candidate than that person's entire career history. I have seen no actual data to support this belief.
I think someone who has a history of having built successful applications is far more likely to be qualified than someone who happens to have a good memory for algorithmic solutions and performs well under the stress of an interview situation.
This interviewing approach may make sense for entry level candidates who have nothing more to show than what they have learned in their CS classes but applying it to an experienced professional is simply brain-dead.
> The problem is that there is a belief in the industry that 15-30 minutes of technical interviewing tells more about a candidate than that person's entire career history. I have seen no actual data to support this belief.
Actually, this is only true when there is no social proof. Once you have people who can vouch for your successful application building prowess in some form or the other, you will find interviewing to be dramatically easier.
Statistically speaking, I haven't had to look them up that many times. I've a high percentage of the JDK memorized though, and a pretty good portion of the CocoaTouch and Objective-C Foundation framework. :-)
I've been to a couple interviews lately and this has been the first time (in my career) that I have been tested (with time constraints too, mind you). I was either pointed to a whiteboard, or sat in a room with nothing but a couple sheets of blank (unruled) paper, a non-erasable pen, and a list of ~10 algorithms questions with a few to be implemented and their running time, and memory footprint to be explained.
I was not prepared, at all.
I have been developing software for about 17 years. Do you have any idea how many times in my career I have been asked to write a heap sort, a trie, or create a power set? Never. So, I had forgotten some of the specifics of how to implement them. Let alone on paper. A quick note... My handwriting is atrocious. I'm 41 and I am extremely embarrassed as to how bad it is. I can play classical guitar, but I screw up everything I write or attempt to draw. I thought it was a dyslexia thing or something, but I don't seem to have enough of the symptoms for that. That's pretty much why I liked using a computer when I was younger; I could fix my mistakes. So, needless to say, when I am asked to write stuff down I kind of freak out.
Anyway, there is a reason I have reference materials and the Internet. If I don't remember the specifics of something, I go look it up. I know what a lot of data structures and algorithms are, but I just don't bother memorizing all their specifics. I know what to look for. I read the description and can decide what the best thing to do is. Sure, I remember the basics of the major algorithms and data structures, and some of their their Big O characteristics. Implementing these isn't really what I do on just about any given day.
So, what have I been doing about it? I've been spending the last couple weeks going back over the "Algorithms" book (http://algs4.cs.princeton.edu/home/) and grabbed all the videos from the Coursera courses on the same book/topic.
I admit it's all my fault. I have written a lot of very successful applications over my career. These have fulfilled requirements for power generation, real estate, healthcare, search engine, and marketing companies. Using higher level abstractions (like using an OO language) with industry tested APIs for sorting, lists, trees etc.. kind of makes you push that stuff to the side because for 95% of the development, that kind of low level detail is just not necessary.
Now, of course, this really depends also on what type of development you do. Sure, if you are writing a lot of C code, you may need to manually write these structures. Or, if you are writing low level code (game event loops, collision detection, file system stuff, you know) that needs to run as optimally as possible, sure. A lot of us write applications that take in data, and spew it back out. Heck, a lot of developers are forced to write just a hell of a lot of SQL queries and they'll never see a data structure beyond a class file, an array list, and a result set.
Again, I am attempting to better myself now. I don't know how long it will be before I can answer some of the more crazy questions I have been asked though.
TL;DR I was not prepared, at all.