Paul Tyma, a software engineer and startup founder, writes about threaded versus async I/O, tech interviews, hiring, and speculation about aliens and AI.
Commenters cite his case for synchronous multithreaded I/O over async callbacks and his argument on why we'll never meet aliens, calling his blogs full of gems.
Very thorough explanation that I definitely agree.
I love watching Soccer and Basketball. In those two fields, the best players are those who dedicate themselves to the game.
Lionel Messi, Christiano Ronaldo, Michael Jordan, LeBron, Kobe. The list goes on. They have the same trait: passion and dedication. Some may have born with the skill (Ronaldo, LeBron). Some takes time to develop (Jordan, Messi).
Having said that, our field is a little bit strange because there's a divide between being good at a particular set of skills and being jacks of all trades.
For example: we tend to argue and discuss the topic of how learning new programming language can change the way you think about a particular problem and hence make a conclusion that those who put the effort and time to learn niche language such as Erlang, LISP dialect, Ruby, Lua get this automatic recognition as a "better programmer". (They may be a "better" programmer if we compare it to John Doe Programmer, but are they truly a better programmer?)
On the other side of the coin, we have people like James Gosling, Bjarne Stroustrup, John Carmack, Dennis Ritchie, Joshua Bloch, Guido von Rossum, Kent Beck, Martin Fowler, etc. that are pretty much sticking with one or two languages but truly focus on their problem domain (as oppose to the languages that they use).
There seem to be a group of people who are good at plumbing different technology and get something out of it and there are another set of group of people who…
Fulltime, Palo Alto - funded Series A
http://www.refresh.io
paul at refresh.io
Title: "Rather Impressive Java Developer"
Our current dev team is pretty awesome and we're looking to add to it. Currently we have a few PhD's, few ex-googler's, some tech book authors, couple of ex-linkedin, ex-microsofties, and stanfords, and a bunch of startup vets like Trulia and dealer.com. Heck we even have the guy who wrote the Java testing framework TestNG ( http://www.testng.org ) and the guy who wrote Mailinator ( http://mailinator.blogspot.com ). And we're only up to 7 people. But we want an 8th and maybe a 9th.
Job Description:
Someone we want to work with. Someone who will make us smarter and better and, in return, someone we can make smarter and better too. Someone who will help us make our company and its products great.
Our technology includes:
Java. Thousands of threads (Mailinator guy keeps adding more, TestNG guy keeps removing them). Tons of data, tremendous data analysis, fuzzy logic, machine learning, natural language processing. We use Mongo and we're having no problems with it - because we're careful. We treat every superfluous database access and every unnecessary network call like its a small insult to our users. And gosh darn it, we love our users.
Simply, we are building a product that fetches and analyzes massive amounts of data to improve our user's lives (see the website for a more specific description, or better yet, email me)
Job Requirements:
You…
That is too vague to get really good answers back. What position are you in for?
That said, the best practice you can hope for is to INTERVIEW AT A LOT OF OTHER PLACES FIRST. Just trust me on this. Interviews require practice, and the best way to do it is to interview at other places that are good. If you don't trust me, listen to this guy, who says the same thing (and got the job at Google) [http://paultyma.blogspot.com/2010/11/google-interviewing-story.html].
That all said, you will probably want to review your basics of analysis (e.g., big O), as well as things like binary search. You will probably get asked to implement code of some sort, so be really well acquainted with your favorite language. Pick up a copy of Programming Pearls, by Jon Bentley, and work through a problem or two every day. By "work through", I mean try and do it yourself, and THEN look at the answers. The idea is to be thinking well come time for the interview.
Other things everyone knows are, you want to be really well acquainted with what Google is doing in your area. One of the ways they vet candidates is to see who actually knows what Google is an does in practice, rather than asking why they want to work there. A lot of their questions will probably come from problems they actually have.
Brush up on your books from college. Give the algorithms and data structures 101 stuff a quick look over and make sure you understand it.
That's not a comprehensive list or anything, but if you want more…
"NIO/MINA is the right answer on Java."
I think my point, which admittedly is only informed by the work of some brilliant people, is that your point is not supported by data gathered on modern hardware with modern operating systems running a modern JVM. At least, not in all cases. With care and some tuning, people can get extremely good performance out of the thread-per-connection approach. Please check the document linked in the parent to this thread (http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html)
What's more, even the systems that are very good at this do not use something like NIO, epoll, or select (as anything other than a very buried implementation detail). Erlang, for example, doesn't restrict you to the kind of model that raw NIO does. NIO is a fine thing for what it is, and a potential building block for many things, but it's not a very compelling as a server framework. MINA is a better suggestion, but still not a universal catch all for these sorts of problems.
I'm not trying to say, "NIO is never right, tpp is never wrong." I'm just saying your categorical statement is not always correct. Making that statement is wrong, and it's misleading, and I don't think the problem you found was really due to the unavoidable overhead of the threading.
As an interesting counterpoint, Paul Tyma has a really excellent presentation on how NIO in Java actually allows considerably less throughput than thread-per-connection and has a much more complicated programming model:
http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html
I've written a fair amount of asynchronous network code in my time, and it really is more difficult to write and debug - developers are generally used to being able to see a linear flow in their code. Event driven code in general IMO is much harder to follow and reason about than linear code. In my current project we have a fully asynchronous multiplexing network component - I'm about to replace it with a simpler, synchronous model because both the client code and the code of the component itself will be much simpler. Even if I take a performance hit the easier maintenance and fewer bugs will be worth it.
> Asynchronous, callback-based code is frequently more difficult to write, harder to reason with, more inflexible, and buggier than similar synchronous code.
That is an excellent point that is usually ignored. Thread per request is much easier to understand and work with. Of course, thread per request is simply not a good choice in cases like a server with support for web sockets, but it is good enough in many cases. My experience has mainly been with Java (NIO vs. simple threads and Executors). Paul Tyma has made a more convincing argument than me about this -
http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html
http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html
http://www.theserverside.com/discussions/thread.tss?thread_id=26700