What are fair interview questions

Question

I had 2 recently I didnt think were fair.
1. was how would you recover a table to a point in time from a truncate without disturbing existing prod?
I said you had to rman restore elsewhere, roll forward with arc logs to last point before the trunc and then export or CTAS back to prod.
2. how do you deal with index contention oin concurrent inserts.
Without any further info I said evaluate the index in use to see if its the correct index type.
For 1, the Interviewer said well really it would be faster if you used your dataguard database and flashbacked. (could tell he wasnt impressed)
For 2, the Interviewer said well the answer I was looking for was if its for a sequence based table in RAC you could up the cache to a few thousand.
I could have got into arguments here with the interviewer but thought better of it, but next time I will argue.
Where did he get the replication features and rac sequences from? If theyre going to randomly throw features into the equation after the question, then Im bringing sybrand, tom kyte and jonny lewis with me on concall. (think of it like a phone a friend, if I win you split the pot). "Where did you get those guys from" the interviewer will ask, "The same place you got your dataguard and rac from" I'll answer.
whats fair and not fair in an interview?

Answer 1

>
I had 2 recently I didnt think were fair.
1. was how would you recover a table to a point in time from a truncate without disturbing existing prod?
I said you had to rman restore elsewhere, roll forward with arc logs to last point before the trunc and then export or CTAS back to prod.
2. how do you deal with index contention oin concurrent inserts.
Without any further info I said evaluate the index in use to see if its the correct index type.
whats fair and not fair in an interview?
>
Alls fair in love and interviews. What position were you interviewing for?
I don't see anything wrong with those questions - they are both fair questions. What is it about them that you think is unfair?
What other questions were ask before you were ask those two?
I would offer several suggestions
You should NOT offer an answer if you don't have enough facts to base the answer on; that's called 'guessing'. You either need to get the missing facts that you need from the person asking the question or make reasonable assumptions and base your answer on them. Always include your assumptions in the answer you provide.
Question #1 - you could have modified your answer to include assumptions and said something like
>
One way to do that if you use RMAN and archive logs are available is to restore the table elsewhere, roll forward with arc logs to last point before the trunc and then export or CTAS back to prod.
>
That answer provides information about the assumtions you made. They may not use RMAN and they may not be in archive log mode. You either need to find out those facts or include the assumption about them in your answer.
It also answers how you 'could' do it instead of how you 'would' do it; since how you 'would' do it might depend on whether dataguard is available. And you are free to include in your answer a phrase like - 'if dataguard is not available'.
Question #2 you said
>
Without any further info I said evaluate the index in use to see if its the correct index type
>
As I said above you either need to get further info or tell the interviewer what info you are basing your answer on.
Your answer suggests a good solution but doesn't include enough info to tell if you really know WHY the index type might matter.
My answer would probably begin with 'It depends on what is causing the index contention.' Then I would either ask for more information (e.g. type of index) or I would make a reasonable assumption and base my answer on that.
For example your answer is absolutely correct and easily defended (if they decide to argue) by adding some more information to what you said.
>
One cause of index contention with concurrent inserts is the use of a BITMAP index in an OLTP system. A bitmap index will serialize DML operations and can cause significant performance issues.
>
That is an absolutely correct answer even if it isn't the answer the interviewer wanted; you can defend it.
That puts the onus back on the interviewer to provide more information if they want a different answer.
Or you can ask questions to elicit more information if you want (I don't recommend that though once you give a correct answer) to cover other causes of contention
1. what type of index is it?
2. contention can be caused by a value for MAXTRANS that is too low.
3. contention can be caused by serialization processes used by the INSERT operation (complex trigger activity, sequence number generation (use of NOCACHE).
>
If theyre going to randomly throw features into the equation after the question,
>
That is EXACTLY why you have to make it clear to the interviewer what assumptions you are basing your answer on. That beats them to the punch. Give a correct answer using your own assumtions. Then if they throw in new information (replication, RAC) it becomes a new question rather than destroying the question you answered.
If you have read enough of these forum threads you should know by now that when it comes to Oracle most answers begin with
>
It depends . . .
>
If an interviewer doesn't provide enough information for you to provide a good answer then you are free to use your own reasonable information to base your answer on. Just be sure to tell them what those assumptions are as part of your answer.
Remember, even seemingly simple and obvious questions 'depend' on the assumtions you make.
Quick - how many bytes does the string 'CAT' take to store in a VARCHAR2(20) column?
Depends on the character set doesn't it? If you aren't told the character set use any set you like and base your answer on it. Using ASCII or UTF8 it will take 3 bytes.
Wait - is that right? Or was the interviewer asking about the actual BINARY representation which would then include a length byte?