classic cylon

Ciena interview

I had an onsite interview at Ciena a couple of weeks ago for a Senior Systems Test position.  Long story short — I didn't get the job.  I think they were looking for a person with more experience automating the user experience of routers, whereas most of my experience was automating router operations.

Anyway, one good thing came of this.  As I was going through my interview "debriefing" — making notes about what I was asked, how I answered it, and things I could have done better, I found a mistake in the BGP-4 RFC.  I submitted an errata report for it, which will hopefully be helpful to people who use it.

classic cylon

ProtonMail test

I took a test from 7-9am this morning from ProtonMail, a secure email provider based in Geneva, Switzerland, that has an office in SF.  The test was sent to me by email, and I had two hours to complete it.  ProtonMail required me to take the test during their business hours, so I either had to be up at dawn to take it or stay up really late.  Either way, I knew I would be tired, so I decided the best thing to do would be to take the test first thing in the morning.

The test had several logic puzzles and some other questions.  I have not focused on those types of questions lately, because tech companies are more likely to ask algorithms and systems related questions.  Even if I had prepared more for those types of questions, I still might have struggled with them, because I don't do well on those types of questions after just waking up.  So basically, it's the same old story -- I wish I had done better.

classic cylon

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

classic cylon

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.

classic cylon

(no subject)

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.
classic cylon

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.
classic cylon

(no subject)

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 ...
classic cylon

A mistake, or a sly way of filtering candidates?

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.
classic cylon

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.

"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.
classic cylon

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.