Log in

No account? Create an account

IBM interview

I had an interview loop yesterday at the IBM Silicon Valley Lab facility with several people from the Cloud Network Services group.  Four engineers plus the engineering manager interviewed me.  I thought my overall performance was so-so -- I could have done worse, but could have done better.  Some of the programming questions I was asked were similar or the same to questions asked some time ago on HackerRank, but I was a little slower at the interview, so I either wasn't able to complete them or made small mistakes.  There were also questions I was asked about past projects that I didn't remember very well.  The air conditioning in the building made me feel very cold, enough to put my jacket on, and impeded my ability to answer questions.  I also started feeling tired after about an hour and a half of the loop.  Perhaps the height of the loop was explaining to one of the team members how Relative Placement works.

Unfortunately, I was turned down.  I am disappointed, but not discouraged.  Hopefully, I will do better on my next interview loop (well enough to get some kind of offer).  Perhaps if I have some time, I will make some general remarks about my experiences with tech interviews over the last couple of years.  (If you read my posts on FB or Quora, you probably have an idea of what I'm going to write.)

Netsia interview

I had an interview with Netsia last Friday afternoon for a Senior Network Operations Engineer position.  I wasn't offered the position, but I don't feel discouraged.  One of the people interviewing me felt that I would be a good candidate for contract software development work, and that they would consider me if they have any.  I felt pretty good overall about the interview, because I felt like I represented myself.

I just wanted to briefy mention that I have had a few phone interviews over the past few months that I've felt better about, even though I didn't make it to the next round in any of them.  I have changed my interviewing strategy somewhat.  I am maintaining my focus on IETF working group activities and some other things (such as ranking methods).  So when I do have an interview coming up, I don't just drop everything else to prepare for the interview, although I do attend to specifics the interview might require, such as writing code in a Google Docs document.  When writing code during an interview, I make sure to ask questions, such as if pseudocode is allowed, if I may refer to documentation (e.g. man pages), etc.  If a particular language is required, I check myself as I write for matching braces, etc.  Also, after asking questions, I ask to gather my thoughts for a minute.  If I cannot think of a more efficient algorithm or method, I write the more straightforward code I can think of that would (hopefully) suffice.

In general, I have felt more in control of these interviews than others I've had (and written about here) in the past.  Hopefully, that is a sign of better things to come.

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?
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.