I don't know if you should quit or not, but I do think you're mostly just psyching yourself out here. I can't see your actual interviews, but I'm just guessing a little based on your example.
On the 3 second tweet time question, I think you're just getting anxious at the thought that they might expect you to replicate thousands of engineer-months of work in a 20-min interview session. Nobody sane expects you to do that. If I was asking that question, I know nobody's gonna build Twitter in 20 minutes - what I want to know is how you think about and attack the problem.
I've never worked with anything Twitter-scale, but I might attack it like: How many followers are we talking about here? Okay, let's just start with a simple, dumb system and build it up. Simplest thing I can think of is a basic CRUD application backed by a Relational DB. SQL joins to get the tweets from your followers. You'd have to make a new request and new query manually to load new tweets. You could auto-poll, but that'll get real hard on the DB with even a modest number of users trying to refresh semi-rapidly. Maybe we can have a system where a single DB is still the source of truth, but there's a parallel system to load new tweets faster for those watching. Could maybe use websockets or long-polling for web clients. Let's build some separate servers for that websockets traffic. I'm pretty sure that as long as there isn't that much overall traffic to any one watcher, we can handle a good number of connections on one server, so we don't need a ton of them. Maybe creating a new tweet still adds it to the DB normally, but also triggers a background job, so the tweeter still sees fast response time. So we've got a background job going, and a bunch of realtime connection servers that are maintaining connections for specific users. We've gotta connect them somehow, send a message from the background worker to the realtime servers to send the tweet to connected clients that are following that user. Now let's think about how that would work...
Basically, show that you can examine the problem and come up with a few possible solutions and think about the trade-offs of them. I want to hire the engineer who can do that for any problem set in front of them. It's much harder to justify hiring the one who just has a blank stare for anything they don't have experience with already.
And for the record, that question isn't inherently bad IMO. But it would be a bad interviewer to just ask it and stare at the poor nervous candidate who has no idea what you want. A better interviewer would make it more clear what they're looking for, and help them down the first few steps of what I just went through above until they get the idea. Ex: So let's say Twitter 1.0 is a basic CRUD DB app. What might the DB schema look like? What's going to happen in terms of DB queries when we try to render a timeline for a user? What's going to happen if they all start hitting refresh every 10 seconds? If we want users to be able to see tweets faster than that, what might we do?