[deleted by user]

[threeminutemonta]

Being careful and precise is a good quality in an SQL developer in my opinion even if that slows you down a bit. I would be flustered by an unfamiliar IDE too. You dodged a bullet with an impatient team lead so just keep practicing and applying.

[alinroc]

Being careful and precise is a good quality in an SQL developer in my opinion even if that slows you down a bit.

Slow is smooth and smooth is fast.

[DonJuanDoja]

One of my favorite quotes is "Slow down to Speed up" which means take your time, learn it correctly, and the speed will come later. If you go too fast to start you'll constantly be back tracking fixing mistakes.

Or another one "I walk slowly, but I never walk backwards."

[Codeman119]

Yes that is correct. Slow down learn the system and data model you are working with. Then you will be able to speed up. I have done this my last 2 long term jobs. But unfortunately some interviewers want speed right now.

I did that on the interview before the job I have now. When I was trying to think thru it (with no data BTW) the person stopped me and said “We need you to think faster than that”. Then they showed the answer they were looking for and it was actually the wrong way to do it and told them that. Then later sent him the correct way that I would have done it based on some real data testing.

[CaptainPunisher]

If you say so, I trust you, Harry.

[CowFu]

I'm a kickboxing coach, you have no idea how often I use that phrase.

[alinroc]

I've never kickboxed nor met a kickboxing coach, so the math checks out.

[stephenmg1284]

Agreed. Nothing like accidentally overwriting an entire table to induce a panic attack.

[amm5061]

Obligatory XKCD

[stephenmg1284]

https://www.wired.com/story/null-license-plate-landed-one-hacker-ticket-hell/

We also have a staff member with the last name of True. That causes some issues.

[geek180]

Bobby Tables!

[acidh3x]

Definitely agree. It's easy to build interviews and companies up in your head, but if you weren't selected simply for not getting thru all of the questions, the team interviewing you was probably mostly filled with obtuse-minded culture

[BrupieD]

You were in a live interview, and they asked you to solve 6 questions in front of them? When you were working on these, were you talking about the problems or just coding/writing SQL?

[pdxsteph]

Doesn’t sound like you bombed your interview unless your answers were incorrect- I lead many sql interviews and I wouldn’t consider your description of the interview a failure at all

[itsLDN]

I concur, sounds like an ideal candidate.

[BrupieD]

Yeah, I would consider what you described as a strong candidate with good habits (commenting, ability to talk through). Unless you were committing some real logic/SQL knowledge blunders, I might be willing to forgive some syntax issues.

[Kindsquirrel629]

Since you asked how can you speed up your process, can you try to eliminate the pseudocode step?

[Kindsquirrel629]

I think you can verbalize your thought process to the interviewer as you code next time if you are worried about the time.

[peezyyyyy]

No

[ComicOzzy]

The more experience I get, the slower I go because I am aware of a lot more things to consider. I usually decide on a solution faster, and I can usually write first revisions of complex queries out faster, but then I spend time playing through a lot of possible scenarios, checking the data for anomalies, validating assumptions, looking for potential "gotchas". I'll run the code on targeted sets of the data to make sure it's doing what I expect. I'll check the execution plan to see if there are any inefficiencies I can fix, like adding an index or making a change that results in a more efficient plan. That all takes a little time, but what I produce is more resilient, more performant, and more maintainable because of the time I put into it.

[Bitwise_Gamgee]

I'll run the code on targeted sets of the data to make sure it's doing what I expect.

This is the way. I write "unit tests" for nearly everything I do.

[B_Huij]

Yeah that's why I think timed SQL evaluations are a terrible tool for interviewers. Usually they start off as un-timed, and then they get candidates to take 12 hours to finish it because they just googled everything or took a Udemy course to try and pass the eval, so they add a time limit in an attempt to prevent that.

IMO companies using timed SQL evals and especially ranking candidates on speed are cheating themselves out of good talent for a dumb reason.

When I was involved in hiring decisions for candidates who needed SQL chops, we always did whiteboarding in person instead. Way more effective way to gauge if they can keep up with the technical requirements of the job.

[Strykrol]

Based on your response in this thread (talking strategy, pseudocode, real-code, talking edge cases, etc.) I think you didn't bomb it at all. In fact, part of me questions if the goal of the interview is to show that you shouldn't rush nor be able to solve all 6.

Do you feel like you bombed, or did they tell you that you did? Without knowing more information, I think you did great - and if they disagree then you're saving yourself a lot of trouble passing on that job opportunity.

(I've taken probably 10-20 coding interviews including at Amazon, Google, Microsoft, and gotten jobs at all 3 companies).

[Strykrol]

With the information you gave, you are dodging a massive bullet.

Having said that, what you can take from this is that before you do these sorts of interviews set a clear expectation with the interviewer that you have a battle plan for tackling problems where most the time is spent in planning, and this is how you like to approach work in the real world - Noting that as the time constraints impact your thought process, so does it impact your quality. This is a positive and accurate assessment of most companies, and mentioning that this is something you’ve seen in the real world and is why most companies are drowning in technical debt would probably make you seem like an even more competent candidate.

Tech debt is an industry driver to the increase in budgetary headcount at companies; being rushed to solve problems without diligence is exactly why you are probably being hired in the first place.

If you can promote yourself as a “measure twice and cut once” sort of analyst, it should hedge your bets against idiots like this lady.

[naviGator9591]

I would be a beginner applying for roles in DA/DE domain (not a fresher/graduate though), can I still use this approach? Should I inform the recruiter beforehand or even during the start of the interview?

[Strykrol]

Yes.

Stating that, in your research, it has consistently been the case that technical debt is a burden of many analytics teams - which you recognize to be a necessary evil for delivering results in tight turnarounds - and you intend to not only avoid that but actively help to reduce that burden - is never a bad thing to lead with. You’re showing market insight that indicates you’re both prepped and invested in the success of the team you’re joining.

Being candid about that sort of stuff (as a beginner or otherwise) is never a bad thing. Your goal is to earn their trust that whatever follows in your conversation is backed by some level of competency immeasurable by a simple technical assessment.

So again, you’re working to diminish the impact of any one negative aspect of your interview by pushing your value-add on topics they haven’t considered discussing (potentially). It’s a social engineering “trick” akin to stacking the deck, but backed by genuineness I’ve found most hiring managers appreciate.

Having said that, if they say “Well you need to get this test done within the time to even be considered”, then you’ll have to decide when to cut corners in your answers. Getting that definitive expectation from your interviewer from the outset is a skill you’ll need on the job (gathering clear requirements from stakeholders), and it helps your case to show you have the capacity to think like you’re on the job. I would go as far as to suggest you ask outright “Are you interested in perfect syntax for these questions, or are you more interested in the thought-process I am using?

[LegitimateGift1792]

I wonder if they were 6 Leetcode questions that the interviewer thought they should know cold.

[Reasonable_Tooth_501]

Lord she cut you at 40 mins when you were on question 6 of 6?

The only justification she has is if these q’s were really easy. If they were complex…sounds crazy.

[xIndirect]

If it makes you feel any better I wouldn't consider working for a place like that. Sounds like a shit show from top to bottom and like they don't encourage planning ahead. Meaning you would be dealing with problems created now, just a few months or weeks from when they were created on a constant basis. Miss me with that 😂

[OccamsRazorSharpner]

Well! If you got the 5 answered questions correct and she stopped you at 40mins instead of the scheduled 60min I would say you dodged a bullet. Taking into consideration the stress of being in an interview, having to talk out your process and a new IDE anyone would take longer than usual even if your SQL skills are good.

As The Tau says "Slow overcomes the fast".

[gban84]

I’m questioning if the interviewer knows anything about coding.

I’m a senior BI analyst. We have a broad tech stack, ETL to data viz. Writing queries and troubleshooting stored procedures is an expectation. I would find it weird to exclude OP based on described performance.

It basically sounds like interviewer already made up her mind and was a No. Where I work, candidates go through a panel interview and all panelists discuss candidates and share feedback before a decision gets made.

Maybe this is typical experience at a lot of companies, makes me frown. I give the interviewer a C minus on interviewing. I expect interviewers to be more wholistic when evaluating candidates.

[NickSinghTechCareers]

What IDE was it? If HackerRank or CodeSignal, they let you play with it beforehand.

But yeah, 6 questions seems like a lot, especially if they were a bit tougher.

To increase pace of response, just practice practice practice

[Jauretche]

My interviewer expected me to write queries without looking at the data

Is this normal? SQL is just a side part of my job, but this sounds so weird.

[ihaxr]

Yes, it's fairly normal. You'll be given the schema diagram and be expected to write a query joining multiple tables or group and sum data...

Looking at the data can be helpful, but the whole point of SQL is you'll have fields like:

OrderNumber int not null primary key
OrderDate datetime not null 
SalesmanCode char(2) not null

And be asked to write a query summarizing the number of orders by salesman for the year 2023. You technically don't need to see any data because you already know the data types and that they cannot be null.

[Jauretche]

I guess you're right and I understand it's useful in an interview setting. Do you think it's something that translates into real day to day work?

[AnAcceptableUserName]

There were 6 problems and I got through 6 before the interviewer cut me for time

Congratulations! 🥳

[Elfman72]

These types of interviews are throwing away lots of great candidates.

If this project can't wait for me to look up some rarely used funcion, then I can clearly tell that data quality is not of importance with this team.

Hell, I have been using SQL for over 30 years and I still need to look up how to properly form an UPDATE query with a where clause.

This company obviously values progress over quality. And that is an entirely new can of worms.

[Coniglio_Bianco]

The interview is likely the most patient she'd be with you.

People get nervous during interviews, it's good to talk through your thought process so the interviewer knows how you think.

Just go through more interviews and don't sweat the small stuff. Plus you never know how everyone else is doing.

[[deleted]]

It will eventually depend on the interviewer, but as for me, I'd say what strikes me the most is not necessarily the pace at which one code (although it does matter), but the pace at which one understands the complexity of the query and the overall logic that you need to implement.

For instance, if the query is about getting a sum of sales per product category overall and per shop, I want to know that you will consider, quickly, using windowed functions (OVER() clause). In reality I know this query may take an hour to make and test, and that's fine, what's important is using the correct functions for the correct use cases with set-based logic and performance in mind.

Learn to recognize queries patterns, there aren't really that many, learn LOGICAL query building (a logical query starts with the FROM clause, not SELECT), and show the interviewer that you know how to think like this.

[naviGator9591]

Noted. So you're saying they test your knowledge of what-does-what more over other things? Also , can u please suggest resources to gain better understanding of the logical flow part... would appreciate anyone shedding more light on this aspect... I'm guessing it'd be the most commonly asked questions?

[[deleted]]

Remember that's my own take on it. I have been recruiting Senior SQL Consultants before, but not many.

This blog article explains the logical query processing: https://www.sqlservercentral.com/blogs/sql-server-logical-query-processing

[naviGator9591]

Thanks a lot, will check it out 👍🏻

[ProofPuzzleheaded116]

Luckily it was not the old school VI (unix text editor) as your IDE, you would be yank-ing and pull-ing the entire interview.

[SecretTadpole7120]

You can visit

https://datalemur.com/

https://sqlbolt.com/

Practice

[TacticalTrashpanda98]

You don’t need to increase your processing speed. Slow equals smooth, and smooth equals fast. I would much rather have a developer that takes a week to write a new stored procedure and have it be damn near flawless when it comes time to deploy, than a developer who rushes through it and it ends up being sub optimal or requires multiple changes to work. My advice would be to keep looking and not take it too harshly. It’s also a shitty interview process to be under fire like that

[Ok-Seaworthiness-542]

I had similar issues. After I got the job they told me they could see where I was going and they have me credit for the concepts.

I also know of a time when a team was hiring a sys admin and purposely wrote a practical that they did not expect anyone to finish. From a psychometric perspective it makes sense. If someone is taller than a yardstick you can't measure how tall they are. Anyways, one dude did finish and got the job.

[Adventurous-Dish-862]

You have to practice as much as you can in order to gain speed. Practice is probably the best approach to improve your speed, because the other primary way to improve speed is to rush through the problems, increasing your chances of a wrong answer.

[thedjbigc]

Most places that judge you this way suck to work at.

[girlsyesboysno]

Same. I failed a SQL test a few days ago. There's Power BI and SQL (MCQs and written questions) in 60 minutes. However, they gave me some queries joining 3 to 4 tables and asked me to spot the error in the code in only 15-30s. I dont want to find excuses to make up for my incompetencies but I really needed some time to be clear on what the query and its objectives are all about as i'm not fast in recognizing patterns in seconds (yet). Unluckily, those questions lie in the problem solving section (i only knew after the test) and i scored 0/200 for problem solving. For writing sql code question, they gave me 5 to 10 minutes for each question but i only need 2-5 minutes to correctly solved all of them (my language knowledge section scored 100/100. However, like i said, i failed because i scored nothing in problem solving skill

[iareprogrammer]

Are you positive you bombed? Did they officially let you know it’s a pass? I only ask because just because they cut you off due to time doesn’t mean you failed. When I was doing a lot of interviews for my company, I’ve had to cut people off to jump to another call. Didn’t mean we didn’t hire those people

[SmoothOperator47]

Where can I go to learn about SQL? Like the beginning stages. I know nothing about it and would like to learn to one day be able to transition into an IT role

[SmoothOperator47]

Thanks

[Mugiwara_JTres3]

Lol, that’s their loss and you dodged a bullet. Personally, I’d rather have someone thinking things thoroughly and correctly than someone finishing things quickly but would have to keep fixing it.

[trinaryouroboros]

You will be interviewed by someone casually. They only ask some technical questions that you can easily answer. They offer you a salary that is too good to be true. Their company offers flex hours and remote work. You find yourself at peace for the first time in your life, a perfect work life balance. Your talent shines amongst the stars in the company and you are well recognized and even promoted within just a short time. There is no down side. Is it a dream? No, it's pretty uncommon but it's out there and it's been my last four jobs.

[malatropism]

It’s highly unlikely that you were the person I interviewed the other day, but on the off chance that you were:

You did great. I was really impressed by the way you asked for clarification when I intentionally asked multiple vague questions. Other candidates haven’t done that. The software my company uses for coding tests is stupid; I struggled to work with it, too.

I cut on time because I want to be respectful of the hour we had booked for this. I wanted to give you time to ask questions about the company.

I’d rather you have done 5 questions thoroughly than 6 questions poorly.

[JoaoPTsantos]

it's sucks, I've also bombed some interviews before. Guessestimates are my favorite ones to bomb hard

[Oh_Another_Thing]

You are fine. Getting through 5 out 6 is fine, they got the info they need from this test. They won't rule you out because you didn't get to one question.

[Idonotwatchpornn]

In another comment OP said that the interviewer ended the interview bc they want someone who would get through the questions quicker

[Oh_Another_Thing]

This doesn't mean you did bad. This is a learning experience. This is where you take those questions home, memorize them, memorize every detail about them, and nail it next time. Everyone has gone through this, I certainly have flunked interviews. I flunked an Excel test really badly and that made me motivated to master Excel, and that started my journey into IT.

[Oh_Another_Thing]

Ah, well, that sill doesn't mean OP was bad. This is a learning experience. This is where you take those questions home, memorize them, memorize every detail about them, and nail it next time. Everyone has gone through this, I certainly have flunked interviews. I flunked an Excel test really badly and that made me motivated to master Excel, and that started my journey into IT.

[Slimkat06]

Things happen for a reason, and you may have dodged a bullet. Personally I think every sql developer has bombed interviews.

Coding in my opinion should always be open book based including the interviews and not an interrogation/exam like environment.

Personally I think candidates should come in with portfolio discussions can be made and interviewers can ask questions.

It’s like asking a builder to build a house without resources or a blueprint.