>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.
Have you actually contacted customer support for Shopping Express? I have, twice and both times my issues were resolved very much to my satisfaction quickly.
Further, customer support for Nexus - my one issue with them was also satisfactorily resolved quickly.
I understand that my experiences are not necessarily the norm, but I see this quip posted regularly and I don't know if people who post it actually have any experience.
One good reason to use a VM - JIT's can generate very very fast code. Hotspot has gotten so good that there are several cases where numeric java code I've written is faster than reasonably tuned C.
Can you show us some Java code that's faster than reasonably tuned C compiled with a good C compiler with all optimizations on? Performance issues in Java are often related to memory management and lack of control over the layout of your objects and JITs also have real-time constraints, you can't sit all day while the JIT does it's thing.
I do machine learning, I don't particularly care about object layout - almost everything I deal with is just arrays of floats, doubles, or longs. I'm also not bothered by GC issues as I simply iterate over the same arrays many times. Lastly, with the type of code I run, JITing of hotspots is done long before the first iteration over the data is complete.
A coworker bet that java would be within 30% of similarly structured c code. I didn't believe him, so I rewrote two of my companies computationally expensive algorithms; a variant of matrix factorization and a neural network.
The production version of the C code did some tricks that would not be possible in java, so I rewrote the C versions to be a bit simpler. I then ported the simpler C programs to java, a fairly straight forward and mostly mechanical job.
The MF code was 5-6% slower than in C, the RBM code was about 1% faster than C.
Granted the tricks I was able to exploit in the production versions made those versions decisively faster than the simple java version, but java was and is much better than I realized.
I'd be interested in seeing the code. I guess my perspective is that with C++ or C getting something to run fast is a process. The first naive implementation will run pretty fast with a good compiler but then you whip out the profiler and look at the generated assembly. It's not just the language it's also the tooling. As an example, you might find that to make good utilization of SSE you want to process multiple matrices concurrently. You may arrange your input data such that you can quickly load the corner element of 4 matrices into an SSE register. You may further rearrange things so that you hide the latency of certain instructions. A good compiler can do some of that for you but the biggest thing is having visibility and being able to exert control at this level. This is often an order of magnitude difference in performance.
Now with a VM you can't really do that. Even if you could for a given implementation of the VM you might get terrible performance somewhere else. The run anywhere VM approach means you're giving up the ability to fine tune things and there's really no way around that. All you can do is try to minimize the impact and I guess JIT is one way. It's certainly true it's a lot faster than it used to be but presumably there are some sweet spots, patterns the JIT is very good at, and some less than sweet spots, patterns where it's not, and your visibility and ability to engineer things is reduced...
So, you wrote the C code to be slower, and then Java seemed fast? :-) I do numeric software for a living - similar to you: lots of arrays allocated once and iterated over. It would be great if Java could cut it, but I'll never believe when Java people claim that it's nearly the speed of C until they show me a Java FFT that compares to FFTW. One simple benchmark, and I'll believe the Java believers.
one awesome trick the jit does is in the case of child classes with virtual functions, if there is only one child class used in a run, it can remove the virtual-ness and inline the function used.
so, for example, one place you would see this is if you have distributions, and eg class Distribution has a virtual member function like deviance or some such. However, for a given run of your code, you only ever use one distribution. Also say that the loop that uses the deviance is hot enough that you can see the slowdown from the vtable and the function call. The java jit will inline the deviance function for the distribution you use (assuming the method is small enough, which it often is). The only way to get this behavior in c++ is to lift the decision out of the hot loop and generate one function for each distribution. I've done this and seen noticeable performance gains (10-15% on hours/days long runtimes), but it does not make the code nice to work with.
Well... A lot of hotspots potential comes from runtime profiling, this is not necessarily the same as having an optimizing compiler generating code at compile time.
Modern C compilers have profile guided optimization for that. You run your code, profile it, and the optimizer uses that data in the next pass. So this is something you can get without a JIT compiler.
In my experience, PGO is something that relatively few C/C++ programmers know about or at least use... roughly the same percentage of java programmers know how JIT works. But all java programmers get to benefit from JIT.
Don't get me wrong, a lot of java bugs the hell out of me and I'm personally much more comfortable writing c++. I'm just pointing out that a code running on a virtual machine isn't some horrible back water.
I think a fair compromise would be to have a setting to adjust the 'wobble'. I like both charts, but it mostly looks like Camillo prefers the font (only speculating).
zuul is used by the netflix API. It's not a cache. It's a request router.
EVCache is used internally for ephemeral systems data - things that would frequently go into mysql or cassandra but don't really need crash persistence.
Wow. That really says something (to me anyway), begging to go back to Verilog.
There are a lot of pain points in the HDLs, but it seems like Verilog has more than the others.
I saw someone working on a clojure HDL, I think it might have compiled down to or emitted Verilog. I thought it was more confusing than the HDLs to begin with, but depending on one's background it might make more sense.
I have a very different experience. I've had my fastmail account for ~5 years and get 20 new pieces of spam in my inbox daily, while on my gmail account, that I've used for ~10 years, I only get 1 spam per month on average.
Fastmail's spam filtering is atrocious in my experience.
Engineers are expected to take responsibility for themselves. They are, after all, "fully formed adults" (in Patty's parlance). And honestly it's not that hard to figure out which skills are useful to the work around you.
Netflix has traditionally only hired very senior engineers. Mentoring, at least technical, isn't seen as necessary for these people. Further, if an engineer thinks mentoring would help them, the onus is on them to seek it out.
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...