Google second interview
The interview was totally brutal. It was worse than brutal, it was horrendous. It was absolutely horrible. But not the worst that I've experienced. The guy from Google starts out with:
Google: "How are you? Do you have some time to do the interview? It will take about 30 to 45 minutes."
Me: "I'm fine, I'm ready. Let's go."
Google: "Explain to me how path mtu discovery works."
I talked about DF (don't fragment) bits and the rest. I screw up and say the router will drop the packet silently. He grills me on it. I say I don't recall the correct sequence, but something like that. [I looked it up again. The router sends an ICMP 'can't fragment' packet.]
Google: "But why even have an MTU in the first place? Why can't we just send packets as large as we want?"
I talked about packet switching, router buffers, retransmission, routers getting tied up. I can tell I'm not getting anywhere on this one and he gives up.
Google: "What do you know about the 3-way handshake?"
I talked about syn, syn-ack, ack.
Google: "Why send the final ack packet?"
I talk about "that's how the RFC is written" :-P
Google: "Why can't the client just start sending data after receiving the syn-ack?"
I don't know. [I should have talked about the TCP state machine]
Google: "What are the file permission bits on a file that you know?"
I talked about read, write, execute, SUID.
Google: "How does SUID work?"
I talk about SUID.
Google: "What other flags are there?"
I remember vaguely the "t" bit on a directory and describe it.
Google: "What about the 't' flag applied to an executable?"
I don't know. [I did some research -- it's unused, but means 'text file' or something like that. I think the answer is that an executable file won't execute. I haven't tested it. I've never seen the 't' bit set on any file in 15 or 20 years.]
Google: "You mentioned inodes. What are those?"
I talk about inodes.
Google: "They're pointing to parts of the disk. What kind of information is stored on them?"
I talk about mod/access/create times. I talk about file permissions. I even remember reference counts for hard links.
Google: "Anything else?"
I can't think of anything. [I should look it up.]
Google: "If you are administering a system, and you think an intruder has broken into the system, what checks do you do?"
I talk about the file system integrity. A trusted 'ps' command to look for hidden processes. 'netstat' to show the network ports. Etc.
Google: "If you were an intruder and you knew that someone like yourself would check these things, how would you work around it?"
I talk about trying to name my executable 'bash' or even better 'httpd' to disguise my activities. I fail pretty miserably on this one. I never used a root kit.
I think I screwed the pooch really badly. Imagine what kind of people they hire if I can't get this position? I don't agree that these kinds of interviews work well and hire the correct people. But that could be sour grapes. :)
Google: "How are you? Do you have some time to do the interview? It will take about 30 to 45 minutes."
Me: "I'm fine, I'm ready. Let's go."
Google: "Explain to me how path mtu discovery works."
I talked about DF (don't fragment) bits and the rest. I screw up and say the router will drop the packet silently. He grills me on it. I say I don't recall the correct sequence, but something like that. [I looked it up again. The router sends an ICMP 'can't fragment' packet.]
Google: "But why even have an MTU in the first place? Why can't we just send packets as large as we want?"
I talked about packet switching, router buffers, retransmission, routers getting tied up. I can tell I'm not getting anywhere on this one and he gives up.
Google: "What do you know about the 3-way handshake?"
I talked about syn, syn-ack, ack.
Google: "Why send the final ack packet?"
I talk about "that's how the RFC is written" :-P
Google: "Why can't the client just start sending data after receiving the syn-ack?"
I don't know. [I should have talked about the TCP state machine]
Google: "What are the file permission bits on a file that you know?"
I talked about read, write, execute, SUID.
Google: "How does SUID work?"
I talk about SUID.
Google: "What other flags are there?"
I remember vaguely the "t" bit on a directory and describe it.
Google: "What about the 't' flag applied to an executable?"
I don't know. [I did some research -- it's unused, but means 'text file' or something like that. I think the answer is that an executable file won't execute. I haven't tested it. I've never seen the 't' bit set on any file in 15 or 20 years.]
Google: "You mentioned inodes. What are those?"
I talk about inodes.
Google: "They're pointing to parts of the disk. What kind of information is stored on them?"
I talk about mod/access/create times. I talk about file permissions. I even remember reference counts for hard links.
Google: "Anything else?"
I can't think of anything. [I should look it up.]
Google: "If you are administering a system, and you think an intruder has broken into the system, what checks do you do?"
I talk about the file system integrity. A trusted 'ps' command to look for hidden processes. 'netstat' to show the network ports. Etc.
Google: "If you were an intruder and you knew that someone like yourself would check these things, how would you work around it?"
I talk about trying to name my executable 'bash' or even better 'httpd' to disguise my activities. I fail pretty miserably on this one. I never used a root kit.
I think I screwed the pooch really badly. Imagine what kind of people they hire if I can't get this position? I don't agree that these kinds of interviews work well and hire the correct people. But that could be sour grapes. :)

0 Comments:
Post a Comment
<< Home