Many people say that DBs are not good for large blobs, hence the advice to put large files such as images in the files system, not in the database. What's different here that makes it acceptable to put files in the database?
They just run everything through one live database all the time under normal conditions. Personally, I think this is much simpler to manage than to be regularly spreading out queries over many queries.
I really wanted to use Scala+Play to get away from the MS stack, but the documentation for Play was pretty hard to navigate due to the volume of documentation and the breaking changes in 2.
We've recently started down this C#/Postgres route. One of the main decisions to use C# was static typing, so I wanted to keep this with the data access layer as well. I've decided to use dotConnect for PostgreSQL so I can use EF. I figure I can use dapper or another micro ORM after I get into performance issues.
Our biggest problem with Postgres is actually the lack of a good GUI. I'm using 0xDBE for the amazing auto complete and PgAdmin for everything else.
From the interviews I've done so far, the algorithm questions are more important. From our perspective, it's much easier for someone good with algorithms to learn a few technologies than for someone with a few technologies to learn algorithms. Plus, you're going to need to take some time to familiarize yourself with our software system anyway. It doesn't matter too much to us if you take two months to ramp up or 3.
This just seems like a better way to evaluate candidates even though we rarely have difficult algorithmic problem in our daily work.
So to make my chances in the future better, it would be better for to spend time on sites like topcoder honing on my algorithmic skills rather than say, experimenting with nodejs. Or does this depend on the company/job I am applying to?
Yes, time spent on TopCoder is more likely to help you in coding interviews in general than picking up new technologies.
I say this with some specificity to Amazon (I did ~200 interviews while I was there), but it would apply equally well to every other tech interview I've done.
Top Coder will change the way you think about problems (in terms of what primitives you'll bring to bear against them). I would say the same for mastering another framework that has a different model than those you've used before, but that both takes a lot more time and is nearly impossible for an interviewer to evaluate unless they've achieved the same mastery.
Algorithms are in some sense a least common denominator proxy metric for "can this person solve problems?" Usually this is followed by "can this person string three lines of code together and perhaps use a for loop?"
When these interviews go well it's usually a pretty accurate indicator that the candidate is technically capable of doing the job. The contrapositive is not always the case -- when the interview goes badly you're sometimes left with a nagging sensation that because you did a crappy interview you're going to miss out on a good candidate. That's just the way (many) hiring systems are biased, though -- it's better to say no to a good candidate than say yes to a bad one.
It's interesting, but your chances of getting a job are very dependent on how well you perform during the 30 minutes they throw small algorithmic questions at you. This isn't to say that alone will get you a job, but if you bomb that part of the interview, it's basically over.
