Question regarding SAS controllers

[prady]

Hello All,

I am trying to get a job with a manufacturer of storage devices. A part of the requirements says "understanding of embedded systems". I have cleared the phone inteview and they told me they are using an ARM core to communicate with host processor. I am a new college graduate with no experience with device drivers and since the in person interview is not happening till Jan, I was hoping to develop some understanding of SAS controllers.

Any ideas regarding the best place to start? I was reading the device driver programming book for linux and I am guessing the type of drivers are "block drivers". If you were hiring, what would you expect from a new college graduate with EE degree?

Thanks in advance!

Happy holidays!!

 

[Stereodude]

Personally, I think you're headed somewhat down the wrong path. They're not really going to expect a recent college EE grad to have SAS or SATA experience. I'm not sure trying to learn it now is going to do you much good since your knowledge won't be very deep. They're more likely going to want someone to have some experience with embedded systems (hence the requirement).

Have you ever worked with a microcontroller (MCU) in an embedded system? You must have had some project in college where you had to write code for a MCU and get it to interact with other devices right?

 

[prady]

Hello StereoDude, Thanks a lot for replying.

I agree with your suggestion that I am probably headed the wrong way. I guess, what I am trying to find out is what are the fundamental things that I can brush up on to excel in the interview.

I have worked on little projects like "flashing the LED", "Displaying messages on the LEDs".. (PIC, PowerPC) In the Operating Systems course, I have developed an understanding of processes, threads, resource management, premptive multitasking etc. for x86 architecture. My only worry is that someone will ask me "Do you have any experience with 'device driver' programming or the type of code where C interacts with low level hardware" and I would be sitting without an answer.

 

[Stereodude]

A SATA or SAS controller is just the application / software running on the microcontroller on the storage device. Knowledge of the specific application is less important for a fresh out of school EE than an working understanding of how a microcontroller works and operates inside any real time embedded system. I'd guess that a lot of the people working there aren't experts on SATA or SAS because most of the people aren't working directly with the SATA or SAS protocol.

My senior design project in college 10 years ago had me working with a Mitsubishi M16C Microcontroller. I had to write a "device driver" to scan an external keypad, a "device driver" to send a 40x4 array of characters to a 40x4 character LCD, a "device driver" to interface to an GPS module via a serial protocol, etc. As you can guess, my experience wouldn't be directly applicable to most embedded applications but it would show an interviewer a knowledge and understanding of programming on a microcontroller in an embedded application which is all they can really expect from someone straight out of college.

Ultimately, the key is to try tailor your explanation of what you did in college toward what they are looking for. So if an interviewer asks you "did you ever work with an ARM microcontroller?" You don't just say, "No." You say, "I didn't work with an ARM Microcontroller, but I did work with a PIC microcontroller..."

Is the storage company looking for a software engineer, or a hardware engineer?

 

[prady]

That makes a lot of sense and helps A LOT!

This is a system engineer position requiring good background in analog mixed signal design & characterization and good understanding of digital design, digital communications, digital signal processing and embedded systems.

I think, the problem is the job requirements are usually quite vague and it's difficult to tell what are the critical requirements even after talking with hiring manager. I was given the answer that "characterization experience and programming experience are critical but most critical is being able to communicate effectively with other design engineers, test engineers and FAEs".

I have strong background in digital communications, signal processing, high speed CMOS analog mixed signal designing (couple of internships). So, when I started reading about SERDES architecture all the building blocks and characterization methods make a lot of sense but I just can't seem to find much information about the controller on SAS cards. Hence the nervousness.

Your suggestions actually make immense amounts of sense. Thanks a lot for your time and effort.

 

[Stereodude]

A System Engineer?!?!?

RUN AWAY NOW!!! :rotfl:

Seriously though I'd pay very close attention to how they describe the position and what the job entails. Based on my work experience a typical "system engineer" doesn't do much real engineering. They usually deal with documentation (writing, reviewing, etc.) or management type tasks (maintaining the schedule, keeping track of milestones, etc.).

Systems Engineering

 

[prady]

I was told that I would be working closely with cross disciplinary design engineers, customer, FAEs, and design architects. I eventually want to move towards project management. I will take this experience!~

 

[Stereodude]

Whatever floats your boat... I personally hate project management.

 

[LunarMist]

Is that an entry level job or not? "Understanding of" has a broad range of meanings. I don't hire anyone with less than 5 years of experience anymore (preferably 10-15), but an established company should have a process for entry level employees and some sort of training program.

 

[Howell]

Ultimately, the key is to try tailor your explanation of what you did in college toward what they are looking for. So if an interviewer asks you "did you ever work with an ARM microcontroller?" You don't just say, "No." You say, "I didn't work with an ARM Microcontroller, but I did work with a PIC microcontroller..."

Prady, something you might be able to learn in the mean time is the technical differences/limitations between what you have worked with and what they want you to have worked with.

 

[Stereodude]

Prady, something you might be able to learn in the mean time is the technical differences/limitations between what you have worked with and what they want you to have worked with.

This is very good advice. You want to know the difference between what you know and what you don't know. You don't want to equate things or experience that aren't even close to equivalent or similar.