Interview redux

Well after having ran out of time for a proper interview last time, the company managed to sort out transportation for me to get back down to Hamilton for that interview.  I had to wake up at 6 o'clock again to make a 7:40 am InterCity bus from the Sky Tower.  The toilets were third world standard.  Poo land.  There were 7 others on the trip down and took around 2 hours.  I was being a complete tourist and taking random pictures every so often.  When the bus got to the Hamilton bus stop, the first thing I looked for was an outlet for my memory leak.  The weather made for brisk walking.  The time was close to 10am.  So, come to Alexandra Street, I made my way into the KPMG tower and took the lift up to 9.  The lift stopped at level 7 and surprisingly the firmware manager stepped into the lift.  First thing I thought about was the elevator pitch but all I did was raise an eye brow to send an acknowledge signal and he basically did the same so he sent back a ready signal.  At this point we rendezvoused with a hand shake.  Must have been a random sight for the two others in the lift.  So we reached the 9th floor and I got a quick 10 min break to freshen myself.

So, just the firmware guy in a fume ridden room.  First thing to do was to go through the test.  Got asked what I meant when I had (counter + 1) / 16.  Probably wrong syntax but the division was supposed to act as a modulus so the counter value would be between 0 and 15 all the time.  Probably needed the percentage sign.  Next was that RTL diagram with the useless "and" gate that would always be false.  So got asked how I could optimise the circuit.  Simple, take out the and gate and operands.  Then the multiplexer becomes useless and because the binary counter is clocked, the output register is not needed.  Then assuming that the initial state of the counter is not important, you can remove the "+ 1" logic.  All you're left with would be an up counter.

Next question, to do with metastability.  This is where the self rooting comes into play.  First, if there is a 200M clock and a 50M clock and you wanted to transfer data at irregular periods from the higher clocked domain to the lower clocked domain, what problems will you have?  If you have a block in the middle of the two domains, what signals do you need?  How do they communicate?  Assuming that the downstream (50M clock) component can always accept data, what signals can we remove?  Draw the timing graph of a data transfer from the upstream to downstream component.  How would the middle component be able to match the two clocks so that there is no glitching due to each of the clock edges being too close together?  All I can say is that there were a lot of *silence* and stares at the board.  I think the interviewer was very good at hiding the fact that I was pissing him off with my stupidity.  Not enough focus.  So, that was probably the worse than the radio interview I had in year 2 where the lecturer kept saying I was wrong.

So, next question.  I think I had an advantage because I was told the same question after the first interview.  The objective is to make a mono-stable component.  The component accepts one pulse and outputs a long pulse.  The pulses are synchronous.  Since I knew a loop would be a fail, I used a variable to keep track of the down counting from 100,000.  The next question was, what would be synthesised?  Pretty much just a down counter with its 17 bit long output simplified down to a 1 bit number through bitwise "or".  The result of the "or" is the output.  No need to use compare logic.  A few control signals are needed and some use of precedence to get expected behaviour.  Much easier question.

The next thing on the list was just general questions.  What was the hardest thing you have come across?  What final year project are you working on?  Where did you learn VHDL from and what projects did you make?  The interviewer was writing quite a lot from the rather short answers that I was giving him.  I'm not very descriptive by nature when it comes to useful information.  Or maybe I'm able to "get to the point" super efficiently?

The interview concluded after about one and a half hours.  Not as long as the others.  Tough though.  There were also some Waikato University students there.  There were wearing similar outfits to one another.  I don't think they are a competition for us because they looked quite young.  Chances are they are only interested in a summer job.  One of the guys started a chat with me.  Started with the obvious question: Are you here for an interview?  Anyway, they didn't learn much about VHDL but they have used micros quite a bit.  They also learnt C# but nothing much apart from C for programming their micros.  They took the absurdly hard algorithm, C and Linux tests as well.

So anyway, the HR person escorted me to the QuickCat shuttle and luckily we got there in time because the driver was already outside waiting and had already phoned saying that I was not there.  There was one other passenger inside and they were going to the airport.  Sounded like they came from Ireland.  Got back to Uni at about 3 pm and started panicking for the 704 presentation.  But first, had to go to the Marae for 403.

Interview

Just spent the whole day down in Hamilton for a job interview. Six others, all from the University of Auckland, travelled down. Took around one and a half hours each way. I wouldn't have been a pleasant journey if you didn't make sure your bladder was empty. If not, you'd be squirming to flush our your memory leak. Core dumps can be archived.

The first test was an IQ test which constisted mainly of words and number associations. Then there were different tests for people who were going for different positions: VHDL and software. For VHDL, the test was not timed. The software test, which I was originally given, came in three parts: Algorithms, Linux proficiency, and C code.

The algorithm part was not do-able at all.  I didn't understand the significance of the big O notation, space, and amortise of the functions we had to write:

• For a singly linked list a with an unknown number of elements n, write a function called get_n that takes in the list and a number k that returns the (n - k)th element from the list.
• For a singly linked list a, write a function called check_linked that checks for cycles in the linked list and returns true if there are or false if not.
• For an array a with a known number of elements n, write a function that rotates the list at element k.
• Something about having a list of page tables that can be written to by Applications and asking how we could make sure they weren't being used by other Applications requesting the pages being written to in an efficient way.
• A question that was too long for me to remember.  Something about managing a list of resources and figuring out the resource intensive ones.  They noted that going through the whole list would be too inefficient so they proposed a relaxed algorithm which had something to do with n bins and sets.
• A router can delay the transmission of packets.  There will be 24*60*60 = 86,400 different values for time.  Find a way to reduce the number of values below 1000.

The Linux proficiency test was hard as well.  It was a collection of short questions mainly about what commands should be used to get certain information and some administration questions.

The C test was a bit better but my brain wasn't holding up well enough.  Some of the questions were:

• What is wrong with this: x = x++;  ?
• Find the bug in the internet checksum code.  (Casting of addr inconsistently)
• In this source code, why is the assert always failing?  (Passing of a pointer and allocating memory to it and asserting that the pointer is no longer a null reference)
• Explain why the outputs are like this?  (int a[10] created and print outs of its size and each of its elements are made)
• What is another way to do the same: node_t->size ?
• What other ways are there to do a[2] without using the ++, += and comma operators?
• Write a recursive function that performs the factorial calculation.
• Complete the function for inserting an element into a linked list.

Well after those three tests, we were given a small tour of the office space by the Appliance person.  They seemed really bubbly and joyful but we were too brain dead to laugh with him.  We were pretty quiet.  So after killing a bit of time through more talking and asking of random questions, lunch was finally ready.  The company has a free lunch on Fridays so we got to join in.  The way they laid out the food, it was more like a "make your own sandwich" sort of thing. We were also made to sit amongst the other workers so we could another feel for the company. Alienating ourselves by us all sitting at the same table would have looked awkward.  The table I was at, there was an American guy who worked for AoL and some other small companies and he did some security work for the predecessor to CIA.  We ended up talking about different types of briberies and using buffer overflows for hacking.

So after lunch had finished, we got started with the interviewing process.  I was picked to go first and funny enough I didn't get too nervous.  Got asked a few questions about what specific part of a project I enjoyed at University and what paper I found most useful.  They went over the C test with me which I got 6/10 and I think they were pleased with it; especially the x = x++ question, thought they were debating as to whether my answer was "the" correct answer.  Then I got asked about the different types of storage class specifiers for variables; auto, extern, void, static, and register.  Somehow bashed my way through that with the help of "braces" to explain the scope and lifetime of the variables.  Then I got to ask my questions and the important one was:  How was it decided that certain candidates would be given the software test or the VHDL test?  The answer was, they considered our CV and the papers we took and decided which areas they felt we'd be best suited.  Additionally they were interviewing people for the Card software side rather than just Appliances so that cleared things up a bit.  But I did stress that I had expected to do the VHDL test rather than the software test since I expressed my interest in that area in the feedback form when the company came to University for an exhibition.  So after that realisation, I got to do the VHDL test and I ended up taking about one and a half hours to do it which wasn't very long considering the others took more than two hours each.

Some of the VHDL questions:

• Given this circuit, express it in VHDL.  How can you increase the clock frequency of this circuit?
• Find 3 syntax and 1 functional error in the following VHDL code.  Why will this VHDL code not be used when implementing on a Xilinx FPGA.
• What are the disadvantages to a logic element with 4 inputs to an LUT with a flip-flop at the output?
• What are the disadvantages of clocked memory resources?
• What is the metastability problem?  How can you make a circuit more tolerant of metastable signals?
• Draw the output for the clock selector circuit.  What is the problem with this circuit?  Fix the problem identified and draw your circuit and expected output.

So after finishing this test, I had nothing to do since the interviews for VHDL were taking a very long time.  I found another guy who had finished his interview so we decided to take a stroll through Hamilton but we didn't get far from the office when it started to rain.  We waited underneath some shelter for a while, hoping that the rain would ease back.  But it didn't so we decided to go back into the office.  That was a bit sad.  We got back into the office and now more people had finished their interviews.  So the usual discussion about what questions were asked and feedback the interviewers gave began.  It didn't seem like anybody had much of an advantage.  Everybody got perplexed by the questions the interviewers asked.  The first guy who got interviewed for VHDL only got out after an hour and half of interviewing; which is a very long time, indeed.  Apparently they were asked to complete more questions on a whiteboard.

I never got the chance to get an interview with the VHDL guys which was a shame because it seemed more of appropriate to have been interviewed by them and I was up for the whiteboard challenge!  Well I was told that even though I didn't get interviewed, the VHDL test that I did should be enough for them to figure out if they wanted to interview me later on.  Hope they do, or hope that I got the Card job.  Either way, having a job in Auckland would be good.  That was pretty much the end of the day.  The cab had arrived so we were off back home!