Log in

Facebook job screen

I had a phone screen with a Facebook recruiter earlier today for a position in their network engineering group. They have many interesting projects to support their network infrastructure including datacenter architecture, connectivity, and automation. The screen had two parts – one in which the recruiter asked me some general questions about past jobs and my current activities, and another consisting of directed questions. The questions were generally of the same nature and difficulty as those in this NANOG thread about interview question suitability. I don't remember everything that I was asked, but I made some mistakes. Also, in some cases, I said I could not remember the answer, but would be able to give the answer if I looked it up. The recruiter was nice enough to say that it's expected that I wouldn't be able to answer some questions, because it's been a while since I've worked with these things on a regular basis.

As always, we'll see what happens. I think I could have done better. Everything I was asked is something I have been familiar with (at least) at one time – it's just that I didn't remember some things.

Apr. 24th, 2015

I was extremely annoyed after spending an hour applying for a Broadcom job. They switched to a new "talent management" provider, so I had to resubmit my resume. Their process of extracting items from a resume is one of the poorest I've used, so I had to correct quite a bit of information. There were several other problems. Perhaps this technology saves time and money for companies looking to hire, but it is very cumbersome and time-consuming for the individuals they seek. Years ago, when people just sent resumes to companies through the postal system, it was an easy process of putting the resume in an envelope, addressing it, stamping it, and dropping it in a mailbox. So much for progress ...
Earlier today, I applied for a network development engineer position at Dell. Taleo handles their applications. Part of the application process involves acknowledging having read a Notice of Convictions document. However, at the time I applied for the position, I could not access the document, because I could not obtain an IP address for the domain name in the document's URL.

So here is the dilemma. Would it be better to answer truthfully, indicating that you did not read the document (if you could not access it)? Would it be better to indicate that you did read the document, even though you did not, because you attempted to access it? Or is there some other alternative, but you pay an "opportunity cost" for choosing it (namely the time spent on it)?

I decided to use the "attach" feature Taleo provides to attach a note indicating that I did attempt to access the document, but DNS queries failed (using two different ISPs) for the domain name in the URL. My reasoning was that this is something Taleo (or Dell) may be doing to filter candidates – at the very least, catching those people who were not honest about not reading the document (if they could not access it). It could also serve as a filter for those people who, rather than giving up on a problem, investigate it and attempt to find out what is wrong. Arguably, this is part of the skill set for the position I applied for.

As always, we'll see how it goes. But it did occur to me that this might be a sly way of filtering candidates.

Infoblox phone screen

I had a phone screen with Infoblox last Tuesday for a Principal Software Engineer, Server position. I was in the midst of taking care of some family issues before leaving town, so in general, I did not perform as well as I might have otherwise.

"Are you currently working?"

No, not currently.

"When was the last time you worked?"

December 2010.

"Why did you leave your job?"

To take care of personal and family issues.

"What are your strengths?"

Protocol conformance, performance, and scalability.

"In HTTP, what is the difference between how are parameters are passed in GET and POST?"

I wasn't sure, thinking he wanted information about headers that are used to pass information to the server. When I realized he meant URL parameters, I said via key/value pairs. (I probably should have given more information, e.g. http://example.com?key1=value&key2=value.)

"In DNS, what is the difference between a recursive and an iterative query?"

A recursive query returns the answer (if it exists). An iterative query returns the address of another server that should be queried.

"How is DHCP used by a client to obtain an IP address?"

The interviewer's accent was very thick, so I wasn't sure whether he had said DHCP or HTTP. When he clarified, I wasn't sure at first, so I had to think about it, and said that I didn't remember the details, but a special DHCP request packet is sent to an IP broadcast address. (I probably should have said that I would use the DHCP RFC to get the details.)

"What data structure would you use to get the most used IP address in a log file?"

After getting clarification of what type of log file he meant (ie. is it like an HTTP access_log), I said a simple way to do it was a hash table, keyed by IP address, such as is used in Perl.

"What is the difference between bubble sort and merge sort, and what are their orders of growth?"

I said bubble sort is an exchange sort with an O(n2) order of growth. In merge sort, the list of items is successively halved until individual items can be (pairwise) sorted, then the sorted lists are merged. Its order of growth is O(nlogn). He was pleased that I remembered the orders of growth.

"What programming languages have you used the most?"

C and Perl.

"Have you done any object-oriented programming?"

I said that I have programmed in Java and Python, but not recently.

"Have you done any multithreaded or multicore programming?"

Multithreaded yes, multicore no.

"When using sockets, what is the order of system calls required to set up connections between a client and a server?"

I couldn't remember what to do for the client side after doing a connect(). I asked for more time, but still couldn't remember, so I just said so, but I had done it before. (I probably should have said I'd check the man pages, at least. More on this later.)

"Are your family issues resolved and could you start working?"

I said I hoped the family issues were resolved.

He then asked if I had any questions. In response to the usual questions I ask, he said that the engineering group has about 60 people located on several continents. However, his group has between 20-30 people. He doesn't write code anymore; he is more involved in project planning and hiring. In closing, he gave the indication that I might fit in better with a protocols group, and that he would send my résumé to some of the other managers to see what they thought. (I wasn't sure whether or not that was a good sign.)

So, as always, we'll see. I wasn't very happy with how I did on the sockets question. I've been asked that before, and done better, but this time, I didn't. On the way to the airport on the day after the phone screen, I spent some time reviewing the OpenBSD system calls related to client and server connection. (I'll go over the Linux system calls also. Although I don't think they differ substantially, it can't hurt to check, just in case.) However, I don't think the socket question was difficult (if you know in advance you're going to be asked it), but it's not something that someone is necessarily going to remember. When working on a nontrivial piece of code that uses sockets, the socket setup and any other associated system calls are usually the first part of the program written, so that basic interaction with peers can be established. After that is working properly, most of the attention is given to adding new functionality, resource management, debugging, etc.

Juniper phone interview

I had an interview last Friday morning at 8am (!!) with the hiring manager for a JUNOS (Juniper OS) engineering group. He asked me a lot of questions about things that are on my resume describing things that I do while not being currently employed. (Recall that I was advised some time ago by a Cisco recruiter that I should not leave any gaps on my resume, or else no one would consider it, treating me as if I was trying to hide something.) So we talked about some of my recent activity with IETF WGs, such as getting RFC 796 moved to Historic status, because it references IPv4 networks (and addressing schemes) that are very out of date. He also asked me to explain how the Equinix MLPE route servers worked, and how my provisioning code produces their configuration files.

He then asked me a lot of questions about what type of work environment I was looking for. I told him about wanting to continue to be involved with the IETF community (if possible), being in the loop of (technological) progress, and having authority commensurate with responsibility. He seemed to pick up on the latter point, because he said he tries to run his group that way. However, he did warn me that there are times when people are expected to work as much as 80 hours per week, even handling customer issues directly. I said that wouldn't be a problem, since I've had to do that for most of my career anyway.

He then told me that he'd like me to come in for an in-person interview. He asked how much programming I had been doing during this period of unemployment, especially C programming. I said that I have written code in several languages, depending upon the project in question. He cautioned me that the interview would be very difficult, involving questions about data structures and algorithms in C, because the engineers on his team make the questions very difficult. He asked me how I felt about that, and I said that I would just do the best I can, and that everyone experiences the same feelings on these types of interviews.

So, we'll see. (Nothing has been scheduled yet because of the Memorial Day holiday weekend.) But one thing that is now very very clear to me is that there is no substitute for the type of interview practice I have been doing. The competition is too stiff, and the interviews themselves too challenging, not to spend time developing code, studying algorithms and data structures, getting involved with open-source projects and/or standards bodies, etc.

Cisco coding test

I'll give a brief overview of the coding test I had a couple of weeks ago. I was told to verify that Cisco WebEx worked prior to the test, which I did to the best of my knowledge several days before the test. However, on the test day, it was necessary to download and install a client after the meeting began. I was able to download the client, but for some reason, it would not install. After some back-and-forth with the interviewer that took almost a half hour, we switched to a shared Google Doc, and the test began.

"Write a function in C that returns the largest signed integer supported on the system the code will be running on."

I thought this was something that was defined in a header file somewhere, so I asked if I could look at some header files. The interviewer said not to make any assumptions about the hardware, so I said OK, but I would still need to include some header files anyway so some declarations would be recognized. I didn't find what I was looking for in the header files, but I did think of a way to do this for a 32-bit signed integer. (While out walking, the way to do this for an arbitrary sized signed integer occurred to me. Oh well.)

"Implement a function in production quality code, file_copy(), that takes two pathnames, copying the contents of one to the other."

I asked if it needed to return a particular error code in case of failure, and he said I could define that myself. I also asked if these were regular files (so ordinary calls to open(), read(), etc. would work), and he said yes. He also said it was OK for me to refer to man pages, which was good, because I don't remember the order of arguments to open(), read(), etc. So I proceeded to write a simple version of it, where any failure to do anything would close all open descriptors and return an error. After I was done, I told him that at this point, I would test it to see if I had made any mistakes. He then asked me if there was a way I could make the function more robust (e.g. if there was a partial write()). I understood what he was asking, and made a few changes, but because the actual typing using Google Docs had taken longer than if I'd been allowed to use a text editor or an IDE, a lot of time had passed, so I used a goto to break out of an inner loop instead of doing more of a rewrite.

At this point I was feeling tired, having been up late the night before doing something I would have done earlier if it had not been for some personal issues that had come up earlier in the day. My right shoulder also started bothering me. The interviewer needed to take a break, which was good, because I did also.

"Given the root of binary search tree, and two nodes, find the lowest common ancestor."

This is one of those "standard algorithms" that I don't remember off the top of my head, but I figured it could be solved by traversing the tree recursively. I started to write some code to do that, but I started feeling even more tired. I wasn't really getting anywhere, so I took a piece of scrap paper, drew a sample tree on it, and worked out a few simple cases. I then told the interviewer that I needed more time, but he said time was almost up. (Recall that we weren't able to start on time due to problems installing the WebEx client.) So, he asked me to explain in words what I would do. I gave the best description I could, under the circumstances.

After that, I asked the usual questions I ask of anyone who interviews me, such as what a typical workday is like, and so forth. He thanked me for my time, and that was it. I haven't heard anything since.

I just sort of chalked this one up to being tired and having to use Google Docs. I think I could have done better if I hadn't been tired. This stuff is difficult enough on its own; it's even more so when dealing with personal problems. But I really hated having to use Google Docs to write the code. IMO, it is one of the worst editors for coding. I know there has been a lot said about how interviewers can't tell how good a software engineer a candidate is if the candidate is using his or her favorite editor or IDE. However, IMO, there has to be a better way than Google Docs, especially if production quality code is requested. Apparently, Codeanywhere provides a service that purports to be the Google Docs for collaborative coding in the cloud. If it is, will candidates be allowed to use it during interviews?

Apr. 26th, 2014

I had a strange dream last night. I was back at MIT, living in MacGregor. However, it overlooked an ocean on its south side, not Memorial Drive and the Charles River. It was very high tide, with threatening waves that seemed to rise to the skies. I went outside to take a look, and the waves were so high that I thought they might reach the shore and drown me, so I went back inside. The tide continued to rise, and started reaching the building. I looked around to see if anyone had noticed, and perhaps thought we should consider leaving the building, but everyone else was just going about their business. Some people were eating. (There were several kiosks available for buying food.) However, the tide continued rising, enough to start flooding the building. But people were just eating, so I went and got something to eat (a half pie of something that looked similar, but not quite like pizza). The dream ended after that.

Possibly, the MIT theme of the dream was triggered by several old IENs and RFCs I've been reading, which were written during the late 1970s and early 1980s. In one of them, IEN 175, a woman named Ginny Strazisar reported that reducing buffer sizes in one of the gateways improved performance. Could that have been one of the first occurrences of bufferbloat using TCP/IP?

I have a phone interview (coding test) scheduled with Cisco next Tuesday for a software engineering position. As always, we'll see how it goes.

f5 phone interview

I had a phone interview with f5 Networks a couple of weeks ago for a Principal Software Engineer position. These are the questions I was asked. (I'll provide more of my answers later if I have time.)

"Describe the TCP handshake when a connection is first opened."

"What is an ack?"

"How is data passed to TCP from a user process?"

"Design a TCP connection table. How big should the connection table be?"

"Design a (simple) hash function that maps connections into the connection table."

I have not done anything like this in a long time, so it took me a couple of minutes of writing some diagrams on a piece of paper before I responded with XORing the source and destination addresses and ports 32 bits at a time.

"What data structure would you use for TCP throughput?"

I wasn't sure what he meant, so I asked if he wanted something to collect statistics (e.g. total packets or bytes per connection).

"What does an HTTP request look like?"

"What are some HTTP headers?"

"What are HTTP cookies used for"

I said to maintain state and for tracking.

"Are there any other headers that can be used to track state?"

I thought about it for about a minute, then said I couldn't think of any. I had forgotten that authentication headers can track state.

"What were you doing during the time you weren't working?"

I was asked back for an onsite interview about a week later. Since the interview was conducted under an NDA, I can't write about it, but unfortunately, I didn't get the job. There were a couple of things about the interview I wasn't happy about. One was that they gave me mechanical pencils for a written C programming test whose thin points kept breaking. I wish they'd given me wooden pencils instead. The other was that the last person to interview me just left me in the interview room by myself instead of walking me out to the door. I felt a little uneasy walking around the office unescorted, but no one from the interview team or HR was nearby.


"Man I won, but I didn't beat him!"

These were the words of Apollo Creed (Carl Weathers) in Rocky II, when his trainer tried to convince him not to fight Rocky Balboa again, because of the terrible beating Rocky gave him in their first fight.

Might some Swing competitors say this after seeing their final placements? Let's see …

Most Swing competitions use a system called Relative Placement (RP) to determine the final placements of contestants. You can follow the link for a more in-depth explanation, but briefly, judges rank the contestants in order, then the RP algorithm produces the final placements based on determining the largest majority of the highest placements.

So, let's take a sample from a hypothetical contest (which is also in the RP document linked to above):


Four judges placed Couple A 2nd, and three placed Couple B first. Under the RP algorithm, Couple A would beat Couple B, because a majority of twos beats both a minority of ones and a majority of threes. (With seven judges, four is a majority.)

But did Couple A really beat Couple B? Maybe not …

Looking a bit more closely at each judge's placements, we see that six judges actually placed Couple B higher than Couple A. In other words, the vast majority of judges thought Couple B danced better than Couple A in this contest!

This type of pairwise comparison between couples was a topic of debate recently among WCS dancers. As it turns out, the question of whether a pairwise comparison of couples' judges' placements is a stronger measure of victory than RP is relevant. Such questions were asked (and answered) by the Marquis de Condorcet, among others, in the development of social choice theory. I would not be surprised if this issue comes up again, especially if it would make the difference in one of the major Swing competitions, such as the US Open, which just concluded recently.


Nov. 9th, 2013

I decided not to enter into any more WSDC J&J (Jack & Jill) competitions. (I will still do All-American J&J's where they're offered.) I'm glad I made that decision. I've been to two dance events since then, and just watched the competitions when I was able. Not competing allowed me to take in everything that was happening, and focus in on some issues that turn out to be on many people's minds. I've written a number of things about this on FB, and time permitting, I'll write about them here as well.