Personally, coding problems in interviews is usually a red flag for me. You may end up asking questions that someone doesn't do frequently and you MAY filter out a really good candidate. For example, if you ask a question around "MERGE" or "PIVOT/UNPIVOT" to someone who doesn't use those frequently, you may lose out a candidate who is really good at doing set based data manipulation and accidently hire someone who has a love for CURSORs and NOLOCK.
If I was hiring for a Jr. position, I would want them to be able to understand the basics such as the difference between the different join types, but that can also be easily googled, so as long as they are thinking about the problem correctly and looking to solve the problem with a set based solution, I can teach and train that Jr. to be a Sr.
Now if I am hiring for a Sr. level position, I don't want to try to stump them on queries as that isn't the point of the interview. I may show them some code and an error message and ask how they would start troubleshooting it, but I'm not giving them a table and asking them to write queries by hand against it. If I am applying for a Sr. level position as a developer and you want me to write code, my first thought is that you are having a problem and I am coming in to be "free help" and I don't really want a job where I would be working with people like that anyways. Now, a better interview question is to get the interviewee "thinking" about the problem. Like ask them how they would plan to write a query to get the data and what sort of questions they would ask the end user before getting the data. That "plan" is the important part of the question because depending on what it is going to be used IN will determine how I write the query. Like is this a "one-off" and will never be used again or is this a repeated query and should be persisted to disk? Also, in your above example, what do you consider a "duplicate data entry"? Does just 1 column have to have a duplicate value or is it 2 identical rows? I would want clarification on what you consider a duplicate data entry before I start writing the query. Plus, what column are you using to determine what is "first"? Your question, while it MAY seem easy to you, has a lot of unknowns to someone who doesn't know the data and without knowing the data, you can end up with a lot of different answers that are all technically correct, but not what you were looking for. For a Sr. level developer position, I would HOPE that they are asking all the right questions and then providing a verbal explanation of how they would get the data, and for a Sr. level position, I would HOPE that they would be asking about data volume and expected data growth too so that they show they are planning for the future not solving an immediate problem. And even then, at a Sr. level, I would want them to ask things like "how are you handling this currently?" and "what problem do you hope to solve with this?" and "is there a workaround while we develop this?". Things I ask end users all the time.
Now, if you were hiring me as a DBA, I would be annoyed that you are asking me "developer" level questions for a DBA position and I'd definitely turn down the position as developer and DBA are 2 completely different roles and if you are merging them into 1, I would want to be compensated nicely for working 2 jobs. The ONLY exception to asking "developer" related questions to a DBA (in my mind) is if you are looking for how they would tune the query. Like what is their "performance tuning" plan for a query? There are TONS of ways to do performance tuning and it really depends on the system usage. Like is the query slow but used 1 time per year? then I probably wouldn't waste time trying to tune it. If the query run time is 1 second and is run millions of times per day, getting that to 0.5 seconds would be a pretty big win. Then reading the execution plan, reviewing the code, reviewing indexes used and missing, reviewing data volume, etc... lots of places to look AND nice DBA related question.
The TL;DR version - if I am hiring an "Advanced DB Developer" (which I read as a Sr. Database Developer), I am not going to throw code at them. I want to know how they will work with the end users to get the answers to the questions being asked. If they made it to the interview, then I already trust their resume, so I want to know how they "think". I want to ask questions to see their thought process. If they go straight to code when I ask them a question, they are not a good candidate as they will provide answers that don't meet the questions intent. I have a TON of end users who ask questions that are EASY to misinterpret and result in reports giving bad data IF you don't ask the correct questions. Jr. level you can train them to ask the correct questions. Advanced/Sr. level they should be able to ask the questions without coaching.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.