This seems like kind of a trick question. The vast majority of interviewers want to hear what they want to hear, or at least have you agree.
We've all been conditioned to expect this. Then, here comes along someone with a different question where if you answer it differently, you probably don't get the job.
In my mind, I'm going to ask, "Is this a serious question? Are we just filling time?"
> Are you ready to be CEO of Google on Monday?" If they say yes, then I'll probably entertain myself by asking how they'd run the company while mentally moving on to the next candidate.
This question...it just seems so loaded and I have to disagree. I can get a 'no' vote (which is enough to end the interview process) because I give a silly answer to an uncertainly question.
If I say, "I want to build apps for non-profits" is that going to sink me during a QA interview? What if I say, "I want to enable non-profits with tech?" during a product or project manager interview? To me, both of those things are heavily intersected. But it seems like I can get stopped right there. God forbid if someone says they want to be a stay-at-home parent.
I'm going to cold read you and tell you what you want to hear.
I feel this question is less-than-helpful because it doesn't really extract any extra information yet is approached with a different angle to make the question intentionally tricky and make good candidates fail.
>> Are you ready to be CEO of Google on Monday?" If they say yes, then I'll probably entertain myself by asking how they'd run the company while mentally moving on to the next candidate.
> This question...it just seems so loaded and I have to disagree. I can get a 'no' vote (which is enough to end the interview process) because I give a silly answer to an uncertainly question.
It's a silly question, and the commentary about moving on to the next candidate shows ugly dismissiveness. What if the person sitting across from you COULD be the next CEO of Google, and you're blowing off a great find? It's not like there's only one person on Earth who is qualified to be the CEO of Google. Plenty of people could do it. I'd argue that the higher you go up the chain of command at any company, the less specific a skill set the position needs, to the point where many more people out there could be CEO of Google than could be Principal Compiler Technologies Engineer.
As others have mentioned, mostly the question is silly because, like most behavioral questions, the correct answer is: take some time to figure out what the interviewer wants to hear and feed it back to them.
> What if the person sitting across from you COULD be the next CEO of Google, and you're blowing off a great find?
Then hopefully you're not on Google's CEO interview committee, and the candidate is overqualified for whatever position you have, and hiring them comes with a risk of being unable to retain them when the much greater opportunity comes knocking, leaving you where you started but a couple of months down the line.
At least when I am the interviewer, the detail of what you say is less important than your humility, humor and at least some level of enthusiasm/passion for software/work. Hopefully in addition to your technical competence (but this is not the question to assess it) :-)
> Being able to take an idea and turn it in to a product is a brilliant skill that startups absolutely need, but equally, once the product is out there being used, you need the other skill set to maintain the product and add new things without annoying the users.
Frankly that's a potentially dangerous state of mind. Impulse you rather accomplish something little and get the glory or be on the team that got man on the moon?
In my opinion, it's amazing what you can accomplish when you don't care who gets the credit. You're stronger with others than on your own.
Anyways, I've been around engineering teams for a while now and here's what I mean: there's always some principal engineer or fellow (in the terms of a title) that is greatly esteemed and admired because of decades of progressively larger and larger feature creation and system architecture/leadership.
If all I ever do is fix bugs -- forever in my career -- it means I'm not going to build anything and I don't get to be on the team that gets the people to the stars because that team is reserved for aforementioned team of people who have built a lot.
I probably shouldn't be a programmer anymore since all I'm good for is fixing bugs.
Not you, but it's not you regardless of where you work if you're an employee. Glory comes from public recognition of your work. If that's what you're looking for, start something yourself. Or contribute to an open source project. Or write a book. Do something that will have your name put on it.
If you're working for someone else, and it's their name on the product, ignore glory and insist on money.
> ... start something yourself. Or contribute to an open source project. Or write a book. Do something that will have your name put on it.
You say this like I've not thought about it or tried it myself. :)
It's difficult since I don't know what I don't know. I stumble around trying to figure out what I need to figure out and come to realize that I don't know what goes where.
It's also difficult because of sheer time. I spend 13-14 hours going to work, being at work, or coming home from work. Whatever suggestion you have I've probably thought about or tried, so do be considerate if you decide to reply. ;)
Not to be a jerk but I'm going to sound like a jerk, but know it is from a position of love: linked lists and arrays are both fundamental data structures.
And let me relate to you: I get turned down for jobs all the time. It is not because of capricious reasons that I wish were the case, but it's because of me not knowing something. Yes, it's maddening because they throw out good candidates along with the bad to minimize risk to them. The same facts happen to me and you, but try to have the perspective on them be as positive as you can.
Well, the appropriate response is to politely ask for clarification. Sometimes asking a dumb question is a useful way to see how someone treats someone less experienced. I find treating interviewers with deep respect no matter how dumb they sound generally puts me in the drivers seat going forward.
If someone mentions array and list as alternatives in a generic CS context (not language specific), one generally familiar with the field should be aware of the concepts being referenced (one might reasonably ask to verify that the latter was a referenced to a singly-linked list, since while that's by far the most likely meaning in a generic context where it would be paired with an array, there are some other possibilities.)
That's not to say that failing to know that terminology should automatically result in rejection, but understanding that is not an unreasonable expectation when hiring something other than a narrow-focus language-specific code grinder.
I agree that the question needs improvement, it admits too much confusion unless there's a context. List is an ADT in Java and OCaml and some of the literature, an implementation in Python, C++ etc. Linked-list would have avoided that, although possibly suggests an answer.
Having said that, I'd be minded to look dimly on a candidate who tried to sidestep that question with 'but I use Python and they're the same there, so it's just a question of semantics' and did not try to clarify the question with me.
The most maddening part of seeing companies throwing good candidates out along with the bad is that it's actively harmful for getting good candidates. You're doing more interviews, which means more opportunities for a bad candidate to somehow slip through your filter.
It's a principle-agent problem - having a strict filter gives the interviewer a way to deflect blame when they hire a bad candidate. This is at the expense of the company both through additional bad hires and through extra time and money spent interviewing.
% cat > l.py
@profile
def slow_func():
for i in xrange(1048576):
continue
return -1
@profile
def fast_func():
for i in xrange(10):
continue
return -1
@profile
def the_func():
for i in xrange(10):
slow_func()
fast_func()
if __name__ == "__main__":
the_func()
% kernprof -l l.py
% python -m line_profiler l.py.lprof
Timer unit: 1e-06 s
Total time: 5.21814 s
File: l.py
Function: slow_func at line 1
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 @profile
2 def slow_func():
3 10485770 2644263 0.3 50.7 for i in xrange(1048576):
4 10485760 2573875 0.2 49.3 continue
5
6 10 5 0.5 0.0 return -1
Total time: 8.9e-05 s
File: l.py
Function: fast_func at line 8
Line # Hits Time Per Hit % Time Line Contents
==============================================================
8 @profile
9 def fast_func():
10 110 61 0.6 68.5 for i in xrange(10):
11 100 26 0.3 29.2 continue
12
13 10 2 0.2 2.2 return -1
Total time: 10.5501 s
File: l.py
Function: the_func at line 14
Line # Hits Time Per Hit % Time Line Contents
==============================================================
14 @profile
15 def the_func():
16 11 3 0.3 0.0 for i in xrange(10):
17 10 10549853 1054985.3 100.0 slow_func()
18 10 203 20.3 0.0 fast_func()
