If I'm interviewing someone (I only do the engineering specific part of 
the interview, not the psychological part), I don't typically ask about 
how long it took them to do a project, I want to know what the projects 
were that they've done.  Experience really comes from finishing 
something and working out all the details necessary to call it done - 
it's not just a collection of specific abilities.  To that end, I'd 
suggest that in addition to some evidence of experience on a resume' 
what you need to have under your belt is several working projects 
(preferably ones that have gone into some kind of production) that you 
could talk about (favorite interviewer question is what was your biggest 
problem and how did you solve it?) or organize into a portfolio.  Even 
better is to have someone in the industry recommend you based on a 
project that you did (your positive opinion of yourself is good - a 
disinterested third parties' positive opinion of you is golden).  
Personally, I think the blood pressure monitor project is something you 
should highlight because it shows a genuine desire to work - not just to 
get occupy a cubicle and collect a paycheck.  You've got to love this 
stuff to struggle through the tough parts and do it right - convey that, 
and you'll get offers.

Good Luck,

Tony


Jason Hsu wrote:
> I am currently seeking a position as an embedded engineer.  A job
> location in the Twin Cities region is greatly preferred.  (One
> advantage is that it's nearby.  Another advantage is that I can
> continue participating in Project Phoenix, an IEEE study group working
> on an open source blood pressure monitor.)
>
> I'd like to hear your suggestions on what else I need to learn in
> embedded engineering in order to be a truly outstanding embedded
> engineer.  Engineering job ads (any discipline/specialty) always
> equate proficiency with "years of experience".  As you know, the
> relationship is clearly not 1:1, and I know better than to assume that
> having 3, 5, 7, or 10+ years of embedded engineering work experience
> will automatically make me proficient enough to do embedded
> engineering blindfolded.  I want to be the person with 3 years of
> experience who is just as proficient as others with 5 years of
> experience, not the other way around.
>
> So far, I have picked up on embedded engineering on my own, with the
> aid of excellent microcontroller communities like this one.  I thank
> everyone who helped me through the various obstacles I ran into, and I
> can't imagine how anyone got up to speed on embedded engineering
> before there were great online communities like this one.
>
> I understand that I have just barely scratched the surface of the
> embedded engineering world.  I know I need to learn more, as this will
> make me more productive on the job and give me more material to talk
> about in elevator speeches, cover letters, resumes, and job
> interviews.
>
> Some highlights of what I've done so far are:
> 1.  All of the basic stuff in the introductory exercises (simulating,
> A/D converters, I/O pins, the open drain I/O pin, disabling LVP so
> that the normal I/O function works for that pin) with the PICSTART
> Plus programmer, PLUS the things needed for my SWR/wattmeter project
> 2.  Both Assembly language (through MPLAB) and C (through PICC in MPLAB)
> 3.  Using MPLAB in Windows XP and in antiX Linux through WINE
> 4.  PIC16F84, PIC16F72, and PIC16F872
> 5.  Unsuccessfully trying to use open source software to program
> microcontrollers in Linux: I consider the open source software route
> (GPSIM, Piklab, etc.) to be in a pre-alpha stage.  I ended up running
> MPLAB through WINE.  This setup works in antiX Linux but not in Puppy
> Linux.  (I did notice that antiX Linux has a newer version of WINE in
> its repository.)
>
> What other embedded engineering skills do I need to learn?  Until I'm
> in a situation where something else has already been chosen or a PIC
> is not viable, I intend to stick with PIC simply because that's all I
> know.  (From what I've heard, someone who knows PIC shouldn't take
> that long to get up to speed on AVR, Atmel, etc.)  Some things I'm
> aware that I haven't done yet are:
> 1.  ICSP: So far, I have only used the PICSTART Plus, which requires
> moving the microcontroller back and forth.  I know that this isn't an
> option for surface mount microcontrollers, and an ICSP setup that
> allows a connection directly to the target circuit is necessary.
> 2.  I2C, SPI, UART, etc.: Most of the ads for embedded engineering
> positions mention these standards.
>
> What else should I learn?
>
>   
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist