Quote:
Originally Posted by jjshabado
Dave, I recently had to do a pretty intense technical interview (on the not fun side), so I've been thinking more about how interview can be improved. A red flag for me is that you have interview questions that seem to be selecting people for how recently they read a SQL Cliff notes book rather than people who have actually done ****.
I don't actually have anything practical to add since I agree with you that it seems like people should know at least some/most of the stuff you're asking about if they actually had experience. Just may be worth thinking about.
I agree. As I said, I do want to try to test out something over the phone so I don't get a crash and burn when I ask them to select *. For example, if they claim to have built a database, I would expect them to have some notion of the data types they used. I mean, you can't even build a table without them.
It is also a very difficult place because I would love to find someone who is much more knowledgeable than I am, but it isn't possible in this situation. I certainly don't believe I have any notion of optimal style of interviewing. Not particularly experienced here.
Today, I interviewed someone and once again, got to GROUP BY on a breeze. I try to design the test so that each question will be the same as the last question with one extra line added. Naturally, the next line would be HAVING.
The common mistake (and I'm not even sure if this is only a PostgreSQL mistake, tbh) is to try to put WHERE somewhere in the query. Like the last person, this one freaked out and started putting all sorts of things into the query, adding aliases and so forth.
This one was a tad better at using a search engine. They opened a bunch of tutorial sites and was at times looking at the GROUP BY page, and the very next page was HAVING. It was the same feeling as watching those predator / prey nature videos.
After a few minutes, I suggested copy / pasting the error message into Google: found the answer in 5 seconds flat. The next question required a UNION which she nailed and then I asked to build a table, which had a minor thing I disagree with but oddly had a relatively unused concept in it. Auto increment? Never heard of it.
This is from someone who actually has some proper schooling and is teaching themselves RoR and has a few projects with databases to boot. Even sent a code example with her resume.
Not sure what the point of all of this is, but I agree that book <> real knowledge. I wouldn't know where theory and knowledge intersect properly. I have an applicant here that sort of knows what they are doing, has classical smarts, is an autodidact, but doesn't consider the error messages.
What am I supposed to do here? I have a fresh-face engineering student with strong credentials sitting across from me who, by all appearances, is extremely intelligent, but [snip] and is willing to take lower pay with a smile, and appears to want to try a new career already.
It was a horribly difficult experience for me. This person is the same as me: not enough confidence to get a real job and unemployed for a much longer time than they deserve. I ended up offering a position, but I feel highly conflicted about the situation.
Quote:
Originally Posted by clowntable
Always a good indicator that it might be time to change jobs soon.
This is part of the story as well. I'm not sure if I want to bother finding a new job or just striking out on my own. I'm partially seeking a replacement, but I'd probably have to find two people.
Quote:
Originally Posted by RoundTower
One of the most important and difficult things in an interview is to stop it being about the interviewer showing off how smart he is.
Yeah... I try to make it about the interviewee as much as possible, but I'm sure I accidentally come across as a conceited muckity muck as well.