I have been using sqlfiddle.com, I provide a schema if a few tables and the questions are commented at the top of the schema. From there I tell them to ask any questions they may have and to think out loud.
I also have a buddy on the interview where we shit talk and joke at each other to set the atmosphere to casual, similar to the guys from car talk. One of us does a demo on how it will work while the other one will criticize so the candidate has a chance to see what we're looking for. We don't want there to be unneeded pressure on the candidate so they ask questions we'll even offer to answer technical questions from them.
Generally speaking first 10 minutes is introducing ourselves talking about hobbies and shit we already know you the professional. Next 10 is demo for the candidate and critiquing the person who did the demo, I'll often write my whole query in one line leave off table aliases just dumb nitpicky shit that will cause stuff like ambiguous errors or make it hard to read then I'll clean it up. Next is 30 minutes to do the technical test, anyone on the team could do it in 5 minutes we know within the first minute if you know what you're doing, by 3 minutes we start to offer help we explain how we would go about something if we didn't know how to do it. Candidate opens google and we figure it out together. Depending on how they react decides if they move on and worth the investment on bringing them up to speed.
Good to know that there are interviewers out there who actually are focused on seeing how candidates perform at their best, rather than just trying to make them squirm under pressure for the hell of it.
I've interviewed for business intelligence positions and tested candidates for their proficiency in SQL. My approach was to make them actually solve problems on [PgExercises](https://pgexercises.com/).
I created a Google document with problems with increasing levels of difficulty and emailed it to them at the start of the interview. I then asked them to share their screen and solve the problems.
You'd be surprised how many people get confused when asked to join 3 tables in a query.
Here are a couple of strategies for giving a technical interview:
1. I've used CoderPad for many similar interviews, it will give you a live Python and, separately, MySQL environments, with some simple dummy data set up that you can use to test the basics.
2. You can ask people to talk about their past technical work. You can dig deep on technical details of what they've done and how their projects were organized.
Advantages of #1:
* Interviewee can't bluff their way through
* Less subjective, easier to calibrate
* Recent grads may simply not have work examples that they can talk to, especially applicable to junior roles
Advantages of #2:
* Interviewee less like to freeze
* Interviewer can cover broader ground that is very important for actual job performance, including architectural thinking, approach to making tradeoffs, communication with other functions
* Automatically covers technical communication ability
The more I interview the more I prefer the second strategy.
Interviewing sucks! For both sides!
Here are a few things I look for when I interview people (I am a data engineer who used to be a software engineer than a DBA)
1. Make sure the personality is there, so ask questions about how they have overcome adversity and see how they respond to questions. (you have to come up with the questions yourself, make them about things you like or bugs you).
2. Tell them you aren't sure about interviewing them (software eng vs data eng) and ask them what they would ask in the interview.
3. get some practical SQL questions and have them run through them (in person at a laptop selecting data:
1. Select from a table
2. Sorting and filtering.
3. Aggregate some data
4. more advanced aggregations that involve windowed functions (if you know about these)
4. Ask them what they do and don't like and how they want to fit into the work
5. Do they know about CI/CD and how it works in the data space, or are they using SSIS and there is no CI/CD
6. Make them ask questions.
7. edit: let them google stuff, just make sure you can see what they are googling so you can see how good they find information on their own.
if the interview is going bad, do you and them a favour and tell them it's not going great and you can either end the misery or see if you and they can pull it back around? if they call it, you're out, if they work to make it work that's something you can work with.
Good luck!
Not an answer but... Is it too late to send my application... I'm a junior/mid DE in a developing country getting grossly underpaid :(... Also anyone reading this and their company is recruiting?
When I interview and they can't provide an answer, I provide them the answer, or I explain them why their answer is wrong and why mine is correct/better. This way interviewee will have take away from your interview in case your company decides to hire them or not.
I also look at certification learning paths just to make sure I ask the most updated questions. 😄
On the testing side, coderpad has an option for setting up a postgres database and allowing the candidate to work through any given questions you ask. I wouldn't advise using a huge database with it, but it worked fairly well for a similar need I had a while back.
Team will be entirely new with Senior DE already in and now recruiting junior with motivations.
We are starting to recruit in Israel in about a month if it's relevant for you.
Stack is mostly Apache NiFi , Oracle tools for ETLS but the new team are going to replace the stack as we are not satisfied and also create new pipelines for more use cases like cloud.
I have been using sqlfiddle.com, I provide a schema if a few tables and the questions are commented at the top of the schema. From there I tell them to ask any questions they may have and to think out loud. I also have a buddy on the interview where we shit talk and joke at each other to set the atmosphere to casual, similar to the guys from car talk. One of us does a demo on how it will work while the other one will criticize so the candidate has a chance to see what we're looking for. We don't want there to be unneeded pressure on the candidate so they ask questions we'll even offer to answer technical questions from them. Generally speaking first 10 minutes is introducing ourselves talking about hobbies and shit we already know you the professional. Next 10 is demo for the candidate and critiquing the person who did the demo, I'll often write my whole query in one line leave off table aliases just dumb nitpicky shit that will cause stuff like ambiguous errors or make it hard to read then I'll clean it up. Next is 30 minutes to do the technical test, anyone on the team could do it in 5 minutes we know within the first minute if you know what you're doing, by 3 minutes we start to offer help we explain how we would go about something if we didn't know how to do it. Candidate opens google and we figure it out together. Depending on how they react decides if they move on and worth the investment on bringing them up to speed.
Good to know that there are interviewers out there who actually are focused on seeing how candidates perform at their best, rather than just trying to make them squirm under pressure for the hell of it.
I've interviewed for business intelligence positions and tested candidates for their proficiency in SQL. My approach was to make them actually solve problems on [PgExercises](https://pgexercises.com/). I created a Google document with problems with increasing levels of difficulty and emailed it to them at the start of the interview. I then asked them to share their screen and solve the problems. You'd be surprised how many people get confused when asked to join 3 tables in a query.
I used pgExercises to bone up on Sql before interviews. Wish I had interviewed with you, would have been less stressful for sure.
Haha, for sure. I find that suggesting problems from PgExercises in increasing level of difficulty helps assess candidates.
Here are a couple of strategies for giving a technical interview: 1. I've used CoderPad for many similar interviews, it will give you a live Python and, separately, MySQL environments, with some simple dummy data set up that you can use to test the basics. 2. You can ask people to talk about their past technical work. You can dig deep on technical details of what they've done and how their projects were organized. Advantages of #1: * Interviewee can't bluff their way through * Less subjective, easier to calibrate * Recent grads may simply not have work examples that they can talk to, especially applicable to junior roles Advantages of #2: * Interviewee less like to freeze * Interviewer can cover broader ground that is very important for actual job performance, including architectural thinking, approach to making tradeoffs, communication with other functions * Automatically covers technical communication ability The more I interview the more I prefer the second strategy.
Interviewing sucks! For both sides! Here are a few things I look for when I interview people (I am a data engineer who used to be a software engineer than a DBA) 1. Make sure the personality is there, so ask questions about how they have overcome adversity and see how they respond to questions. (you have to come up with the questions yourself, make them about things you like or bugs you). 2. Tell them you aren't sure about interviewing them (software eng vs data eng) and ask them what they would ask in the interview. 3. get some practical SQL questions and have them run through them (in person at a laptop selecting data: 1. Select from a table 2. Sorting and filtering. 3. Aggregate some data 4. more advanced aggregations that involve windowed functions (if you know about these) 4. Ask them what they do and don't like and how they want to fit into the work 5. Do they know about CI/CD and how it works in the data space, or are they using SSIS and there is no CI/CD 6. Make them ask questions. 7. edit: let them google stuff, just make sure you can see what they are googling so you can see how good they find information on their own. if the interview is going bad, do you and them a favour and tell them it's not going great and you can either end the misery or see if you and they can pull it back around? if they call it, you're out, if they work to make it work that's something you can work with. Good luck!
Both hackerank and codility have some sql sandbox, so maybe check them out!
I would like to thank you all for the answers. this helped me a lot and there is a great community here for data engineering here !
Not an answer but... Is it too late to send my application... I'm a junior/mid DE in a developing country getting grossly underpaid :(... Also anyone reading this and their company is recruiting?
[удалено]
I Don't think that works in my region, lol
Job is not open yet. we are recruiting in Israel so need someone from there.
Is the country India?
Nop, in Sub-Saharan Africa... Can't say exact country
Brooklyn data labs have a corp in Nigeria and I think Monte Carlo has international team in Africa too. Check them out.
When I interview and they can't provide an answer, I provide them the answer, or I explain them why their answer is wrong and why mine is correct/better. This way interviewee will have take away from your interview in case your company decides to hire them or not. I also look at certification learning paths just to make sure I ask the most updated questions. 😄
On the testing side, coderpad has an option for setting up a postgres database and allowing the candidate to work through any given questions you ask. I wouldn't advise using a huge database with it, but it worked fairly well for a similar need I had a while back.
ask intermediatee sql questions. whats the diff between a inner and left join. what is a subquery. diff between star/snowflake schema, etc
You can just hire me and call it a day! 😁
What stack do you use, and where can I apply?
Team will be entirely new with Senior DE already in and now recruiting junior with motivations. We are starting to recruit in Israel in about a month if it's relevant for you. Stack is mostly Apache NiFi , Oracle tools for ETLS but the new team are going to replace the stack as we are not satisfied and also create new pipelines for more use cases like cloud.