Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking a Google Interview - MIT's guide to Google interviews

courses.csail.mit.edu

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Hacking a Google Interview - MIT's guide to Google interviews

#21

Post by jonsen »

gizmo wrote: post #3

They get the definition of polymorphism wrong, because their definition ("ability of one method to have different behavior depending on the type of object it is being called on / object passed by parameter) is also met by compile time function overloading. Their example, where you have a customer integer class that is capable of dealing with both other integer arguments and floats is pretty poor. Any definition of po…

Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time.

Yes

  class A { ... f() ... }
  class B extends A { ... f() ... }
  class C extends A { ... f() ... }
  A x =  ...  // a B object or a C object
  x.f()
is polymorphism if anything.

Re: Hacking a Google Interview - MIT's guide to Google interviews

#22

Post by arakyd »

sorbits wrote: post #15
bsaunder wrote: post #8

Earlier quoted context omitted.

Complexity can sometimes be a perspective thing. I recall a discussion at one point with a co-worker were we were each arguing that the other persons approach to a particular problem was more complex. After much contemplation I was able to see both perspectives. Also with some problems there seems to be a conservation of complexity notion. It's inherent in the system and depends on where you push it. For the book, yo…

Yes, I agree that a lot about how to structure code is subjective, which is also why I am very interested in having better terms to describe this — thanks for the book suggestion! Giving it some more thought, I think it boils down to realizing when one is solving more than one problem, and then being able to write the code so that each problem is solved in isolation, yet without introducing complex APIs between the d…

My favorite book of this type is Thinking Forth, available online at http://thinking-forth.sourceforge.net/. You will get a large dose of the Forth mindset, but it's mostly higher level design tips and not as specific to Forth as, for example, How to Design Programs (read: Functional Algorithms in Scheme). It's a fun read, and a great way to get a perspective on design that is different than what you get from the usual object-oriented or functional language centric sources.

Re: Hacking a Google Interview - MIT's guide to Google interviews

#23

Post by rglovejoy »

kraemate wrote: post #5

Are there any MIT students who would not know these things? Big-O notation etc?

Probably, if the student was not an EECS major. I studied physics there, and Big-O notation was not something that came up. Heat and entropy, however, was things that we talked about a lot.

Re: Hacking a Google Interview - MIT's guide to Google interviews

#24

Post by biohacker42 »

nebula wrote: post #12
gizmo wrote: post #3

They get the definition of polymorphism wrong, because their definition ("ability of one method to have different behavior depending on the type of object it is being called on / object passed by parameter) is also met by compile time function overloading. Their example, where you have a customer integer class that is capable of dealing with both other integer arguments and floats is pretty poor. Any definition of po…

Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time. At least in C++ world, it's not true. There things like compile time polymorphism, and run-time polymorphism. And by the way, why do you think polymorphism should be based on run-time data? simpler things can be achieved at compile time with static…

Whenever I think of polymorphism in C++, I think of base pointers, virtual functions and the vtable. I guess my mind just puts run time and compile time in separate boxes.

Re: Hacking a Google Interview - MIT's guide to Google interviews

#25

Post by simplegeek »

mrshoe wrote: post #18

I've interviewed with Google, Apple, and Microsoft. It always strikes me that the questions they ask you during interviews are not at all representative of what you need to be able to do on the job. That's why these course materials are incredibly valuable. You have a better shot at these types of interviews coming straight out of college than you do after X years of job experience. The interviewing mindset is very d…

Man, you can do good at copy-writing. Actually, I found your reply quite appealing and it follows some guidelines of lots of copy-writing books that I'm trying to read these days. But,anyway, thanks for sharing.

Re: Hacking a Google Interview - MIT's guide to Google interviews

#26

Post by d0mine »

smanek wrote: post #9
bsaunder wrote: post #6

Earlier quoted context omitted.

Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time. I'm not sure that's always true. Or at the very least seems language dependent.

Yeah, Java doesn't do multimethods (i.e., method dispatch based on runtime argument types). If Class X has two methods: void foo(Object i); void foo(Integer i); then: Object test = new Integer(4); X x = new X(); x.foo(test); will invoke 'void foo(Object o);' based on the compile time type of test. Java does do dispatch based on the runtime type of X - but it is quite limiting once you are used to having proper multip…

You're right. It calls 'void foo(Object o);'

    import junit.framework.TestCase;
    
    public class TestMultimethods extends TestCase {
        public void test() {
          Object test = new Integer(4);                                        
          X x = new X();                                                       
          assertEquals(x.foo(test), "foo(Object)");
        }
    }
    
    class X {
        String foo(Object i) { return "foo(Object)"; }
        String foo(Integer i) { return "foo(Integer)"; }
    }

Re: Hacking a Google Interview - MIT's guide to Google interviews

#29

Post by andreyf »

simplegeek wrote: post #25
mrshoe wrote: post #18

I've interviewed with Google, Apple, and Microsoft. It always strikes me that the questions they ask you during interviews are not at all representative of what you need to be able to do on the job. That's why these course materials are incredibly valuable. You have a better shot at these types of interviews coming straight out of college than you do after X years of job experience. The interviewing mindset is very d…

Man, you can do good at copy-writing. Actually, I found your reply quite appealing and it follows some guidelines of lots of copy-writing books that I'm trying to read these days. But,anyway, thanks for sharing.

it follows some guidelines of lots of copy-writing books that I'm trying to read these days

Agree that the comment was good, what guidelines are you thinking of?

Re: Hacking a Google Interview - MIT's guide to Google interviews

#30

Post by andreyf »

gizmo wrote: post #3

They get the definition of polymorphism wrong, because their definition ("ability of one method to have different behavior depending on the type of object it is being called on / object passed by parameter) is also met by compile time function overloading. Their example, where you have a customer integer class that is capable of dealing with both other integer arguments and floats is pretty poor. Any definition of po…

Actually, polymorphism is when two or more clearly different phenotypes exist in the same population of a species — in other words, the occurrence of more than one form or morph.

Polymorphism is certainly not a very well defined notion. Personally, I think the best answer would be "I don't know a precise definition, I've heard it mean different things based on context, for example...".

Post reply on HN