These days I skip all interviews which require me to code in the interview. I have plenty of open source code, if they cannot figure how good I am looking at, then they definitely cannot figure how good I am with a 3 hour coding interview.
IMO, coding interviews is like public speaking. Many people get nervous in front of a crowd. It's a skill one has to obtain should it be required. Coding interviews are quite irrelevant for a programmer/developer position.
I find it incredibly nerve wracking because it gives me that feeling of someone standing over my shoulder without me being able to fully interact with them or read their body language. When you sit down to hammer out a solution you have all the additional pressure of trying to stay engaged with someone you can't see. As a result I constantly drop my focus on the problem and lose what I've worked out in my head.
Maybe they want you to be slow and thorough (I've been nailed for not checking the exit status of print statements). OR maybe they want it quick and dirty, in which case you'll get nailed for "overengineering", or you just wont have time to do it the imaginary time frames they set for these tasks, if you go for any of the defensive practices that the other guy would have nailed you for. Fun, fun, fun.
2. Actually evaluate them on that.
Anything else is a psychology test, and you aren't psychologists.
It's a combination of nerves and needing to suppress a part of my natural coding process that occasionally involves a brief frenzy of guess-and-checking and pattern recognition to get my bearings on possible solutions. That part of the process is unconscious and intuitive, kind of like how athletes don't think about what they are doing. If I slow down to consciously relay those early steps of the process it breaks the spell/flow and I go blank.
I think the problem is that I have a habit of letting rapid ad-hoc intuition guide my coding, rather than being a rational agent following a pre-planned 'waterfall'. In-the-moment intuition somehow (surprisingly) produces nicely workable and even readable code much of the time, but also entails some amnesia about the steps I took along the way. I occasionally have doubts - am I built to be an engineer? By nature I am a very logical person, why can't I always conceive of a whole answer (or at least a clear direction) before "putting pen to paper"? Working memory deficiency? ADHD? Lack of practice? However, my doubts about programming potential are quelled when my friends and I look at the code I can write and the problems I have solved.
Practice makes perfect as they say. I really look forward to using this service.
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...
def function(unsorted1, unsorted2):
return [1, 2, 3]
poorly specified questions are very important to ask IMHO :)
Chill, he said 'so'. i think he was just saying he looked up the answer but that persons answer was faster
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.
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 do agree though interviews should be more focused on soft skills and not technical, even for technical jobs.
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!
merge_sorted(list1.sort(), list2.sort())
> 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
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.
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.
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?"
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.
"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.
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'd ignore the fact that there were initially 2 lists and just concatinate them and sort. I.e sort(unsorted1 + unsorted2)
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.
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).
Dig in, look around, its obvious what I can do, and what I'm capable of learning.
Ask me to code a sample app and comment every function with detailed explanations of my thought process.
Add me as a collaborator to GitHub and request that I make some pull requests on your product.
Live coding interviews are more irrelevant than irrelevant and completely ignore the fact that many people -- and especially introverted technical types -- just don't do well in front of groups.
Technical screens are synchronous and relatively well understood. If they are not the literally BEST choice of time for figuring out if someone is a good developer, they are at least a very defensible choice.
Work they'd otherwise be doing during the 3-hour coding interview?
2) if they're doing something not related to your interview during your interview, you don't want to work with them anyway
Public speaking is something you really should take the time to get good at. I think you are greatly underestimating the importance of communication skills in the workplace...even for developers.