>I have plenty of open source code, if they cannot figure how good I am looking at...
I've interviewed several people with lots of code on github and what looks like lots of accepted pull requests to many projects who still can't seem to reason through a problem described as "write a function that takes two unsorted lists and returns one sorted list".
I think I'll continue asking technical/coding questions...
I would say this is actually a very important part of interviewing. When given vague requirements, see how they respond. Building something that is technically correct isn't as good as building what you actually want.
I'd give the candidate some minutes to Google the problem, but then I'd want a solution and a good explanation. (Explaining other people's code is hard, too.)
Thanks autokad. base698 has the right interpretation: My response was the smarmy answer I have given in interview situations where I just felt rebellious against the energy of interviewer combined with the test questions. I actually agree with base698. An understanding of the basics is required. And the companies I've coded for - for long periods of time, and loved working at - figured out I knew the basics based on our conversations alone. I hire people without testing. It has not backfired yet. I have also tested others in the past, had people pass the test, only come on board to be dangerous to production environments.
In elementary school when you were learning to do algebra did you say, "that problem has been solved id google it?" To learn you have to do the basics before you can do the advanced stuff.
What is the correct answer to this? Let's try a little experiment.. I've never heard this question before, so I'm in the same boat as a naive interviewer right now. Let me elaborate my thought process.
"H'm, this looks a bit like mergesort, where you take two sorted sublists and form a bigger sorted list. So...sort the sublists using mergesort, then call the merging algorithm? (compare the heads of the two lists, and form the bigger list)"
This would be the answer I'd start giving. Tell me if it corresponds even remotely with what your idea of a correct answer is, or what points would you deduct from if it is incorrect. Off the top of my head, I'm not sure I'd be able to write the exact python code for this that covers all edge cases in less than 15 minutes.
We try very hard to NOT ask questions that have only one correct answer, and my team only interviews/hires senior people. So my approach to interviewing might be different than someone who's interviewing a fresh grad.
I treat all questions as conversational. The direction the question goes depends on where I (or other prior interviewers) think more evidence is needed.
For example: merge sort is an answer that satisfies the conditions of the problem. Given that, I would decide if I need more evidence about your ability to code, if so I'd ask you to implement merge sort; I might want more evidence on how you explain things, so I would pretend that I didn't know what merge sort was and ask you to give me a description of it.
I wonder if those people you're talking about just froze in the interview process, like others in this thread have mentioned doing?
Presumably it's possible to distinguish people who interview badly from people who lie on their résumé. The question is "How?" Followed by "How many interviewers know how to do this?"
The interviewers in these loops are generally quite introverted themselves, I know I certainly am. I believe we are sensitive to people who are the same and cut them slack.
My goal when interviewing someone is to determine if they will, on net, add more lift or more drag. If someone is so nervous that they can't communicate, they (sadly) will almost certainly not be able to demonstrate this.
Luckily, there are personal referrals. A strong engineer who interviews very poorly but has good first hand references will be given MUCH more slack.
I'm curious, what kind of a solution are you looking for with that problem? The trivial solution of concatenating the lists and then using a library sort (or cobbling together quicksort) is about as good as it gets for small lists.
For large lists, the best you can do is copy the lists into an array, use a parallel n * log n array sort, then fix the pointers.
The problem doesn't seem to require any real thought. It is difficult to make optimizations because the problem isn't especially well defined and the optimal asymptotic performance is obvious the moment the word "sorted" is uttered.
You can do better by taking advantage of the fact that the lists are already sorted. O(n1 + n2) time, where n1 and n2 are the sizes of the original lists and O(n1 + n2) space for the output.
The "trick" is to iteratively merge your two lists: at each step you select the smallest of the two items you're at in both lists then move forward on the list whose item you picked.
An extension to this problem (I've asked, and been asked, many variations of this) is to merge K sorted lists of N items each. The naive solution is to merge them all together and sort but you can do better if you extend the algorithm above from 2 lists to K and choose a helpful intermediate data structure to optimize the "select the smallest of the K items" operation. AFAIK, all-up the best you can do then is O(NKlog[K]).
EDIT: Re-read the question, realized I read "unsorted" as "sorted" - not sure what you can do to merge two unsorted lists in better than O(Nlog[N]) time beyond non-comparison-based sorts where you make assumptions about the range or distribution of your input (radix/counting/bucket sorts).
Yeah, when the lists are sorted, you need the intuition that you can merge two sorted lists in less than n * log n time. Like you say, the best you can do for merging several sorted lists is (sum of lengths) * log(# of lists).
If someone asks me to code/problem solve in an interview these days, I don't even bother to try, I just pretend to try and answer the question to see their reaction, because by that point I've already lost interest in the position. It's the equivalent of a shit-test, so I like to turn the tables around and see how they react instead.
I do this for many reasons, one of which, is they obviously weren't interested enough in my talents to throughly research me before the interview to assess my skill-set, which means, they weren't that interested in hiring me to begin with. I don't want to work for someone who is just slamming through interviews for talent; I'll bow out. I want to work for someone who is specifically interested in working with me and understands my skill-set before hand. The second reason, I don't deal with these questions is that I don't like to be put on the spot without my normal working environment, I feel at a disadvantage and uncomfortable. Keep in mind most developers are introverts.
I consider a good interview to be about people; not technicals, which can be referenced/refered or looked up; they should provide a medium to see if the employee is a comfortable fit. If goals and motives align. To talk history and such.
Oddly enough, people lie, unknown references can be bullshit.
The cost of hiring someone who is incompetent is high. High enough that companies generally make several attempts at finding and filtering people that might be incompetent. I don't think anyone who interviews programmers actually believes the standard technical interview process is fun or necessarily even accurate, but there's nothing else as low cost to implement that works better.
Further, someone who treated a technical problem in an engineering interview as a "shit test" would be walked out at any company I've interviewed for... Good luck with that!
I do not think your attitude or position are indicative of the majority of developers. They also require a huge time investment up front by the interviewer. Even if your individual Github profile (or whatever) is organized, comprehensible, and relevant, it doesn't say anything about the vast majority of developers whose profiles are largely scattered, obtuse, and frankly not even representative of their own work.
If you are a recognized leader in a particular field your situation is obviously different, but you can't expect me as a interviewer looking for a web developer making a mostly standard CRUD app to have the time to delve into your personal history and divine your technical expertise without asking you about it.
I can't really explain it. It was a puzzle to all of the interviewers.
The only reasonable hypothesis I have where I assume the candidate was honest is that the quality of the code in his github profile is largely due to help from others.
Or that they are bad with on-the-spot-questions-with-short-time-limit-while-every-move-under-scrutiny-by-potential-employer situations ... Which usually only ever happen in interviews.
The only reason I can do well in one of these interviews is because I recently started writing poor patch code for websites.
In development, who would do design, code and review on only one change in a straight sequence? It is like asking half your brain to shut down and the gods to smite you.
I've interviewed several people with lots of code on github and what looks like lots of accepted pull requests to many projects who still can't seem to reason through a problem described as "write a function that takes two unsorted lists and returns one sorted list".
I think I'll continue asking technical/coding questions...