The responses here just go to show how random a DBA interview could be. As one chapter (24) of SQL Server MVP Deep Dives Vol 1 "What does it mean to be a DBA?" put it the job description is so varied and constantly changing it is hard to even list all the DBA specialties on which to focus. When you do a phone interview often you have no clue as to the real DBA job being sought after. Realizing this one should not focus too much on specialties or specific facts. While one person may believe knowledge about joins is essential, a production DBA managing 100+ instances may never get a chance to write a join statement. And so in that case it is irrelevant. Or as one put it, knowledge off the top of your head about how to recover a suspect database, well of course always have a recovery plan for your database, but on the other hand the last time i saw a suspect database was quite a few years ago and so it is not the most relevant specific information in an interview in my opinion.
In short, DBA interviews are a random and chaotic experience. As a DBA since SQL Server 4.21 I have gone through many different 'specialties' and there is no way I could remember in detail all the exect facts about each one. As a DBA we are somehow expected to step up and handle whatever SQL Server issue there is. Reporting Services, Analysis Services, performance, very large databases, ERP systems, Clustering, Infrastructure, Virtualization of SQL Server, oh and nowadays, the Cloud to name a few.
When I have assisted in interviewing i tried to keep it fair and with the knowledge in mind that the DBA job is likely somewhat different wherever you are and basic intelligence, projects survived, basic knowledge and communication and people skills are what i focus on. If someone doesn't know the answer, then saying so and intellgent discussing what it may be or might mean may be what is looked for.