Hiring Advice

I think that's the problem. It's very expensive to work in SF.

If you work for a big company, the code _is_ proprietary. And engineers aren't always good at figuring out that just a snippet isn't going to tell anyone anything. I've been involved in hiring some very satisfactory software engineers, and demanding code samples wasn't part of the process. Besides -- code samples are going to come from two groups: folks who have jobs currently, and folks who habitually take code home with them. The former group is smaller than you might like, and do you really want a code-hoarder to be draining code from you?

Maybe you should get the code sample at the interview. The most effective interviewing technique that I saw used (and I'll use it again) took about 45 minutes to wring about a dozen lines of code from the applicant (and lots of sweat). It gave us a good idea of coding style, and specifically tested for the ability to do the math to check for overflow.

There's certainly people who meet all these qualifications in the Portland area, but they're not fresh-faced college kids. I'd take a look at the current "embedded systems" curriculum -- I'm not sure that they teach assembly language programming at all anymore. Certainly what you're asking for would either come from a college kid who (like me) had been doing hobbyist work since grade school, or someone who's had a few years of experience.

--
http://www.wescottdesign.com

Yes. That's the way it is.

I advertized the position in the local univercity and I put a master's degree and/or practical or amateur experience in the relevant field into the job requirements. That brought much less chaff and attracted few good people.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

I think C is considered to be obsolescent by many. Especially academics (who've never really worked, anyways!) Assembly language even moreso (I cut my teeth on 4004/8080 asm and go to great pains to eliminate it -- any ASM -- everywhere possible in my designs as it poses a significant barrier to maintenance for other folks)

See above. There are lots of "programmers" and few "engineers".

This, I think, is a problem with too many canned "modules" that do all the work for you. E.g., "give me a random number between

237 and 985". [I "stumped" the person in millworks at Home Depot by asking to have a sheet of plywood ripped into 10" strips. He pulled out his tape rule and asked me "How do I measure 10 inches?" (I have *witnesses* to this!!!) Be afraid. Be VERY, VERY afraid!!]

I think you will find "self-starters" to be few and far between. Consider how many folks can develop a cohesive argument. Or, can present some topic in a structured manner so that their audience is given the information they need to understand the *next* bit of information to which they will be introduced, etc.

Change this requirement: Please submit your implementation of the following algorithm in the language of your choice. Comment on your choice of language, the aspects of the language that make it well suited to this sort of problem, and the characteristics that might make this inappropriate for a real-world solution.

This reveals a lot about how they approach a problem. Do they "just barely" comply with your requirement? Do they understand their own implementation? Are they practical (e.g., anyone submitting a SNOBOL implementation is probably not worth talking to; OTOH, someone submitting a CLEVER one in APL *might* be!)?

See above. If they aren't "clever" (deceitful???) enough to fabricate a "code sample" on the spot to satisfy your request, then how will they fare in a "spot test" in a face-to-face interview (where they are under time pressure and have no other resources to draw on besides what is within their heads)

I suspect what you are experiencing is actually a perverse consequence of the bad jobs market. Folks sending out *lots* of resumees and receiving very few *real* returns. So, why invest much time in any *one* application when, chances are, it's going to be a dead-end as well?

See my rant, elsewhere...

One would like to *think* that would be the case. And, from an intellectual standpoint, one would *hope* that was the case (distressing to think we're graduating "dummies").

But, ask yourself what would *draw* them to your company (besides a paycheck). I've turned down many job opportunities simply because I didn't like the work that was being offered (my time has a significant non-monetary component to it).

Think of the type of personality it takes to be able to stare at a piece of FR4 with little black blobs stuck to it and "rainbow wire" trailing off in 6 different directions KNOWING that it is their responsibility to make it *do* something. Contrast that with the personality type of someone who wants to animate a bunny rabbit hopping across a screen, etc.

[that was a serious question]

Assuming *you* are happy with your position, there, ask yourself *why* you want to come to work each morning? How did you end up where you are? What caused you to move in the direction that you did? What are the parts of the job that you "tolerate" in order to be able to do the parts that you *enjoy*?

Ask your peers the same sorts of questions.

Then, look at the process and path you each took to get there. Head-hunters? Recommendations of friends? School job-fair? etc.

Are the types of products you develop/work-on suitable for taking "on the road"? Could you drag one to a job fair and see how potential applicants interact with it? I.e., what you are looking for is the guy/gal who wants to take the top off to see what's inside. *Then* starts poking around at things to see what's *really* going on under the hood.

I don't think you "just" want to satisfy those basic criteria -- and later discover the individual isn't really interested in the work and leaves once the economy picks up. Rather, I suspect you would want to find someone who will actually add value and have real ideas to offer to grow your business and improve your product offerings.

Good luck!

I'm not surprised.

Only simple to write down, I'm afraid.

[...]

Not necessarily.

You have to be patient, getting a good employee is not simple, and embedded design is somewhat special.

[...]

If San Francisco is too far away, I can offer Munich. Also a hardware designer (analog / discrete) is wanted.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)

I am reminded of the article about "Java considered harmful"

Perhaps a C centric Forum has a jobs thread? That could be a good place to post.

Even if we code only very small pieces in ASM and some even in C++ (Embedded PC), I still need to know ASM or at least know how to read it. If I encounter a problem at a deeper level I sometimes have to look at what the Compiler does to figure out what went wrong. And that below the C level.

RK

Knowing how to read it, and know how to code it efficiently are two entirely different skills.

If the employer wants the first he should be asking for it and not waste his time looking for one of the 0.01% of engineers who can do the latter

tim

I'm not saying it isn't a desirable skill to *have* -- as is the ability to *swim* even if one doesn't live near the shore. Rather, my point is that these skills are vanishing and, if your goal is to find someone who can fill an embedded position, it is one of those that I would consider removing from the list of qualifications to broaden your applicant pool.

I find having *hardware* folks who can understand ASM is usually more profitable as they can use that skill to bring up new hardware whereas too much of what a compiler does obscures what is actually happening *in* the hardware ("Aw, crap! I spent a day wondering why my ASIC wasn't working only to discover the compiler optimized away the accesses my code was making to it because I forgot the volatile keyword...")

If something that is *known* to be "bug free" exhibits a bug, the last thing I do is go digging through the .S listings. With optimization on, it's more work for me trying to figure out what *magic* the compiler applied to my code than it is worth! First step is to triple check my work to convince myself that there really *are* no bugs in my code, as written. Then, have someone else look at it to see The Obvious that I may have missed. Next, turn off optimizations and turn on debug -- adding DEBUG() statements as necessary and checking the black box's contents. Finally, start stubbing to access more elusive information.

For me, It's just not worth digging that far down (to the metal) as most problems can be resolved before that point. And, if I haven't made a decision on where the code will be

*deployed*, why bother critiquing the compiler before I absolutely have to?

If I'm convinced the tool is broke, buy a new tool.

Rob,

I agree with the poster who said "A lot of programmers, very few engineers". (I disagree with the comments on 'C' - almost everything is in C/C++, and most of the C++ instantly escapes to 'C')

I am that code-slinger you're looking for. I cut my teeth on 8008's and 8048's, and have been programming in C/ASM for a living ever since. I got the feeling from your post that you were looking for 20- year experience skills at 5-year experience pay. Remember, SF is the

2nd most expensive housing market in the USA - I lived within walking distance before you moved from Judah. (And I know what you-all are paying in employer tax.)

In other words, SF is not the 1st place to look for a firmware engineer. All the fresh-faced graduates you talk of would be driving past 20 or 30 possible employers on the way to an interview with you - and at $4.00+ a gallon, closer is better.

Another thing: I'm guessing that you advertised on "CL". I used to look for jobs there, until 10 clients in a row declined to pay the final invoice. I now peruse his list to discover places to NOT work.

Best of Luck with that, RK

y.

It goes deeper than that:

Without knowledge of ASM, the engineer has no clue how to make the C code efficient. The parallel is the VHDL coder that has no concept of the generated logic.

In one embedded x86 design, the C compiler I used had no knowledge of "loop" or "rep". Recoding one 20-line C function to use those resulted in an interrupt service routine that took 1mS instead of 20.

RK (the other)

This exactly. It's not that you need to be able to sit down and bang out a shiny new OS in assembly, every line perfectly hand tuned. It's that you need to be able to work with ASM startup code, where readability matters a whole lot more than clever tuning, and that you need to be able to understand what the compiler's doing and whether it should be.

As an example, when I started working with Cortex-M3 parts I did a bit of playing with the GCC compiler to see what I get under various circumstances. It turns out that if you've got a bunch of global variables that you want to work with, the generated code will first fetch the address from the constant pool and then fetch the data from that address, for each global. If, instead, you stuff all your globals into a struct, then the compiled code only fetches the base address from the constant pool once, then uses the free constant offset to get to the individual parts. Moral of the story, better to wrap your globals in a struct on this architecture/compiler pair.

That's not something I learned in a classroom or found in a book. That's something I found from 5 minutes of saying "What can I learn by poking through this disassembly a bit?" And so the idea that you can get away without any ability to work at the assembly level is worrisome, and that the schools seem to be teaching it now as a given even more so. I only got my EE degree in '03, and even that recently we had a mandatory month or so of MIPS assembly. Not enough to do any serious work, but just enough to remind you that the machine's got guts, and what happens down there matters.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

Your first RISC processor (or at least first ARM)?

The same applies to other ARMs and many other RISC processors, as the instructions need a base register to access static data.

--

Tauno Voipio
tauno voipio (at) iki fi

tly.

f

That's the whole idea of passing pointer to struct. It is a fundamental feature of C, notwithstanding the compiled codes.

Unfortunately, you did not have good teachers. Our teachers guided us well very early on.

Yes, at least you learned what the education system failed you.

OTOH, if the problem is isolated to a small enough section of the code then a quick look at the assembly code can act as a sanity check.

Sometimes, "known" to be bug free just means that we assume it can't possibly have a bug in it because it comes from a trusted source or is otherwise widely used.

Case in point: I've just replaced the remap code in my ARM7 startup code with a Atmel supplied subroutine because the Atmel code handles a wider range of situations than I did. I noticed the lack of volatile attributes in the code where I would have expected them, but I just assumed that the programmer knew something that I didn't and I just used it as is.

The code didn't work, but I just assumed initially that _I_ must be the one making the mistake until I looked at the code generated by gcc and realised that the recent version of gcc I was using had made invalid assumptions due to the aliasing of the address space.

If I had not given the generated code a quick examination I would wasted more time on this than I did. BTW, modifying the code to use volatile attributes on the variables (as it should have had in the first place) made it work as expected.

I also do think that a understanding of at least been able to read assembly code is a required part of been able to do embedded work, because when things really go wrong, it becomes a part of trying to understand the problem.

It's also more than this because if you don't understand the architecture at assembly level, then you are unlikely to have a good feel for any other architecture specific issues which may crop up.

The higher level languages like C are just a abstracted model of what is actually going on, and sometimes, when that model breaks, you need to dig deeper than the model to understand why.

Sometimes the tool works fine, but it's the code that "cannot possibly be wrong" that's the problem. In my case, I should have gone with my instincts instead of just assuming that the professional embedded people knew more than I did.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

It's more a consequence of the fact that the ARM CPUs can't use absolute addresses directly in the instruction operand, and that they also don't have a 32-bit load immediate to load said address easily into a register.

Once you have a pointer in a register, the ARM can quickly access anything within a 12-bit offset.

These limitations/properties are very specific to the ARM architecture, when you compile the same code on x86, the results are completely different, as it can directly access absolute addresses.

This is not usually taught in a classroom.

als

om

he

n a

Indirect addressing is not unique to ARM. PDP-11 (when C was first implemented) has offset indirect and register indirect. ARM takes full advantage of it, but certainly not the only one.

This is an exception, not the rule. In fact, most C data references are stack frame relative.

Depends on whose classroom.

Indirect address is quite common. But the lack of absolute addressing is typically RISCy. At least the PDP-11 had absolute addressing, as well as immediate loads of address values.

Except for all the static/globals variables, which are still quite common in typical programs. It also has nothing to do with 'passing a pointer to a struct'.

For your typical ARM compiler, the following (using static/global vars)

int a; int b;

a = b;

Is much less efficient than this:

struct { int a; int b; } x;

x.a = x.b;

No structs or pointers are passed.

On an x86, there's no difference between the two.