Should a DBA be able to write basic T-SQL? I am a SQL Server database developer (not a DBA) and I find myself frustrated working with my company's new DBA. I'm trying to figure out whether my expectations are unreasonable. 

For the sake of clarity, I'll oversimplify: I'm defining a database developer as  one who writes stored procedures, views, functions, etc that are used in applications, such as a web application. I'm defining a DBA as one who creates maintenance plans for backups, installs the SQL Server on new servers, does patches and other mysterious things. 

Sometimes, in order to do problem solving on production data I'll need to know something about it, like how many rows are in a table or how many rows there are where a column has a specific value. In the past, the DBA and I would have a phone conversation where I would ask my question, he would fire off the query and I would have my answer. 

If you are a DBA (not a developer) and I asked if you could give me a count of the number of rows in MyTable, would you know how to write "select count(*) from MyTable" ?

No bashing, please, of me or my DBA. Just tell me if this query would be in your skillset if you were a mid-level DBA on a large project.
I have been lucky to have had the opportunity to work with many great people in my career and I used to think the same as you do now.

I've met DBA's who were better at writing T-SQL than me, and I've worked with DBA's that don't know a single line of T-SQL. While I personally find the latter frustrating, I try to keep an understanding of the task they are doing in mind when I judge their skill set.

To be more specific, some of the DBA's I have known who could not write T-SQL have been amazing at PowerShell, SMO or were a whiz with SSMS or another GUI and so never needed to write a query. 

More importantly, the question comes down to can they do the job they were hired to do? If they can, and they are good at it, then so be it. You aren't asking them to do yours so don't stress about it.

If they need to run some T-SQL, walk them through it if they are interested, guide them to some help documentation. Some people may want to learn and have never had the opportunity to do so. Others are not interested and just want to clock in and out each day. Each to their own.

As long as you get what you need from the team, life is good.