There are so many ways to find problem queries; it's hard to elaborate all of them.
When I first get on a server that is new to me, I perform a thorough audit starting with all of the hardware and work "up" through the operating system and its settings, SQL Server and its settings, databases and their settings, etc., until I finally reach the queries themselves. I configure and execute PERFMON to identify the server stress points which I thoroughly document. I deliver the completed audit to my management, typically 50-100 pages long, and we review and agree on all of my observations and recommendations, and then I proceed to implement.
There are many things to look at that I can't list them all here. The point I'm making is that the fundamentals of the I/O system, the server hardware, and the server settings must be correct to eliminate them as sources of poor performance. Once these are "clean", almost all that's left to investigate are queries and/or missing indexes. (There are a few others but I don't want to write a long post.)
I load and execute SQL Server Performance Dashboard. This one interface has so many tools for identifying problem queries and missing indexes that it can be used to track down the great majority of a server's problem queries. I look at the Missing Indexes Report (whose output must be used intelligently; you cannot implement every index it recommends for many disparate reasons; again, I cannot list them all here). I look in the reports that list the queries that consume the most server resources: CPU, Logical Reads, Logical Writes, Physical Reads, and Longest Duration. One cannot use these reports blindly; you have to know what you are looking for. I am looking for queries that are candidates for improvement.
I also look at the SQL Server logs, looking for deadlocks and other query failures. I use SQL Server Profiler to identify the exact queries involved in deadlocks.
I have written a Blocking Trace in T-SQL that is foolproof for capturing all blocking and blocked queries' metadata. Blocking is a common problem on many servers. Solving blocking often resolves many server performance issues.
I look at the server Waits Profile in the Performance Dashboard to gain insight into what the server waits are. I don't want to elaborate too much here, but I am looking for what I know to be a normal or abnormal Waits profile. Depending upon what I find, it may change the focus of my efforts investigating queries.
In summary, I use every tool at my disposal, depending upon what I perceive to be the nature of a server's problem queries. This process involves both logic and professional intuition.
Most recently, I've been exposed to a product named "SolarWinds". It gives a very good high level overview of what is happening on a server. Additionally, it offers some very useful "drill down" capability.
I have never found a server whose problems I could not identify and fix, if management allowed me to fix them.
It's the same for queries. If you are knowledgeable about T-SQL, know how to read Query Plans, it's fairly easy to identify the problem query candidates, to identify the query segments consuming resources, to investigate them, and determine exactly what problems they are causing, if any, and make recommendations for altering their construction and execution.