Anyway, this is a tech forum not an advice or agony aunt column.

And it is completely pointless. You want to say you know the answer? Or what? And why? I can give you the answer but you can't even check if that was correct or not...

OK so I have the second part

Now it's

SELECT FirstName, LastName FROM Employees
WHERE FirstName LIKE '%e%' AND LENGTH(LastName) > 5;


But that satisfies the conditions and returns the firstnames and lastname (I found a test database with a run SQL function)

But I have no clue how to count the number of rows returned. There are 7 in the table that I found.

It is (should be) perfectly ok to say "I don't know" - depending on the question, it may be wise to follow up with "but if I needed to, I would XYZ".

Some interviewers will deliberately ask irrelevant questions to see how candidates respond.

Given your second paragraph... if they're that petty in an interview, maybe it's a sign - are you sure it's a place you want to work at?


Put what you just typed into a search engine, prefixed by sql and you will get the answer!

1 members found this post helpful.

select count(*) from ... (response #18)

However, I will also be one to say: if you are looking for the answer to a technical-interview question, "asking for the right answer on a forum" is not the right way to go about it. There are an abundance of SQL-tutorial web sites out there, and some of them even allow you to type in queries to "try them out for yourself."

SQL "select" queries are quite simple:

• "SELECT" what? – fields or function results
• "FROM" somewhere – could be a single table or a "JOIN" between multiple tables based on common field values. (There are several types of JOINs available.)
• "WHERE" conditions are met on the rows.
• (Optional) "GROUP BY" fields to produce summary values (count, average, etc.) for all unique combinations of those fields instead of the rows themselves.
• (Optional) "HAVING" if you want to limit which grouped rows are returned
• "ORDER BY" to sort the results.

Unlike other types of databases, SQL will attempt to give you your answer no matter how the database is organized or indexed, always finding on its own the most-efficient way to do that. In one step, it takes your query, figures out the best way to do it, and does it. (IBM's "SEQUEL" system was completely revolutionary, at the time ...)

While SQL is "mostly standardized," there are "dialect" differences between them. Most will support the same basic "select" syntax although there may be function-name differences. Some provide considerably more capability, such as constructing "pivot tables." Some, such as SQLite, do not support certain usually-standard things because of the particular nature of their implementation.

But: "learning to program is like learning to swim – you have to get in the water, shallow end first." You have to "try ... ... try again." Yes, it is frustrating, especially at first. Until the turns on.

If you ask someone else for the answer, you're not learning to swim. You're just asking for a life-ring to be thrown to you by someone who did get into the same pool and "learn how."

The real task of "learning SQL" is not mastering the relatively-simple syntax of the statements. The real task is to take the problem description, and knowledge of the database, to decide what an appropriate SQL query should be. There may be more than one answer.

1 members found this post helpful.

Or ask an AI: https://you.com/search?q=I+need+to+f...ue&tbm=youchat

SQL systems are endemic these days.
If you want to be a Linux admin (not a network eng), then a basic knowledge is expected.

For those seriously interested, let me please emphasize:

"The real task of "learning SQL" is not mastering the relatively-simple syntax of the statements. The real task is to take the [abstract] problem description, and knowledge of the database, to decide what an appropriate SQL query should be."

Elementary mastery of "SQL" is only the first step – akin to "mastery" of the circular saw and the hammer in the construction trades. You must master these skills before you can move on, but the mere mastery of these skills does not mean that you have moved on.

For example: "the person who you just hired to build a deck" did not gain his qualifications for doing so merely because he knew how to use a [tool]." Instead, he gained his position by knowing how to apprise the situation of "building your deck," and then to successfully execute the task of actually building it – of course using [tools].

Got it

SELECT COUNT(*) FROM Customers
WHERE CustomerName LIKE '%m%'AND LENGTH(Country) < 4;


Number of records where customer has "m" ib the name and country has less than 4 chars.

Ok, that is actually good news. And now?
If you think your problem is solved please mark the thread as solved.

Well, this actually-trivial question has obviously been "solved," but the real point of the thread is that you must learn how to solve these things for yourself. Because, "on the job," you are constantly going to be required to do this. Every company's databases – for historical reasons or otherwise – will be different. In order to be technically competent, you must understand the tools that are available in the [SQL ...] databases that you are using. And, if your software uses an "SQL abstraction layer," you must understand this also.

At the end of every day, your job is to come up with "the right answer."

This requires time, and most of all it requires practice. "Just like swimming," it is actually not that very complicated. But, you must get into the pool. Fortunately for all of us, other people have constructed "practice web sites" which allow you to experiment without first constructing a database of your own or setting up a server.

FYI: "It is a HUGE mistake to 'bluff your way into a job.'" Far better to candidly admit what you do not yet know, and to profess your eagerness to learn it. (After all, "that is how you learn ...") They just might hire you anyway.

Speaking as a "hiring manager" myself, a "hiring manager" above all does not want to be deceived. There are plenty of available resources to "bring a new team member 'up to speed,'" as long as one actually and truthfully realizes what this person does and does not yet(!) know. "Nobody knows everything, even if they think that they do." Better to understate what you think that you can do, and let them be pleasantly surprised.

Looking back, I can certainly say that I tended to hire people who were less certain of their abilities, because I felt that they were being honest with me. If the candidate appeared to be "too good to be true," I trusted my gut.

"Never make a promise to anyone that you are not certain that you can keep!" It is perfectly okay to tell someone: "I'm not sure, but I'll try, and I'll be the first one to let you know." "Honesty is the best policy.™"

1 members found this post helpful.