What not to do during an interview(dandreamsofcoding.com)
dandreamsofcoding.com
What not to do during an interview
http://dandreamsofcoding.com/2014/06/29/interviewing-is-hard/
4 comments
I agree that people shouldn't exaggerate their skills but you need to be cautious about how you go about proving that they do not. It's easy to prove that someone is clueless by quizzing them about specific technical details or syntax. You will of course find something they do not know, but are you really trying to prove your own cleverness by catching them out? "You say you're an expert eh? We'll let me prove you're wrong and I'm smarter cause I'll ask arcane technical facts till I find something that shows you're not an expert!"
> I agree that people shouldn't exaggerate their skills but you need to be cautious about how you go about proving that they do not. It's easy to prove that someone is clueless by quizzing them about specific technical details or syntax.
I agree, which is why I gave GROUP BY HAVING as an example filter for 'advanced' SQL skills (especially as my team manages data warehousing and analytics).
It's not a minor implementation detail, it's the major tool for filtering on aggregated values - something like 'find customers who have purchased two more products in one month' can either be done as a query of an aggregated sub-query, or as one query using HAVING to filter for customers with a COUNT(*) > 2.
Again, this is only for people claiming advanced skills, and it's not that an 'advanced' feature. I don't expect every developer to know about SQL:2003's window functions, but HAVING has been around since at least 1992.
I agree with not asking silly technicalities, as a Java developer, knowing why new Integer(100) == new Integer(100) but new Integer(1000) != new Integer(1000) is an interesting piece of trivia, but using it in an interview is a waste of everyone's time.
I agree, which is why I gave GROUP BY HAVING as an example filter for 'advanced' SQL skills (especially as my team manages data warehousing and analytics).
It's not a minor implementation detail, it's the major tool for filtering on aggregated values - something like 'find customers who have purchased two more products in one month' can either be done as a query of an aggregated sub-query, or as one query using HAVING to filter for customers with a COUNT(*) > 2.
Again, this is only for people claiming advanced skills, and it's not that an 'advanced' feature. I don't expect every developer to know about SQL:2003's window functions, but HAVING has been around since at least 1992.
I agree with not asking silly technicalities, as a Java developer, knowing why new Integer(100) == new Integer(100) but new Integer(1000) != new Integer(1000) is an interesting piece of trivia, but using it in an interview is a waste of everyone's time.
[deleted]
So you're saying you think that questions on syntax are important. We'll have to agree to disagree on that.
That isn't a question on syntax, sorry. We'll have to very much disagree if you think this is just syntax. It's a core part of SQL that anyone with advanced SQL skills should at least be aware of.
Syntax would be caring if they put the ORDER BY in front of the GROUP BY.
Syntax would be caring if they put the ORDER BY in front of the GROUP BY.
Seriously - I remember once stating that I was skilled in Java (would never use the word 'expert', though).
The technical interviewers must have taken it as a challenge to them, as they spent 30 minutes quizzing me on all of the different executables that made up the JDK and all of the different arguments to them.
The technical interviewers must have taken it as a challenge to them, as they spent 30 minutes quizzing me on all of the different executables that made up the JDK and all of the different arguments to them.
I'm a recruiter and do technical interviews for a living. I almost never ask specific questions of syntax. You will incorrectly assess someone as not being knowledgable if your questions are about specific syntax and therefore possibly lose a great developer.
[deleted]
>Don’t swear
If it doesn't work out because I swear in the interview, it wasn't going to be a good culture fit in the first place. This goes both ways.
If it doesn't work out because I swear in the interview, it wasn't going to be a good culture fit in the first place. This goes both ways.
It's not a matter of it's a culture fit or not, it's a matter of showing that you care about the job.
We wear whatever the hell we want to at the office, but if I conduct an interview and the interviewee comes wearing jeans and a T-Shirt with holes, I problem will end the interview short and thank him for his time. If he doesn't care about this job enough to even make an attempt at dressing up then why waste our time.
Same with swearing. If you can't show to us that you care about this job enough to use professional language for an hour then I probably won't consider you past the first round. It's not whether we care about swearing, it's about proving to us you really want this job.
We wear whatever the hell we want to at the office, but if I conduct an interview and the interviewee comes wearing jeans and a T-Shirt with holes, I problem will end the interview short and thank him for his time. If he doesn't care about this job enough to even make an attempt at dressing up then why waste our time.
Same with swearing. If you can't show to us that you care about this job enough to use professional language for an hour then I probably won't consider you past the first round. It's not whether we care about swearing, it's about proving to us you really want this job.
> cares enough about his job enough to even make an attempt at dressing up
Why not be yourself and let the right role culture find you?
If my employer won't swear in the interview out of principle, we are a bad culture fit.
If my employer won't swear in the interview out of principle, we are a bad culture fit.
I agree. I was once interviewed by a company who asked me to look at a snippet of code and tell them what’s wrong with it. It was supposed to to be testing for a handle leak; open db connection without a corresponding close. But right smack dab in the middle was a SQL injection bug. As soon as they handed me the paper I let out a whispered “FUCK”. Everyone laughed, and the rest of the interview went well, up to the compensation package ;-)
"no one in her right mind will penalize you for not being immediately available"
Not deliberately, but depending on how bad they need to fill the hole, they may find someone good enough that they don't bother holding out to see if you're better...
Not deliberately, but depending on how bad they need to fill the hole, they may find someone good enough that they don't bother holding out to see if you're better...
And sometimes, no matter how much you read about interviews, you will suck at it.
Interviews are hard for some people.
Interviews are hard for some people.
This one. If you say you are expert/advanced at X, we will check for some level of competence. It's amazing how many candidates with CVs claiming 'advanced SQL skills' don't know about the existence of the HAVING clause. An exaggerated CV is a very easy filter.