Can someone explain the hype over MongoDB? All I know that it's non-relational (and I have no experience with NoSQL). Thoughts / experiences?

uh it just works at least for me using the mongoose ORM in js. I need to save something ok go save it. I need to add to that "collection" ok put that in the "schema", future saves may or may not have that field. Seems fine idk, no problems here after over a year using it on my current game website.

You can store document data that doesn't need schemas and it stores it in a JSON-like format which is convenient for JavaScript stacks. Probably a bad idea to use it for relational data. That's about it. The main benefit is rapid/agile development and storing document-like data without needing 17 tables and 800 joins.

You can store JSON (and arrays) with Postgres as well.

It seems like the best approach is to store everything that doesn't need to be indexed as JSON, and rest as traditional indexed columns.

Isnt S3 dirt cheap though? I pay very little on it and im not on free tier anymore

I sort of agree and that's the direction I would usually go in, but as ever, it depends on the use case. Mongo has maturity advantages in terms of things like scalability and tooling. There's an article comparing it with Postgres written from a pro-Mongo perspective here.

Your question is a bit like me saying "Why would I ever use a dynamically-typed language now that C# has the dynamic keyword? I can have the advantages of static typing AND use dynamic typing whenever I want!". The answer is that dynamic languages and their ecosystems are ground-up designed to be better at doing what they are designed to do - that is, very rapid, flexible development.

I've used it extensively at my last 2 jobs and I am really not much of a fan. It works best when you have a fairly loose collection of data and you don't have any preconceived notions of what's going to be in it.

Not only should it not be used for relational data, it should probably not be used for anything where you have a schema. Like let's say you're storing users and your initial schema is user_id and username. OK great. Then a month later you decide that you're going to start storing emails too, so you do. All your documents from before that change just won't have an email member in the documents. So you either need to code defensively around that, or go back and update all the docs to have null emails, etc.

It is intensely irritating to deal with mongo collections that have been around a long time with fairly active development, especially if you didn't do that development, because all you have to go on is individual documents. You can inspect a few documents and think you know what the underlying schema is like, but you'll be wrong - there will be documents that don't follow that schema.

It's like trying to reverse engineer a protocol by looking at data traffic. You can't know the full extent of the available options, only what you've seen so far.

Pretty much the only thing we use it for now is to hold a bunch of arbitrary data. Like we have these "jobs" that run, each job is a loose collection of tasks. Which tasks get run depends on the contents of the submitted job, and the output of each task is an undifferentiated blob of json. So mongo makes a lot of sense in this case and it works fine.

We still have problems whenever any of those tasks' output changes (which is often, many of them are 3rd party apps that output json) but we'd have problems with a relational db too, just different types of problems.

I never found this a problem. The way I think about it (and I probably heard it from Mongo peeps themselves) is that your data is still going to have a schema - its just not enforced at the database level. So if you're not backpopulating the emails field, then yeah, your code has to handle it being missing. But that's not really different than your code having to handle a null value in an email column (or field) that was added afterwards and not back populated.

Using Mongo with Python clients felt great. Because the database felt like a natural extension of the language. Missing keys aren't really a big deal. Using Mongo with Java clients felt a lot more awkward.

So as I alluded to above the problem really comes when you have changing team members over a long period of time, it becomes very difficult to reason about the contents of *all* the documents in your collection, because you don't know what changes have happened to the implicit schema. At least with the case of a SQL database, you'll have nulls but every row in the database is guaranteed to have the same fields, even if some of the values may be in a not-well-defined state. With mongo both the fields *and* values may be not-well-defined.

I agree that the way pymongo works is very gratifying but it's also the source of a lot of problems. On the trivial level every time there's a typo or an improperly nested use of a pymongo database/collection you end up with orphaned databases and collections. Instead of throwing an error when you refer to a collection or db that doesn't exist, it just... creates it. Theres a mongo db in our infra that contains what appears to be no fewer than 3 copies of the same data and no one has ever really gone in and figured out which set is in use.

The real problem though, is this: there are usually barriers in most databases to creating new databases, tables, indexes, etc. In mongo there are often no such barriers. So, developers like to skip the gatekeepers and do whatever and so they gravitate to mongo. For sure I have seen mongo get used a lot where EVERYONE agrees that a SQL database would have been better, but it would have been more work for the dev, so, **** it, let's put it in mongo.

This is an argument for decreasing the barriers in SQL in most places, though, as much as for reducing mongo use.

I think in another trivial sense SQL database encourages people to think about their data and what will be needed and how it will be used, and mongo discourages it. It's still possible to think deeply about your data and use mongo, but you don't have too, so a lot of the time you won't. This is along the lines of not enforcing referential integrity. if you're careful and your code is perfect, you don't NEED referential integrity. The fact that you DO actually need it comes from the fact that no one is that good.

I don't get the distinction here. A column may exist in a relational database, but you still have no context on whether its deprecated, only valid for a subset of rows, has garbage data, etc. Just the fact that a column exists tells me very little about the actual state of the values of the data (which is what I care about).

So it seems like the actual problems with old collections / changing teams is basically the same in both cases.


Aren't there settings to stop this? I don't think we ever hit this, but we had a pretty good abstraction layer in front of Mongo so we were rarely writing database/collection names except in development (and I'm pretty sure if I take a look at one of our staging postgres databases I'll see lots of orphaned tables).



This feels like one of those "I don't think the tool is the real problem here". But I get that its not that simple and a tool can exacerbate or ameliorate other issues.


I'm pretty unconvinced that the thinking a SQL database makes you do up front actually leads to better database designs. Its hard to design a database schema - especially up front.

And this isn't to say I'm a Mongo fanboy. The denormalized view of data that Mongo often encourages is clearly the wrong choice in a lot of applications.

Legit exciting and I would like updates
I've been like half-seriously considering seeing what kind of jobs I could get. Started watching YT vids and blogs of people going through the process.
Also you're an STTF'er. It's always nice seeing what STTF'ers are up to these days

That must feel great!

Crap, I got invited to do an on-site interview last minute on Monday. I wouldn’t even know what to ask.

Probably a mistake since I never have interviewed anyone ever. Going to ask the recruiter to take me out of this one.

Ask them to let you sit in with someone more experienced and listen

Barrin,

I think you should do it.

Don't Google technical interview questions and pick a few, that is how most people start off and they get very bad habits and become terrible interviewers.

Instead, just ask the person open ended questions and get them telling stories.

"So, tell me about what you do currently/did last?" Is a good opener. They should have already been asked this and should be ready to give an answer and start off feeling comfortable with you.

Ask them about the technologies they use/have used, what they like about them, issues they have encountered.

Some of the best questions are about times they have had to work very hard to solve something.

In my line of work it might be "have you ever found a bug in a browser... what was it, how did you find it and what did you do to fix it?"

Ideally you want to figure out if someone has the work ethic and determination to solve problems, and enjoys doing so.

You can figure out their ability to understand things easily enough from their resume, but figuring out if they have the will and desire is tour goal, and if they fit into the culture.

If you are interested in the long-term health of your team, it is good to become part of this process.

ask them to explain if java method parameters are passed by value or reference trolololol

Talked to my boss about it. He said to decline but it is on the list of things of the he wants me to start doing next quarter.

Larry, those are good questions but I’ll probably start interviewing only junior engineers who are new grads with little work experience. I know people hate on whiteboard coding but I might throw a few easy ones as a sanity check.

And I agree with Rusty, I feel like I need to sit in on a few.

Hire if answer is "What's Java?".

Isn't Java passing just the same as C#? Everything is passed by value, however objects are actually pointers to the object, so you can modify the object but if the pointer is reassigned to a new object, that won't be passed back to the calling code. I'm not sure if Java's ******ed boxing/unboxing rules have any impact here.

java passes object references by value. it's an old trick question.

What? they're having a dev that's been with the company for a little over a year interview new candidates? Something doesn't add up! /grim

JavaScript is the same as java then.

I'm not sure what the issue is?

^ this

Me neither, or why my name is mentioned (despite him allegedly putting me ignore).

I have a half hour meeting in the morning with the Director of IP Compliance. Should be riveting.

Is this a standard thing when leaving a company? Meeting with the director seems like overkill.