Post by thread:[EE] Test for embedded developer candidate

Four years of going through resumes and conducting interviews convinced me that tests are the best and the most objective way to judge a candidate's qualifications. Here's an example that tests basic electronics knowlege: http://scantool.net/pub/electronics_test.pdf This particular one was put together back in 2004, right now I'm working on updating it to make it more relevant to what we do (feedback is welcome). I'm thinking about putting together a couple more tests, to test math and software development skills. While math test is easy to write, I'm having difficulty coming up with specific problems to evaluate programming skills. Joel Spolsky has this to say on the subject: http://www.joelonsoftware.com/articles/fog0000000073.html Specifically, he suggests the following exercises: 1. Reverse a string in place 2. Reverse a linked list 3. Count all the bits that are on in a byte 4. Binary search 5. Find the longest run in a string 6. atoi 7. itoa (great, because they have to use a stack or strrev) The exercises are followed up by a design problem (design a house or a trash can or ...) What do you think of those? In your opinion, what skills are essential for embedded developers? What sets them apart from desktop app programmers? Best regards, Vitaliy

On 10/19/07, Vitaliy <spam_OUTspamTakeThisOuTmaksimov.org> wrote: > Four years of going through resumes and conducting interviews convinced me > that tests are the best and the most objective way to judge a candidate's > qualifications. Here's an example that tests basic electronics knowlege: > > http://scantool.net/pub/electronics_test.pdf Too easy? {Quote hidden}> This particular one was put together back in 2004, right now I'm working on > updating it to make it more relevant to what we do (feedback is welcome). > > I'm thinking about putting together a couple more tests, to test math and > software development skills. While math test is easy to write, I'm having > difficulty coming up with specific problems to evaluate programming skills. > > Joel Spolsky has this to say on the subject: > > http://www.joelonsoftware.com/articles/fog0000000073.html > > Specifically, he suggests the following exercises: > > 1. Reverse a string in place > 2. Reverse a linked list > 3. Count all the bits that are on in a byte > 4. Binary search > 5. Find the longest run in a string > 6. atoi > 7. itoa (great, because they have to use a stack or strrev) Nice. I failed to pass so this is a good test. ;-) > The exercises are followed up by a design problem (design > a house or a trash can or ...) > > What do you think of those? In your opinion, what skills are > essential for embedded developers? What sets them apart from > desktop app programmers? > This will depend on your product. I can write some simple firmware (three in production now, a Namur sensor interface card, a conduct level probe and a photoelectic sensor, two in HiTech PICC and one in MPASM) but I won't be able to write a more complicated (say for one using embedded Linux). Xiaofan

On Oct 18, 2007, at 10:04 PM, Vitaliy wrote: > Here's an example that tests basic electronics knowlege: > > http://scantool.net/pub/electronics_test.pdf Interesting. I find the last question ("Draw schematic for a one-stage AC amplifier with good temperature stability") out-of-place WRT the rest of the test; perhaps I've just been doing too much software and digital electronics (Hmm. There weren't ANY digital questions on that test, were there?) > 3. Count all the bits that are on in a byte Hmm. Would you expect clarity or clever algorithms? > 7. itoa (great, because they have to use a stack or strrev) Nonsense. Many an itoa-like algorithm has been posted to piclist that uses neither. These aren't bad, but it's easy for me to imagine a microcontroller programmer that has never implemented a linked list, or a windows programmer that has never done their own string processing. BillW

Vitaliy, The test posted is pretty easy but I would be looking more st the way the questions are answered, rather than the answers themselves. For a position as an embedded developer, I'd also suggest some questions involving digital & software items. Preferably include some "tricky" ones where second order effects (transmission line reflections, digital race conditions etc.) are likely to be involved. You probably also may want to ask a question that has no easy immediate answer to see how the candidate approaches problems where all the details are not available and more investigation is required. Of course, if you're scanning a hundred+ applications prior to an interview, then a simple multi-choice may be more appropriate. RP On 19/10/2007, Vitaliy <.....spamKILLspam@spam@maksimov.org> wrote: {Quote hidden}> Four years of going through resumes and conducting interviews convinced me > that tests are the best and the most objective way to judge a candidate's > qualifications. Here's an example that tests basic electronics knowlege: > > http://scantool.net/pub/electronics_test.pdf > > This particular one was put together back in 2004, right now I'm working on > updating it to make it more relevant to what we do (feedback is welcome). > > I'm thinking about putting together a couple more tests, to test math and > software development skills. While math test is easy to write, I'm having > difficulty coming up with specific problems to evaluate programming skills. > > Joel Spolsky has this to say on the subject: > > http://www.joelonsoftware.com/articles/fog0000000073.html > > Specifically, he suggests the following exercises: > > 1. Reverse a string in place > 2. Reverse a linked list > 3. Count all the bits that are on in a byte > 4. Binary search > 5. Find the longest run in a string > 6. atoi > 7. itoa (great, because they have to use a stack or strrev) > > The exercises are followed up by a design problem (design a house or a trash > can or ...) > > What do you think of those? In your opinion, what skills are essential for > embedded developers? What sets them apart from desktop app programmers? > > Best regards, > > Vitaliy > > -

> > Here's an example that tests basic electronics knowlege: > > > > http://scantool.net/pub/electronics_test.pdf some more comments from a nitpicker... diodes: I don't know an anode from a cathode, I don't want to know and I don't need to know. I do know the band on the component is the bar in the symbol, that's all I need. AC amplifier: no aplification factor is mentioned, so I'd offer either a single capacitor between in put and output (factor ~1) or between output and ground (factor ~0). Now that I think about it, no frequency range is mentioned either, so I would specify 0 pF capacitors. but I still think such a test can be a good starting point for a talk. just don't treat the answers as if it were an exam. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> What do you think of those ? I think if you're going to ask questions involving logic, you could ask the candidates, if they can't show specifically how a problem would be solved (ie they aren't able to write some assembly on the spot), the logical method(s) they might try to do it. As we know with our projects, even given our collective experience, sometimes the answer to a problem ends up not being the one we probably thought it would have been Depends what you're after. Knowledge they have now, or their potential as problem solvers ? > In your opinion, what skills are essential for embedded developers ? Good general knowledge, or at least awarity, of sensors, protocols, power supplies, that sort of thing. I appreciate that some may just be starting their working life and have no hands-on experience, but you may find out who were the geeks at school > What sets them apart from desktop app programmers? I guess those guys don't build their own circuits (mainly)

Vitaliy wrote: > Joel Spolsky has this to say on the subject: > > www.joelonsoftware.com/articles/fog0000000073.html > > Specifically, he suggests the following exercises: > > 1. Reverse a string in place > 2. Reverse a linked list > 3. Count all the bits that are on in a byte > 4. Binary search > 5. Find the longest run in a string > 6. atoi > 7. itoa (great, because they have to use a stack or strrev) These questions are about typical algorithms. Most programming on small embedded systems is very little about algorithms, and much more about real-time problems (race conditions), system-level questions (interrupts, protected access to vars), interaction with timed events, correct use of peripherals (being able to read data sheets) -- things that a typical desktop programmer rarely has to worry about. Gerhard

On 10/19/07, Gerhard Fiedler <listsKILLspamconnectionbrazil.com> wrote: {Quote hidden}> Vitaliy wrote: > > > Joel Spolsky has this to say on the subject: > > > > www.joelonsoftware.com/articles/fog0000000073.html > > > > Specifically, he suggests the following exercises: > > > > 1. Reverse a string in place > > 2. Reverse a linked list > > 3. Count all the bits that are on in a byte > > 4. Binary search > > 5. Find the longest run in a string > > 6. atoi > > 7. itoa (great, because they have to use a stack or strrev) > > These questions are about typical algorithms. Most programming on small > embedded systems is very little about algorithms, and much more about > real-time problems (race conditions), system-level questions (interrupts, > protected access to vars), interaction with timed events, correct use of > peripherals (being able to read data sheets) -- things that a typical > desktop programmer rarely has to worry about. Quite true. Small and large embedded systems seem to be quite different. In our small engineering organization, we have people working on Small PLCs with 32bit MCUs and we have people working on I/O modules with 8051s. The firmwares are very different but both are called embedded software. Xiaofan

Alan B. Pearce wrote: >> Here's an example that tests basic electronics knowlege: >> >>> http://scantool.net/pub/electronics_test.pdf >>> >> Too easy? >> > > Maybe, but is about the sort of level I would expect for getting someone who > is looking to start in electronics. We used to give a similar sort of test > to prospective apprentices to see what hobby electronics they had done > before looking for work. > > But bear in mind that when I got my current employment the sort of questions > I was being verbally asked were of a similar level to this, and I beat off > people with masters degrees ... > > > An MSEE often involves doing something more abstract than transistor amplifiers which I would have studied a a few years before finishing my MS degree. My MSEE thesis is on using encryption algorithms in FPGAs. I learned a lot about encryption and FPGAs. Beating people who have an MS over your BS doesn't really mean anything because they probably did something fairly specific. - MK (MSEE '07)

On 10/19/07, Martin <.....martinKILLspam.....nnytech.net> wrote: {Quote hidden}> Alan B. Pearce wrote: > >> Here's an example that tests basic electronics knowlege: > >> > >>> http://scantool.net/pub/electronics_test.pdf > >>> > >> Too easy? > >> > > > > Maybe, but is about the sort of level I would expect for getting someone who > > is looking to start in electronics. We used to give a similar sort of test > > to prospective apprentices to see what hobby electronics they had done > > before looking for work. > > > > But bear in mind that when I got my current employment the sort of questions > > I was being verbally asked were of a similar level to this, and I beat off > > people with masters degrees ... > > > > > > > An MSEE often involves doing something more abstract than transistor > amplifiers which I would have studied a a few years before finishing my > MS degree. My MSEE thesis is on using encryption algorithms in FPGAs. I > learned a lot about encryption and FPGAs. Beating people who have an MS > over your BS doesn't really mean anything because they probably did > something fairly specific. > - > MK (MSEE '07) I agree with you (I did no analog during my MSEE), but the test is such an easy one, any MSEE should pass it. It is similar to a "fizzbuzz" test for programmers. Necessary, but not sufficient, to choose a qualified candidate. It is sad that anyone applying for an embedded engineering position would fail the test, but better to find out before hiring than after. Regards, Mark markrages@gmail -- Mark Rages, Engineer Midwest Telecine LLC EraseMEmarkragesspam_OUTTakeThisOuTmidwesttelecine.com

On 10/19/07, Mark Rages <markragesspam_OUTgmail.com> wrote: > > An MSEE often involves doing something more abstract than transistor > > amplifiers which I would have studied a a few years before finishing my > > MS degree. My MSEE thesis is on using encryption algorithms in FPGAs. I > > learned a lot about encryption and FPGAs. Beating people who have an MS > > over your BS doesn't really mean anything because they probably did > > something fairly specific. > > - > > MK (MSEE '07) > > I agree with you (I did no analog during my MSEE), but the test is > such an easy one, any MSEE should pass it. It is similar to a > "fizzbuzz" test for programmers. Necessary, but not sufficient, to > choose a qualified candidate. > I did analog during my MSEE by research but I would not be able to solder 0805 SMD properly at the time. The interview was based on schematics of a temperature sensor interface codes. I was able to point out the converter topology and the inrush current protection circuits and roughly the other fuctional block (MCU/ ADC/etc) and they (Pepperl+Fuchs Singapore) hired me. The first month was orientation including some simple soldering training by the production operators. Xiaofan

Mark Rages wrote: > I agree with you (I did no analog during my MSEE), but the test is > such an easy one, any MSEE should pass it. It is similar to a > "fizzbuzz" test for programmers. Necessary, but not sufficient, to > choose a qualified candidate. > > It is sad that anyone applying for an embedded engineering position > would fail the test, but better to find out before hiring than after. > > Regards, > Mark > markrages@gmail > True, I didn't mean to imply that it was hard. It seems very easy. When I was interviewed for my job I had to draw some simple op-amp circuits. Fortunately I remembered them quite well. Remembering what a chopper stabilized op-amp does helped me out as well. I had completely forgotten to study any electronics before the interview. I did bring a sort of portfolio of everything I've done in eagle which IMO was impressive for being all extra-curricular projects. - MK

wouter van ooijen <wouter <at> voti.nl> writes: > some more comments from a nitpicker... You know, there are more ways to fail a test than to pass it. Starting a fight with the tester on the basis of Svejk logic is one of the best ... just like asking what the sum of 2 + 2 is and expecting to pass when answering 4 (hint the correct answer is: there are three possible answers: 1 in base 3, 0 in base 4, and 4 in all other bases higher than 4 - this is an ESPECIALLY relevant test wrt embedded assembly and radix imho - not that I'd think about it like that but *this* would be more of a theme for discussion than Dutch stubornness involving 0pf capacitors instead of a standard 1 stage common emitter transistor ac amplifier with an emitter resistor ensuring degenerative feedback at dc and thus temperature stability - the standard expected answer for such a test). I also find it annoying that engineers write tests for technicians because they tend to try to see the theoretical and 'potential' side of the answers where practice is the emphasis for technicians. I had to spend many years in the company of people I am no longer on speaking terms with due to professional divergences of the most serious kind as a result of such 'genius' hiring policies. This does not even touch the alpha ego problem (so brilliantly illustrated by Wouter) which is a proven recipe for sparks in a team. Peter P.

wouter van ooijen wrote: > some more comments from a nitpicker... > > diodes: I don't know an anode from a cathode, I don't want to know and I > don't need to know. I do know the band on the component is the bar in > the symbol, that's all I need. > > An arrow should suffice. I have had a mental block on which is which since I first ever read the words anode and cathode. > AC amplifier: no aplification factor is mentioned, so I'd offer either a > single capacitor between in put and output (factor ~1) or between output > and ground (factor ~0). Now that I think about it, no frequency range is > mentioned either, so I would specify 0 pF capacitors. > > I'd draw an op-amp circuit. It's extremely rare that in this day and age anyone will need to draw a discrete amplifier especially having "good temp. stability" without looking at a book. I don't like closed book tests for this application. If you really want to see resourcefulness and ingenuity which is what you probably want from an employee you should give them a more difficult test and a stack of books. - MK

On 10/18/07, Vitaliy <@spam@spamKILLspammaksimov.org> wrote: > > http://scantool.net/pub/electronics_test.pdf Good test, I like it. I'd fail on the last question though. :( > What do you think of those? In your opinion, what skills are essential for > embedded developers? What sets them apart from desktop app programmers? I'd focus on things like buses, CPU architecture, etc. - Describe I2C, SPI, and the pros / cons of each. Basically look for an answer like SPI requires individual chip selects, I2C is only 2 wire, etc. - How would you generate analog voltages from a uC? - Draw a circuit to drive a high current LED from a uC. - What uC's do you have experience with, describe the overall architecture of them. Alex

> wouter van ooijen <wouter <at> voti.nl> writes: >> some more comments from a nitpicker... > > You know, there are more ways to fail a test than to pass it. Starting a > fight > with the tester on the basis of Svejk logic is one of the best ... just > like > asking what the sum of 2 + 2 is and expecting to pass when answering 4 > (hint the > correct answer is: there are three possible answers: 1 in base 3, 0 in > base 4, > and 4 in all other bases higher than 4 - For more about number bases, listen to Tom Lehrer's "New Math" at http://curvebank.calstatela.edu/newmath/newmath.htm Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available!

On Thu, 2007-10-18 at 22:04 -0700, Vitaliy wrote: > What do you think of those? In your opinion, what skills are essential for > embedded developers? What sets them apart from desktop app programmers? I can't comment too well on what questions to ask, the embedded world is something completely different to almost anyone you ask. Some think knowing ASM is paramount, others think you shouldn't need to read the device datasheet... However, I just want to mention that relying only on "correct answers" is not a good idea IMHO. Don't get me wrong, I think it's VERY worthwhile to "test" people during interviews, it's what I had to do to get my current job. That said, be aware that there are LOTS of people that are just great at tests, but when you get them into real situations they don't work out. Also, there are lots of people who AREN'T good at the fake world of a "test", yet excel in the real world. Also, I wouldn't concentrate on what exactly the applicant knows. Who cares if they get a brain freeze and get one of the questions wrong. What I'd be more focused on is how the applicant DEALS with not knowing, or getting a question wrong. I've heard of applicants getting ANGRY (i.e. yelling and fists pounding on tables) with the interviewer, claiming the test "wasn't fair". I've heard of applicants who, even when presented clearly WHY their answer is wrong, will refuse to accept they might be wrong and state that their answer is correct and it's the interviewer that's wrong. In fact, a technique I've seen which I feel is very constructive is to put progressively tougher questions to the applicant, incrementing until you ARRIVE at a question they just don't get right. Anybody can learn what you need them to know, the willingness TO learn is what's important IMHO. TTYL

On 10/18/07, Vitaliy <KILLspamspamKILLspammaksimov.org> wrote: > Four years of going through resumes and conducting interviews convinced me > that tests are the best and the most objective way to judge a candidate's > qualifications. Here's an example that tests basic electronics knowlege: > > http://scantool.net/pub/electronics_test.pdf Most of your candidates have graduated just a high school or this test is for a college or university graduation ? http://en.wikipedia.org/wiki/High_school#United_States thx, Vasile {Quote hidden}> > This particular one was put together back in 2004, right now I'm working on > updating it to make it more relevant to what we do (feedback is welcome). > > I'm thinking about putting together a couple more tests, to test math and > software development skills. While math test is easy to write, I'm having > difficulty coming up with specific problems to evaluate programming skills. > > Joel Spolsky has this to say on the subject: > > http://www.joelonsoftware.com/articles/fog0000000073.html > > Specifically, he suggests the following exercises: > > 1. Reverse a string in place > 2. Reverse a linked list > 3. Count all the bits that are on in a byte > 4. Binary search > 5. Find the longest run in a string > 6. atoi > 7. itoa (great, because they have to use a stack or strrev) > > The exercises are followed up by a design problem (design a house or a trash > can or ...) > > What do you think of those? In your opinion, what skills are essential for > embedded developers? What sets them apart from desktop app programmers? > > Best regards, > > Vitaliy > > -

> the standard expected answer for such a test I don't expect (and probably don't want) to pass any test where standard answers are expected. Luckily most of my career I worked in positions were that was appreciated. Note that I don't frown on people who do preduce the expected answers: such persons are needed, and in great numbers, but I am not one of them. > This does not even touch the alpha > ego problem (so brilliantly illustrated by Wouter) which is a > proven recipe for sparks in a team. Now I have done it again - I illustrated a problem I don't even know about! But maybe that is the problem, or else it is the language :) Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> just like asking what the sum of 2 + 2 > is and expecting to pass when answering 4 (hint the correct > answer is: there are three possible answers: 1 in base 3, 0 > in base 4, > and 4 in all other bases higher than 4 I disagree (of course!). The correct answer is 2, in all bases, because + is (OK, among other interpretations...) the mathematical notation of the IOR operation. I just dragged 2 fresh classes through an introduction course on computer technology. One boy almost lynched me when, after having to learn to add and substract in all kinds of number systems, he also had to absorb that his familiar + sign (which had just been extended to adding of non-base-10 number) could also mean IOR. I could of course only sympathise. I tried to hint him about other rings and semi-rings. I don't think any of that got through, which was probably for the better. My conclusion: every communication (including a question) needs a context. In most cases it is the responsibility of the sender to make sure that the receiver knows the intended context. Don't assume too easily that your familiar context is the only possible one. Been there, hit my nose: being a (part-time) teacher I have to make exam texts. It is amazing how easily a question that seemed perfectly clear to me can be misunderstood because I did not make my assumtions (context) explicit. Needless to say, in such situations (provided that the student gave the correct answer under his interpretation) I must give the full points for the question, even though I did not get the answer I wanted. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

I would rather see a few questions about debugging. e.g. "What is a Read-Modify-Write problem and how can they be avoided?" "If you have a system in which there are 5 logical or physical processes with test points between each, and you know what the data should look like at each test point, given that the input data is correct, and the output from the system is incorrect, which test point would you validate first?" "What is the advantage of In Circuit Debugging over In Circuit Emulation?" "Given a system that fails consistently in actual operation but operates correctly as soon as it is attached to a test fixture, list some methods you might employ to find the problem." "The only tools you can have to debug a project are an LCD panel (parallel interface) or a single logic probe with pulse mode. Which would you select?" And a few others: "You are asked to recommend a microcontroller for a low quantity system that will be used in house only. Do you select a chip with all the required hardware on board, or "bit bang" the few interfaces needed via software and specify a lower cost chip with less onboard peripheral hardware? What if it was a high quantity system for sale to a large market segment?" "If you are hired as a contract programmer for the initial coding of a project that is expected to have a long life and possibly many revisions, would you choose to write the code in a commonly available language with which you are less familiar or with a little known language which you have used many times in the past?" (no right answer to that one, but it will be an interesting conversation) "During the development of a proprietary application in the workplace, you hit upon a unique way of solving a common programming problem which does not directly relate to the project. Will you A) publish the snippet B) Ask your boss if you can publish the snippet C) not mention the solution to anyone but use it again at this or other jobs in the future." {Original Message removed}

> e.g. "What is a Read-Modify-Write problem and how can they > be avoided?" Use a decent processor :-) > "Given a system that fails consistently in actual > operation but operates > correctly as soon as it is attached to a test fixture, > list some methods you > might employ to find the problem." Make an artificial test fixture. A standard finger would make you rich. > "During the development of a proprietary application in > the workplace, you > hit upon a unique way of solving a common programming > problem which does not > directly relate to the project. Will you A) publish the > snippet B) Ask your > boss if you can publish the snippet C) not mention the > solution to anyone > but use it again at this or other jobs in the future." Presumably Bresenham got it right. http://en.wikipedia.org/wiki/Bresenham's_line_algorithm Russell

> What do you think of those? In your opinion, what skills are essential for > embedded developers? What sets them apart from desktop app programmers? > I guess it depends what you mean by embedded programmers and what you mean by desktop programmers. A lot of desktop programming, especially for internal use is done in languages like java, vb, the .net familily etc. Theese allow crappy programmers to turn out code that is just about acceptable but tend to result in apps that are slow and bloated. In the embedded world we don't generally have that luxury, traditional languages like C and C++ with predictable (and generally quite good) performance but few safegaurds against programmer stupidity are used. Sometimes it is also basterdised versions of those languages. For example symbian C++ lacks exceptions replacing them with something lighter but more dangerous called leaves. PIC C has seperate rom and ram pointers and size/speed constraints mean that things like sprintf are generally avoided. Depending on the particular embedded application they may also have to understand hardware, interrupts etc. Something that desktop developers are pretty isolated from. They may need to know assembler and how to read device datasheets. how to work with buggy compilers and many other things.

> but I still think such a test can be a good starting point for a talk Ah, a conversation. We'll have just the right generation for you ==================== http://www.stuff.co.nz/sundaystartimes/4211545a6442.html Curriculum change shifts emphasis from 'what' to 'how' A controversial new national curriculum will teach pupils how to hold a conversation or ask for help rather than remember facts, historic dates or periodic tables > just don't treat the answers as if it were an exam. Mary Chamberlain, overseeing the project for the Education Ministry, says that although people are "rattled" by the changes, "there's no use (students) being little knowledge banks walking around on legs. "We've got computers, we don't need people walking around with them in their heads... People just have to get used to that." ==================== Teaching kids back to the Stone Age

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Oct 19, 2007 at 09:26:39AM -0200, Gerhard Fiedler wrote: {Quote hidden}> > 1. Reverse a string in place > > 2. Reverse a linked list > > 3. Count all the bits that are on in a byte > > 4. Binary search > > 5. Find the longest run in a string > > 6. atoi > > 7. itoa (great, because they have to use a stack or strrev) > > These questions are about typical algorithms. Most programming on small > embedded systems is very little about algorithms, and much more about > real-time problems (race conditions), system-level questions (interrupts, > protected access to vars), interaction with timed events, correct use of > peripherals (being able to read data sheets) -- things that a typical > desktop programmer rarely has to worry about. An example I just ran into: Built one quick pic thing with a serial protocol to download/upload info to a computer. Works great at 115200baud. (after much debugging) Take the same code and transplant it to a led controller with software pwm. Works ok in debugging, changing the value of single leds works fine, but the control app, which does hundreds every second, fails miserable. Why did the first work so well, with more data transfer, and the second fail? Easy, the second spends 95% of it's time handling pwm, and PICs have a 1-byte rx buffer, the former does nothing but read/write. Solution: Move the rx state machine to the interrupt handler and enable the usart RX interrupt. Took me all of 30 minutes to figure out and fix, but I think I'd pass the "reads data sheets from top to bottom in preference to actually getting work done" test. :) - -- http://petertodd.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHGX2N3bMhDbI9xWQRAn+PAJ9H25aCLZ6RtOYa5fqoZL0OoXYqswCeKO+I fSNSKSE7CTJTbEQETXn+gbc= =Mln/ -----END PGP SIGNATURE-----

Alan B. Pearce wrote: > >Here's an example that tests basic electronics knowlege: >>> >>> http://scantool.net/pub/electronics_test.pdf >> >>Too easy? > > Maybe, but is about the sort of level I would expect for getting someone > who > is looking to start in electronics. We used to give a similar sort of test > to prospective apprentices to see what hobby electronics they had done > before looking for work. When we came up with the test back in 2004 (I haven't changed anything since then, just fixed some typos), we thought so too. Out of about six candidates that took the test, only one was able to correctly answer all the questions. The rest got <60%, although they looked very good on paper. One candidate was even slightly indignant, like it was beneath him: "there is a TEST?!" The last engineer we hired didn't have to take a test, but only because I saw the project that he did for the student project fair (he also brought work samples to the interview). Vitaliy

William "Chops" Westfield wrote: > Interesting. I find the last question ("Draw schematic for a > one-stage AC amplifier with good temperature stability") > out-of-place WRT the rest of the test; perhaps I've just > been doing too much software and digital electronics Agreed. I'll take it off. > (Hmm. > There weren't ANY digital questions on that test, were there?) No, but you're right -- there should be. One thing I'm going to have there for sure, is designing a circuit from a truth table, and vice versa. Any other suggestions? Keep in mind it cannot be very time consuming. >> 3. Count all the bits that are on in a byte > > Hmm. Would you expect clarity or clever algorithms? IMO, it's irrelevant. This is a pass/fail test, to weed out those who can't do it at all. >> 7. itoa (great, because they have to use a stack or strrev) > > Nonsense. Many an itoa-like algorithm has been posted to piclist > that uses neither. > > These aren't bad, but it's easy for me to imagine a microcontroller > programmer that has never implemented a linked list, or a windows > programmer that has never done their own string processing. These aren't mine, they're Joel Spolsky's. :) AFAIK, his company is not doing any embedded development. Vitaliy

wouter van ooijen wrote: > but I still think such a test can be a good starting point for a talk. That's how it's meant to be used, in addition to being the most objective measure of candidate's ability. Along with a real-time, hands-on solving of a problem (sort of like what Joel suggests). > just don't treat the answers as if it were an exam. Of course not. Most of the time, there's no gray area: the candidate either passes with flying colors, or cannot solve the Ohm's law problem. We have a similar test for our shipping/receiving position. I interviewed two candidates in August, both with great resumes and both passed the phone screen. The first candidate had a 4.0 GPA in high school, and was maintaining a 4.0 GPA in college. He spent an hour on four simple problems, and answered "four boxes" to the last question: "There are two boxes: Box 1 (20x10x10) and Box 2 (30x10x5). Which box is bigger? How many 5x2x1 boxes can you fit in the bigger box?" Candidate #1 also couldn't convert pounds to kilograms (given the conversion factor). The second candidate correctly solved all four in about 7 minutes (I assume he could not believe how simple the test was, and spent a couple of minutes verifying his work). He also brought his own pencil and calculator, even though he didn't know about the test. Guess who got the job.

Martin wrote: >> diodes: I don't know an anode from a cathode, I don't want to know and I >> don't need to know. I do know the band on the component is the bar in >> the symbol, that's all I need. >> >> > An arrow should suffice. I have had a mental block on which is which > since I first ever read the words anode and cathode. Drawing of the diode would count as the right answer, but knowing that anode is the (+) side would be icing on the cake. > I'd draw an op-amp circuit. It's extremely rare that in this day and age > anyone will need to draw a discrete amplifier especially having "good > temp. stability" without looking at a book. I thought that was an easy question. A simple common emitter circuit with a voltage divider is really all I'm looking for. This question doesn't really belong on the test, since we're doing digital work almost exclusively. But FWIW, I knew the answer when I was 14 (it's mentioned in every intro text on analog amps) -- long before I had any idea what a 555 is. > I don't like closed book tests for this application. If you really want > to see resourcefulness and ingenuity which is what you probably want > from an employee you should give them a more difficult test and a stack > of books. I think for any profession, there's a certain level of "base" knowledge that is expected. The aim of this test is to determine the breadth of the candidate's knowledge, in a short period of time -- so IMHO it should have many simple 30-second problems. I like the idea of progressing from simple to more complicated questions, so if this was a PIC test, the candidate would be provided with a datasheet. I don't like the idea of providing books, because that can really skew the results. Someone familiar with a particular book would have an unfair advantage.

Alex Harford wrote: > I'd focus on things like buses, CPU architecture, etc. > > - Describe I2C, SPI, and the pros / cons of each. Basically look for > an answer like SPI requires individual chip selects, I2C is only 2 > wire, etc. > - How would you generate analog voltages from a uC? > - Draw a circuit to drive a high current LED from a uC. > - What uC's do you have experience with, describe the overall > architecture of them. Hm, great ideas. What I'm thinking is, there should be a battery of tests: - Math - Basic Electronics - Digital - Microcontrollers - Programming - "Subtests": PIC, Embedded programming, Java programming This way, it's possible to mix-n-match, depending on the position.

Vasile Surducan wrote: > Most of your candidates have graduated just a high school or this test > is for a college or university graduation ? > http://en.wikipedia.org/wiki/High_school#United_States Vasile, it is with much sadness that I have to report that IMO most current EE/CE students would not pass this test. On Wednesday I was one of the industry reps judging a local student project fair, and it's obvious that the college has significantly lowered the bar, compared to just eight months ago. Their enrollment is way down, so there's pressure to graduate as many students as possible. I spoke to the dean of the engineering programs, and volunteered to go to local high schools on behalf of the college to talk about engineering, and help conduct project competitions. We'll see what happens...

-----Original Message----- >From: Vitaliy <RemoveMEspamTakeThisOuTmaksimov.org> >Sent: Oct 20, 2007 1:19 AM >To: "Microcontroller discussion list - Public." <piclistEraseME.....mit.edu> >Subject: Re: [EE] Test for embedded developer candidate > >wouter van ooijen wrote: >>> > In your opinion, what skills are essential for embedded developers ? >> >> For all software guy, maybe even for all engineering types: the desire >> never to make the same mistake twice. > >How would you determine that? >-- I don't know an elgant way to say lazy in a nice way but the good system and network admins are just that - in a good way. :-) blogoscoped.com/archive/2005-08-24-n14.html "Why Good Programmers Are Lazy and Dumb" www.pbm.com/~lindahl/real.programmers.html "Real Programmers Don't Use Pascal"

James Newton wrote: >I would rather see a few questions about debugging. [...] I think these tests are more appropriate for another test (micros/PICs), and since personally I would prefer to answer them orally (since the answers will likely be rather wordy). > "Given a system that fails consistently in actual operation but operates > correctly as soon as it is attached to a test fixture, list some methods > you > might employ to find the problem." Hm, I'd be curious to know the answer to this one, myself! :) > "The only tools you can have to debug a project are an LCD panel (parallel > interface) or a single logic probe with pulse mode. Which would you > select?" Both? Isn't this application and problem dependent? > "You are asked to recommend a microcontroller for a low quantity system > that > will be used in house only. Do you select a chip with all the required > hardware on board, or "bit bang" the few interfaces needed via software > and > specify a lower cost chip with less onboard peripheral hardware? What if > it > was a high quantity system for sale to a large market segment?" This sounds almost too easy, but I see the value in it. :) It's kind of like the question on an application I filled out once, "It is OK to steal from the company if everyone is doing it. True or False?" Some people are really that dumb, and it's good to have these sorts of questions to quickly weed them out. > "If you are hired as a contract programmer for the initial coding of a > project that is expected to have a long life and possibly many revisions, > would you choose to write the code in a commonly available language with > which you are less familiar or with a little known language which you have > used many times in the past?" (no right answer to that one, but it will be > an interesting conversation) What would you look for, in their answer? > "During the development of a proprietary application in the workplace, you > hit upon a unique way of solving a common programming problem which does > not > directly relate to the project. Will you A) publish the snippet B) Ask > your > boss if you can publish the snippet C) not mention the solution to anyone > but use it again at this or other jobs in the future." Not enough information?

>> One thing I'm going to have there for sure, is designing >> a circuit >> from a truth table, and vice versa. Any other >> suggestions? Should borderline analog/digital capability be of interest: Explain the operation of the following circuit(s) - Circuit of classic 2 transistor Schmitt trigger with inmput triangle wave shown - 2 transistor NPN/PNP oscillator with AFAIR 2 x R and 1 x C. It's notionally a multivibrator, but it comes from hell. For that matter, - Classic 2 transistor both eg NPN multivibrator. - Std 2 and 3 inverter RC oscillator circuits. Extra credit - comment on proble with the 2 transistor cct which the 3 transistor version doesn't have ________________________ All the above circuits bend the brain - the more so if you'e never met them before. Driving nodes negative and having them recover with RC time constant makes operation 'interesting'.. _________________________ A few MOSFET ccts which use them "backwards" to do real things - or series opposed :-) _______________ Getting a bit specific, and non digital, but fun. R

On 10/19/07, Vitaliy <EraseMEspammaksimov.org> wrote: > Vasile Surducan wrote: > > Most of your candidates have graduated just a high school or this test > > is for a college or university graduation ? > > http://en.wikipedia.org/wiki/High_school#United_States > > Vasile, it is with much sadness that I have to report that IMO most current > EE/CE students would not pass this test. Which students ? From MIT ? Then where is the problem ? The teacher, the student or the system? I have almost defined the ideea for a complete practical course about electronics (yes with electronic components in plastic bag glued on every course) covering everything in about 1000 pages splitted as separately issues. Minimal math or no math inside treating the phenomena and not the equations. Courses which must be readed with the soldering iron in the hand and with the protoboard on the table. > > On Wednesday I was one of the industry reps judging a local student project > fair, and it's obvious that the college has significantly lowered the bar, > compared to just eight months ago. Their enrollment is way down, so there's > pressure to graduate as many students as possible. > > I spoke to the dean of the engineering programs, and volunteered to go to > local high schools on behalf of the college to talk about engineering, and > help conduct project competitions. We'll see what happens... > > -

On Oct 19, 2007, at 9:33 PM, Vitaliy wrote: > Any other suggestions? Debugging, in both the HW and SW section. A "what's wrong with this circuit/function?" For HW, I suggest missing base resistors, or NPN transistors as high-side drivers, driven from a micro output. For embedded software, how about one of these: int checkinput() { unsigned char c; c = getc(); /* getc returns assorted negative vals for errors. */ if (c < 0) { return -1; /* But we just want a single error val. */ } return c; } ---- or ---- (this one would translate well to assembler, too.) int setbit (int word, int whichbit) { return word | (1 << whichbit); /* Set the specified bit */ } int clearbit (int word, int whichbit) { return word & (1 << whichbit); /* Clear the specified bit */ } (the whole (1<<whichbit) C syntax seems to catch a lot of people who you think would know better.) (double points on the second problem if they complain about no range check for whichbit.) ---- In retrospect, the software questions weren't too bad, if you're not being overly picky about 100% perfect answers. Even someone not too familiar with the BillW

> >> > In your opinion, what skills are essential for embedded > developers > >> > ? > > > > For all software guy, maybe even for all engineering types: > the desire > > never to make the same mistake twice. > > How would you determine that? That was not the question :) In students I can see a clear division. When a student had a problem, and now he does not, there are two clearly separate attitudes: go on and forget about it, or being determined to find the root cause (and presumably, never do it again). The last attatitude is the most promising for a programmer. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> > My conclusion: every communication (including a question) needs > > acontext. > > In this case the context was the word 'sum' in the definition > of the problem. (nitpick mode, don't take me too serious) That word did not have any meaning, because you stated "sum of 2 + 2". " 2 + 2 " is only one item, so it cannot be summed, so the word has to be meaningless. (one level higher in the nitpicker mode) But summing is defined for any number of elements, from 0 up! Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> As an aside, I always remember cathode = negative, because of > Cathode Ray Tubes. The electron beam comes from the cathode, > and electrons are negative. Thus the cathode must be negative:) I'll try to remember that one. My attempt was "cold cathode", which implies that "warm cathode" also exists, and I do know that the purpose of the heat is to boil out the electrons. But often I could not remember whether it was supposed to be "cold cathode" or "cold anode" :( Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

On 10/20/07, Vitaliy <RemoveMEspamspam_OUTKILLspammaksimov.org> wrote: > Hm, great ideas. What I'm thinking is, there should be a battery of tests: > > - Math > - Basic Electronics > - Digital > - Microcontrollers > - Programming > - "Subtests": PIC, Embedded programming, Java programming > > This way, it's possible to mix-n-match, depending on the position. Will this scare the candidates to death? ;-) I do not see the point if the following is correct. On 10/20/07, Vitaliy <RemoveMEspamTakeThisOuTspammaksimov.org> wrote: > Vasile, it is with much sadness that I have to report that IMO most current > EE/CE students would not pass this test. > >From which universities? I think there are better universities out there. I tend to think the text books used in the US universities are pretty difficult. I was sitting in a undergraduate digital control engineering course in a private university and I still needed to spend some efforts on it to get an "A". But I would not be too much surprised if the students are from local public state universities. As a Teaching Assistant for a senior engineering course in a top 50 US University (public), I found it hard to believe that some of the 4th year EE students lack the very very basic maths and engineering skills. Xiaofan

On 10/20/07, William Chops Westfield <EraseMEwestfwspamspamBeGonemac.com> wrote: > > On Oct 19, 2007, at 10:31 PM, Vitaliy wrote: > > > there should be a battery of tests > > the well-qualified candidate will get sick of > trivial tests and form a bad impression of your > company. If I receive a response to an application > for a job, I expect to talk to someone who knows > what the job is about so "we" can come to a decision > on whether I'm suited for the job. I don't expect > a "battery" of tests designed to see whether I was > lying through my teeth on my resume! I tend to agree with this. The only interview I went to which has the tests was from a no-name company. Xiaofan

> > presumably, never do it again). The last attatitude is the most > > promising for a programmer. > > May I ask in what quality you teach ? Teacher, assistant, > lecturer, professor ? And whether this is a University or > another type of institution ? Of course there is no need to > answer, as you like. I am just curious. The Dutch higher eduactional system is not 1-1 compareable with most other systems, but I'll give it a try. We have 2 types of higher eduaction (both compareable to USA University), one is more theoretical and has a somewhat higher status, the other is a bit more practical and has (surprise, surprise) a somewhat lower status. For both types the rule (up to now) is that you go for one subject, for instance Technical Informatics. All of that is in a state of some change, with some merging of the two types, and introduction of major/minor profiles. Take care with naming: the lower type is called 'hogeschool', the higher type 'university', but historically also 'technische hogeschool'. So our 'hogeschool' is definitely not the USA 'highschool'. I have a 40% assignment at the Hogeschool Utrecht (the more practical type). I am not sure what the USA equivalent of my assignment would be. In my country a 'professor' is the head of a university department, often more a manager than a teacher. A 'hogeschool' can not have a professor. I am not sure what the distinction is between teacher and lecturer. My job is to give classes, to prepare new classes, and to generally contribute to the curriculum. We have a slightly lower grade of teacher who is only supposed to give classes, not to develop new ones. We also have assistants, who are more important than anyone else (OK, except for the secretary) because they make sure all technical stuff works. Where would I be without the beamer, classroom PCs, oscilloscopes, etc! We also have a higher (than me) grade of teacher who is also responsible for coordination of a small group (~10 teachers) and initiating new directions for the curriculum. The fact that I work for this particular school is a coincidence. I quit my 'normal' job some years ago and hired myself out for some time, but I don't have the minset for selling myself in that way, so after a few assignments (and some troubles in New York) that did not go smoothly. Meanwhile my shop and consulding developed in a promising but slow way, so I was looking for some work to add to this. Also 'meanwhile' our 3 kids were born and my wife's career developed promising, so we opted for a part-time job for me that allows me to handle the kids 4 days out of 5 (the 5'th is for my wife). Teaching is perfect for this, and Utrecht is nearby. (This year I also teach at their branch in Amersfoort, which is only 100m from my house!). I met a coordinator of the Technical Informatics branch at a computer fair, we talked a little, and I got an assignement. In practice I work for Technical Informatics, Emedded Systems, and (this year) Security Systems. All clear? Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Vitaliy wrote: > Out of about six candidates that took the test, only one was able to > correctly answer all the questions. If you really get so many way-below-qualification resumes that can't be detected clearly on paper, such a simple test makes a lot of sense. Someone who can't answer a few really simple questions doesn't even have to be interviewed. > The last engineer we hired didn't have to take a test, but only because I > saw the project that he did for the student project fair (he also > brought work samples to the interview). That's probably the deal. You'll know a good engineer when you talk to him/her. You 'feel' the substance. The test is just to weed out the ones you don't even have to talk to. That Joel article may not be realistic in one point. He says to 'just say no' when you're not sure you got the right person. But sometimes you need to get a job done, can't do it yourself, and don't seem to find the 'right' one -- which sounds like your situation with the graphics designer. And sooner or later you'll need to give the job to someone; which may not be the 'right' one. Engineering compromises :) Gerhard

Russell McMahon wrote: > All the above circuits bend the brain - the more so if you'e never met > them before. Driving nodes negative and having them recover with RC time > constant makes operation 'interesting'.. I think there are two types of tests. One is with very simple questions that have a clear (and usually simple) answer with little space for ambiguities (and if someone starts to nitpick awfully off-topic, you also know who not to hire -- after all, that doesn't fit into the 'gets the job done' category you need, which often requires just the 'right' feel to understand the /purpose/ behind the requirements document rather than the unusual meanings in the words in that document :) Here the purpose is simple: got it, you're in the next step, didn't get it, you're out. Save time. The other is with questions that are sort of open-ended and leave space for going into various directions. Here the focus is not on the result, but on the way the candidate elaborates, to get to know how she thinks. Spend (some) time. IMO brain benders go into the second category :) Gerhard

William "Chops" Westfield wrote: > the well-qualified candidate will get sick of trivial tests and form a > bad impression of your company. I thought of adding a short explanation to the top of the simple weed-out test. > If I receive a response to an application for a job, I expect to talk to > someone who knows what the job is about so "we" can come to a decision > on whether I'm suited for the job. I don't expect a "battery" of tests > designed to see whether I was lying through my teeth on my resume! Of course you're right -- in an ideal world :) Reality may be different. If the market is so that for any such ad there are only a handful candidates, your expectation is realistic. If OTOH there are often hundreds of candidates for an ad, your expectation is unrealistic, and if I were the hirer and you made your expectation clear to me, that could disqualify you. If you don't understand the very real need of the hirer to weed out 150 candidates that can't answer a simple test that is way below the actual requirements and that should take you all of ten minutes to answer, so that he can spend his time more productively with the 10 that pass it, you're likely not to understand the many more real-world compromises one has to make in a business. Gerhard

Vitaliy wrote: >> "If you are hired as a contract programmer for the initial coding of a >> project that is expected to have a long life and possibly many >> revisions, would you choose to write the code in a commonly available >> language with which you are less familiar or with a little known >> language which you have used many times in the past?" (no right answer >> to that one, but it will be an interesting conversation) > > What would you look for, in their answer? IMO correct answer is 'present the client with the pros and cons and let the client decide'. (The pros and cons in this situation typically include a higher price tag up front for the more common language but a good chance of a higher price tag in the long run for the little known language.) Implementation language for a project that the client is supposed to continue to maintain is something the client has to decide (and sign off) up front. They may still leave the decision up to me, but they need to know what they're getting themselves into and need to sign off the decision. IMO this is very basic for contract programming, but not so relevant for an in-house programmer. A programmer who always was employee may not have a satisfactory answer here, because the situation is too far away for his reality. OTOH, if he's expected to lead contract engineers, he should be able to give you some comments in the sense of 'this would never happen; of course I'd specify the implementation language for any project we hire out'. Gerhard

On Fri, Oct 19, 2007 at 10:04:36PM -0700, Vitaliy wrote: {Quote hidden}> wouter van ooijen wrote: > > but I still think such a test can be a good starting point for a talk. > > That's how it's meant to be used, in addition to being the most objective > measure of candidate's ability. Along with a real-time, hands-on solving of > a problem (sort of like what Joel suggests). > > > just don't treat the answers as if it were an exam. > > Of course not. Most of the time, there's no gray area: the candidate either > passes with flying colors, or cannot solve the Ohm's law problem. > > We have a similar test for our shipping/receiving position. I interviewed > two candidates in August, both with great resumes and both passed the phone > screen. The first candidate had a 4.0 GPA in high school, and was > maintaining a 4.0 GPA in college. He spent an hour on four simple problems, > and answered "four boxes" to the last question: > > "There are two boxes: Box 1 (20x10x10) and Box 2 (30x10x5). Which box is > bigger? How many 5x2x1 boxes can you fit in the bigger box?" Ouch! > > Candidate #1 also couldn't convert pounds to kilograms (given the conversion > factor). Double ouch! > > The second candidate correctly solved all four in about 7 minutes (I assume > he could not believe how simple the test was, and spent a couple of minutes > verifying his work). He also brought his own pencil and calculator, even > though he didn't know about the test. > > Guess who got the job. Duh. As usually it illustrates those who memorize and those who understand. I'll take a flexible problem solver anytime over a bank of facts. Of course I prefer both when possible. ;-) BAJ

> Four years of going through resumes and conducting interviews > convinced me that tests are the best and the most objective > way to judge a candidate's qualifications. Here's an example > that tests basic electronics knowlege: > > http://scantool.net/pub/electronics_test.pdf > How about this one <http://www.forddoctorsdts.com/quizzes/MechanicalAptitude.php>? No electronics (has electrical though). If nothing else, it tests that you read the question properly. I wonder how many mechanics pass that one. FWIW, I don't think the Joel Spolsky test is all that useful for most desktop app programmers, it's more a 'have you graduated recently' test. Bit twiddling? Linked lists? Desktop stuff is probably more design & language knowledge than low level coding, we have libraries for that stuff. Embedded programmers often don't have libraries, of course, so that's a bit different. Tony

> > but I still think such a test can be a good starting point > for a talk > > Ah, a conversation. We'll have just the right generation for you > > ==================== > > www.stuff.co.nz/sundaystartimes/4211545a6442.html > > Curriculum change shifts emphasis from 'what' to 'how' > Mary Chamberlain, overseeing the project for the Education > Ministry, says that although people are "rattled" by the > changes, "there's no use > (students) being little knowledge banks walking around on legs. > > "We've got computers, we don't need people walking around > with them in their heads... People just have to get used to that." Ah, so the answer to 'Is our childrens learning?' would seem to be 'No, they can just look it up on Google.' Sounds good to me. Flaws, what flaws? Tony

On 10/20/07, wouter van ooijen <spamBeGonewouterSTOPspamEraseMEvoti.nl> wrote: > > "There are two boxes: Box 1 (20x10x10) and Box 2 (30x10x5). > > How many 5x2x1 boxes can you fit in the bigger box?" > > Two remarks, modestly nitpicking: > > - I am not allowed to ask such 'stacked' questions > - 200 might be OK for a mathematician, but definitely > wrong in the real world! > One more nitpick, the unit is not specified, so any answer will be correct. ;-) So it is the examiner who failed. ;-) And Wouter's remark reminded me of my working experiences in the the cosmetics bag company, I was helping the shipment girl to fill up the 20 feet container and we often had problems if we do not leave some buffers. In that company I did almost everything (calculating materials, wrting production instructions, translation, shipping, HR, QC, fixing telephones, etc) except operating the sewing machine. ;-) Xiaofan

Gerhard Fiedler wrote: >> the well-qualified candidate will get sick of trivial tests and form a >> bad impression of your company. > > I thought of adding a short explanation to the top of the simple weed-out > test. There is one already. :) {Quote hidden}>> If I receive a response to an application for a job, I expect to talk to >> someone who knows what the job is about so "we" can come to a decision >> on whether I'm suited for the job. I don't expect a "battery" of tests >> designed to see whether I was lying through my teeth on my resume! > > Of course you're right -- in an ideal world :) > > Reality may be different. If the market is so that for any such ad there > are only a handful candidates, your expectation is realistic. If OTOH > there > are often hundreds of candidates for an ad, your expectation is > unrealistic, and if I were the hirer and you made your expectation clear > to > me, that could disqualify you. If you don't understand the very real need > of the hirer to weed out 150 candidates that can't answer a simple test > that is way below the actual requirements and that should take you all of > ten minutes to answer, so that he can spend his time more productively > with > the 10 that pass it, you're likely not to understand the many more > real-world compromises one has to make in a business. It's not really about weeding out 150 candidates, in most cases 95% of the candidates are eliminated upfront based on their resume. It's mostly about determining whether a particular candidate out of the remaining 5% actually has the basic qualifications for the job. Unfortunately, the resume is a rather poor indicator. Even though it may not be "lying", some people tend to embellish their resumes. Maybe their definition of "an expert in C" is very different from mine -- and I need to know what it is. The test is not a prerequisite for the interview, in fact it's only given to those candidates who have already passed the resume sort and the phone screen. I found that most candidates don't mind taking the test, I have never had anyone flat out refuse to take one. And those that get somewhat indignant ("whaat?! there's a test?!"), are usually the ones that know the least. The bottom line is, the test helps us make better hiring decisions, and it saves a lot of our and the candidate's time. If someone can't apply Ohm's law to a circuit, we're going to fire this person anyway -- why not weed them out upfront? Vitaliy

Gerhard Fiedler wrote: >> Out of about six candidates that took the test, only one was able to >> correctly answer all the questions. > > If you really get so many way-below-qualification resumes that can't be > detected clearly on paper, such a simple test makes a lot of sense. > Someone > who can't answer a few really simple questions doesn't even have to be > interviewed. My view is different: interview first, then test. >> The last engineer we hired didn't have to take a test, but only because I >> saw the project that he did for the student project fair (he also >> brought work samples to the interview). > > That's probably the deal. You'll know a good engineer when you talk to > him/her. You 'feel' the substance. The test is just to weed out the ones > you don't even have to talk to. Hm, I don't trust my gut feeling that much. Some people are just great communicators, and know a lot of the jargon. The test is a sort of confirmation of my good feeling. :) > That Joel article may not be realistic in one point. He says to 'just say > no' when you're not sure you got the right person. But sometimes you need > to get a job done, can't do it yourself, and don't seem to find the > 'right' > one -- which sounds like your situation with the graphics designer. And > sooner or later you'll need to give the job to someone; which may not be > the 'right' one. Engineering compromises :) Actually, I found that to be very true. If you can't find the right person, it's better not to fill the position, rather than fill it with a "warm body". I did have a weak moment, and hired a "second choice" graphics designer in August. When after two weeks I found myself constantly holding his hand, and explaining how to use filters in Photoshop, I realized I had to fire him. A lot of money, and mine and his time down the drain. Not to mention the sleep I lost over it, and the grief this caused him. The guy has two young kids, and after he was hired I found out he's in financial trouble (he brought me some forms from the bank to sign). The same idea is the core of the "From Good to Great" book. Great companies are more about great people, than anything else. It's a recurring theme -- just recently I read about it in "Peopleware". They put it diplomatically, something to the effect of "the candidate may need to transfer to a different department, or even a different company" Vitaliy

wouter van ooijen wrote: >> "There are two boxes: Box 1 (20x10x10) and Box 2 (30x10x5). >> How many 5x2x1 boxes can you fit in the bigger box?" > > Two remarks, modestly nitpicking: > > - I am not allowed to ask such 'stacked' questions > - 200 might be OK for a mathematician, but definitely wrong in the real > world! Not sure if 200 would be ok for a mathematician. A real mathematician probably would say "depends (mostly on the wall thickness and whether the measurements are inside or outside), but assuming a reasonably thin wall and all maximum outside measurements, at least 130". OTOH there are people who have a real good eye for such things, including how to place things optimally, and are quick with very accurate estimates -- but who couldn't calculate their way out of an open box :) Gerhard

Jinx wrote: >> Supply the truth tables for the GATES? Jinx, you're kidding! :) > > Oh, OK. Guess they aren't that hard. You either know them or > you don't. Perhaps don't use I don't have the truth tables memorized (haven't really used gates since my freshman year), but I can "derive" them for any gate, because I remember what a gate should behave like, based on its name. :) > What about the basics of a power supply ? eg what voltage and > VA-rating transformer would you use to get 12VDC @ 2A ? > Draw a bridge rectifier > > What does a choke do in a PSU ? What does a filter cap do ? These are rather specific to power supplies, maybe these should be in a more advanced test. > Why do digital ICs need big and small bypass caps ? This is one for a more advanced micro test. I agree that it's a good way to determine whether someone has had hands-on experience, beyond coursework.

Xiaofan Chen wrote: >> Hm, great ideas. What I'm thinking is, there should be a battery of >> tests: >> >> - Math >> - Basic Electronics >> - Digital >> - Microcontrollers >> - Programming >> - "Subtests": PIC, Embedded programming, Java programming >> >> This way, it's possible to mix-n-match, depending on the position. > > Will this scare the candidates to death? ;-) I think both you and Bill misunderstood my intent (my bad). Of course no one will be asked to do all of the tests. Only the one(s) appropriate for the position. In any case, a candidate with the appropriate skill set would be able to complete the tests > I do not see the point if the following is correct. I think the point is, I will hire great people, or I won't hire at all. >>From which universities? I think there are better universities out there. Just a local private technical university (DeVry). > I tend to think the text books used in the US universities are pretty > difficult. I was sitting in a undergraduate digital control engineering > course in a private university and I still needed to spend some efforts > on it to get an "A". Yes, that is how I remember it too. Things have radically changed in recent years. > But I would not be too much surprised if the students are from local > public state universities. As a Teaching Assistant for a senior > engineering course in a top 50 US University (public), I found it hard > to believe > that some of the 4th year EE students lack the very very basic maths > and engineering skills. :( Vitaliy

>James Newton wrote: >>I would rather see a few questions about debugging. >[...] > >I think these tests are more appropriate for another test (micros/PICs), and >since personally I would prefer to answer them orally (since the answers >will likely be rather wordy). Sorry, I thought that was the subject of the test, but going back and reading again, I see I was wrong. >> "Given a system that fails consistently in actual operation but operates >> correctly as soon as it is attached to a test fixture, list some methods >> you >> might employ to find the problem." > >Hm, I'd be curious to know the answer to this one, myself! :) > - More sensitive test fixture (that applies less load the signals being measured). - Target the lines that could be affected by the test fixture to narrow the possible cause of the problem. - Use ICD rather than ICE or other external test fixtures. - Check for grounding or other electrical supply problems that the test fixture might be correcting when it is connected. >> "The only tools you can have to debug a project are an LCD panel (parallel >> interface) or a single logic probe with pulse mode. Which would you >> select?" > >Both? Isn't this application and problem dependent? > I suppose you could say that... My thinking is that toggling an LED is one instruction and easy to insert just about anywhere; calling an LCD output routine is going to be a more serious change to the code and more likely to throw off timing, and so on. Less invasive is generally better. Perhaps there is a better question to get to the idea that the critical point in debugging is to not be invasive of the system under test. <SNIP> >> "If you are hired as a contract programmer for the initial coding of a >> project that is expected to have a long life and possibly many revisions, >> would you choose to write the code in a commonly available language with >> which you are less familiar or with a little known language which you have >> used many times in the past?" (no right answer to that one, but it will be >> an interesting conversation) > >What would you look for, in their answer? > Recognition that a more common language will better allow future programmers to update the code. If he only thinks about himself, he will try to justify his own favorite language. As an example, and hopefully without turning this into a "C vs ASM" debate, if you are going to be the only programmer and you like ASM better, then fine, but if you are doing something that others will then need to maintain, C is the better choice. 50 people will now list cases where that is not true, but I'm speaking in generalities here. >> "During the development of a proprietary application in the workplace, you >> hit upon a unique way of solving a common programming problem which does >> not >> directly relate to the project. Will you A) publish the snippet B) Ask >> your >> boss if you can publish the snippet C) not mention the solution to anyone >> but use it again at this or other jobs in the future." > > Not enough information? > What information would you want?

On 10/21/07, Vitaliy <EraseMEspamEraseMEmaksimov.org> wrote: > >>From which universities? I think there are better universities out there. > > Just a local private technical university (DeVry). I see. But I think Professor Chen's C18 bsed PIC course is pretty good. http://faculty.tp.devry.edu/~schen/ He s "schen" in Microchip Forum. > > I tend to think the text books used in the US universities are pretty > > difficult. I was sitting in a undergraduate digital control engineering > > course in a private university and I still needed to spend some efforts > > on it to get an "A". > > Yes, that is how I remember it too. Things have radically changed in recent > years. That was not so long ago. I attended RPI (http://www.rpi.edu) for a semester in Fall 2003. Even though I did not like Troy and my supervisor and chose to quit my study, I think RPI is an excellent university and the undergraduate program is really good. > > But I would not be too much surprised if the students are from local > > public state universities. As a Teaching Assistant for a senior > > engineering course in a top 50 US University (public), I found it hard > > to believe that some of the 4th year EE students lack the very > > very basic maths and engineering skills. > > :( In the lab, there are some dual 25V power supplies. The first thing I asked them to do is to connect the power supply to get 30V. Half of the students could not get it done. I was a good TA so after the course, they all knew how to do that and got trained in soldering. With proper training, I think they were not that bad after all. That being said, I think the graduate program in US universities (top 100) are all world class. Xiaofan

Vitaliy wrote: >>> Out of about six candidates that took the test, only one was able to >>> correctly answer all the questions. >> >> If you really get so many way-below-qualification resumes that can't be >> detected clearly on paper, such a simple test makes a lot of sense. >> Someone who can't answer a few really simple questions doesn't even >> have to be interviewed. > > My view is different: interview first, then test. I don't think this is a good choice. After an interview, there shouldn't be much need for such a simple test. And why would you want to interview the five who couldn't answer the questions? Aren't they disqualified? That's my point with two sets of test questions. One set is a very simple test, kind of a "need to get it right" test. Anybody who doesn't get it all right is not right for the job. If that get's rid of 50% of the candidates, you just increased the time you can spend in selecting among the real candidates by 100%. The second set consists of questions that you may or may not bring up during the interview, not to get a right or wrong answer, but to get a conversation started. >> That's probably the deal. You'll know a good engineer when you talk to >> him/her. You 'feel' the substance. The test is just to weed out the >> ones you don't even have to talk to. > > Hm, I don't trust my gut feeling that much. Some people are just great > communicators, and know a lot of the jargon. The test is a sort of > confirmation of my good feeling. :) That's what I would use the second set of question for, and the (first) test to give you the time to talk properly to the people who passed it. Gerhard

On 10/21/07, Gerhard Fiedler <@spam@lists@spam@spam_OUTconnectionbrazil.com> wrote: > > The bottom line is, the test helps us make better hiring decisions, and > > it saves a lot of our and the candidate's time. If someone can't apply > > Ohm's law to a circuit, we're going to fire this person anyway -- why > > not weed them out upfront? > > Exactly -- that's why I wonder why you would interview such people in the > first place. This depends on the manager. Some of them will rely on the HR to filter out the resumes. Some of the managers does not trust the HR since some of the HR staffs are not so competent. And it is not easy to filter the resumes nowadays, especially for fresh graduates. Xiaofan

> I need a holiday. A car parked just near the end of our > drive last > night had the plate AND254. Do you know what I really > really first > read it as ? andlw 0xfe COFFEE = 12,648,430 COFFEE = 60,177,758 The first of those, written on our research room whiteboard long long and several lifetimes ago, used to cause people to stand in silent contemplation for long moments and then to either erupt with delight or walk away shaking their heads. ________ >From the same era: I followed a motorcycle that tugged at my brain for reasons which I could not place. After some while I realised that the number plate was "26BNE". What processor was I working with at the time? _______ The ST6 processor, which I used for a specific product some while ago, lacks either AND or OR instruction. I forget which. You have to use DeMorgan's theorum to implement the missed instruction. The ST6 is close to the truest RISC uP I've met. It's close to a NISC. A PDP8 instruction comes closer but is more powerful :-). And the ST6 is horrendously slow for a given clock speed - about 12 cycles per instruction AFAIR. Despite all that it's entirely usable and well behaved and it did what I wanted. It had ADC on most pins, which makes life much easier. I've recently added the ST7 8 pin 6 I/O variants to my 'maybe' list for a new project. I have done NO research on them at all yet, other than noting that they are about as cheap as anything else (the nearly OVERWHELMING requirement), and now have 10 bit ADC on all (6) I/O pins. I wonder if it's grown an OR instruction over the years? Russell > --

>> I followed a motorcycle that tugged at my brain for >> reasons >> which I could not place. >> After some while I realised that the number plate was >> "26BNE". >> What processor was I working with at the time? > Ah yes - writing eprom monitor code in 6800 hex... 6802 - correct. Real time multitasking thesis project written in machine code (not assembler) coz the assemblers were too dear and they hadn't bought one :-). Analysed telephone dialing and progress tones. Uphill, both ways, in the snow ... . That sad, one could hardly find a more nicely structured machine to write machine code out of your head for. All the bit fields together and in order and ... unlike many machines which scatter them hither and you. I/we had no idea at the time how lucky we were. Russell

On Oct 20, 2007, at 6:21 PM, Xiaofan Chen wrote: > That was not so long ago. I attended RPI (http://www.rpi.edu) for a > semester in Fall 2003. Even though I did not like Troy and > my supervisor and chose to quit my study, I think RPI is an > excellent university and the undergraduate program is really good. I would have to state that so far, all of the engineers I've worked with over the last (just under) 20 years in my career who had RPI degrees, have all been top-notch. To a person, they've all also been slightly over-confident, also -- but perhaps it's justified. They all "knew" they were good. They all also had a deep love of their engineering (a passion for it, shall we say) and would help people outside of work hours on just about anything. (Side-note: Olin's an RPI grad, I believe.) Whether or not I've seen a large enough "sample" of the RPI population overall, is probably up for debate. I know the number of RPI grads I've met isn't statistically significant! :-) It makes for an interesting side-question: What are the values and teaching techniques at RPI that help differentiate the people that come out of the program? I've also worked with a number of MIT grads and without question they're all very good too, but seem less interested overall in "mundane" engineering -- if I had to think up a way to describe it. They know their stuff, but tend to gravitate away from "normal" problems as soon as they've shown someone else how to do the engineering work to fix them. Not that this is "bad" in any way, but definitely a different "feel" than the RPI guys. (And I say RPI "guys" because honestly, the school is something like 90% male or more... no offense meant to either the female RPI engineering candidates or the MIT folks... just general observations over a couple of decades.) -- Nate Duehr spamBeGonenateKILLspamnatetech.com

Gerhard Fiedler wrote: >> The bottom line is, the test helps us make better hiring decisions, and >> it saves a lot of our and the candidate's time. If someone can't apply >> Ohm's law to a circuit, we're going to fire this person anyway -- why >> not weed them out upfront? > > Exactly -- that's why I wonder why you would interview such people in the > first place. Because I agree with Joel Spolsky on this: "One temptation of recruiters is to try and add a few extra hoops to the application process. I've frequently heard the suggestion of including a programming quiz of some sort in the application procedure. This does work, in the sense that it reduces the number of applications you get, but it doesn't work, in the sense that it doesn't really improve the quality. Great developers have enough choices of places to work that only require the usual cover letter/resume application to get started; by inventing artificial hoops and programming tests and whatnot simply to apply, you're just as likely to scare away good programmers as weak programmers. Indeed, you may be more likely to scare away the best programmers, who have the most alternatives, and get left with a pool of fairly desperate candidates who are willing to do extra work to apply simply because they don't have any alternatives." After the resume sort, I'm normally left with just a few candidates. When I said "save time" I meant that the 15- or even 60-minute test has the potential of saving weeks, or however long it would take to realize that the candidate isn't fit for the job -- even though their resume looked great, and they aced the interview.

William "Chops" Westfield" wrote: >Only the one(s) appropriate >> for the >> position. In any case, a candidate with the appropriate skill set >> would be >> able to complete the tests > > That would probably be OK. It's just that I can easily see ALL of > those > applying to an "embedded developer" position. That sentence above was unfinished (hence no period). I don't know what happened (remote connection gobbled up the ending?), but it was supposed to say "...in 15-45 minutes". In other words, a very minimal amount of time. One more thing: when I took Career Development in college, we were told to expect a test at the interview (I still have the handout somewhere with example problems, probably should dig it out). They even told us how to "evade" a test if you're not ready ("oh, sorry, no time -- I have another interview after this").

Xiaofan wrote: > That was not so long ago. I attended RPI (http://www.rpi.edu) for a > semester in Fall 2003. Even though I did not like Troy and > my supervisor and chose to quit my study, I think RPI is an > excellent university and the undergraduate program is really good. In 2003, I'd say DeVry was also top-notch, and even eight months ago the project fair was way better than what I saw last week. There were fewer projects, and only one was challenging enough, IMO. I think the problem is that the pool of people that go into engineering has shrunk tremendously. As has already been discussed, the education system lags the industry by a few years, so I think we're just on the side of the pendulum where demand for qualified engineers exceeds supply (until the education system catches up). > In the lab, there are some dual 25V power supplies. The first thing I > asked > them to do is to connect the power supply to get 30V. Half of the students > could not get it done. I was a good TA so after the course, they all knew > how to do that and got trained in soldering. With proper training, I think > they > were not that bad after all. I was in a similar situation: people were given a transformer (with a 110V plug), and were asked to determine the ratio. Most couldn't figure out that the plug was the primary. > That being said, I think the graduate program in US universities (top 100) > are all world class. I have nothing to compare it to, except itself some time ago.

Nate Duehr wrote: > [...]To a person, they've all also been > slightly over-confident, also -- but perhaps it's justified. They > all "knew" they were good. Have you ever met an engineering grad that wasn't overconfident? I think it's the schools' problem, they all tend to exaggerate the reality. It's part of the recruitment process, and also the "career development" courses just prior to graduation. > I've also worked with a number of MIT grads and without question > they're all very good too, but seem less interested overall in > "mundane" engineering -- if I had to think up a way to describe it. > They know their stuff, but tend to gravitate away from "normal" > problems as soon as they've shown someone else how to do the > engineering work to fix them. Not that this is "bad" in any way, but > definitely a different "feel" than the RPI guys. In what capacity have you worked with these guys?

James Newton wrote: [snip] >>> "During the development of a proprietary application in the workplace, > you >>> hit upon a unique way of solving a common programming problem which does >>> not >>> directly relate to the project. Will you A) publish the snippet B) Ask >>> your >>> boss if you can publish the snippet C) not mention the solution to >>> anyone >>> but use it again at this or other jobs in the future." >> >> Not enough information? >> > > What information would you want? I think the danger here is that the candidate will tell me what he thinks I want to hear (B). However, in most situations what is and isn't a part of the company's IP is clearly defined in the employment contract -- in order to be enforceable, the scope has to be sufficiently narrow. Hence, (A) may be appropriate.

>> "Given a system that fails consistently in actual >> operation but operates >> correctly as soon as it is attached to a test fixture, >> list some methods you >> might employ to find the problem." > >Make an artificial test fixture. > >A standard finger would make you rich. Well, my thought was to determine what the test fixture changes (voltage level, ripple, noise, applied signal levels, debug probe). But on the standard finger line, I remember reading in Electronics Australia, one of the 'serviceman who tells' monthly articles, a story that was related to the said serviceman who wrote the column, about a radio set in outback Australia somewhere, which had a problem. Service turns up in due course to fix problem, and finds strange furry item attached to aerial terminal. Enquiries of the family elicited that this was (in Russells words) a 'standard finger'. They had found that by putting a finger on the aerial terminal the signal level improved vastly, but nobody was going to sit there forever with finger on said terminal, so what was a suitable solution. Someone had the bright idea that a string of sausages (for the American readers, these would be English style sausages, I cannot remember your name for them) was meat, just like a finger, so a string of these was attached to the aerial terminal, and apparently 'operated' satisfactorily as a 'standard finger'! It was not clear from the article, if the current callout was due to deterioration of the 'standard finger' ...

> >For embedded software, how about one of these: > > > ... > >---- or ---- (this one would translate well to assembler, too.) > > > >int setbit (int word, int whichbit) > >{ > > return word | (1 << whichbit); /* Set the specified bit */ } > >int clearbit (int word, int whichbit) > >{ > > return word & (1 << whichbit); /* Clear the specified bit */ > >} > > I take it these should have || and &&. Not being a C > programmer, my syntax needs a lesson (or two). That would be interesting questions. For these functions: int foo1 (int x, int y ){ return x | (1 << y); } int foo2 (int x, int y ){ return x || (1 << y); } int foo3 (int x, int y ){ return x & (1 << y); } int foo4 (int x, int y ){ return x && (1 << y); } - explain in your own words what each function does - which ones would you want to have available in a library, and - how would you name those - which other functions would you want to complete your 'bit fiddeling' set of library functions, and - write those and give them appropriate names Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

>After the resume sort, I'm normally left with just a few candidates. >When I said "save time" I meant that the 15- or even 60-minute test >has the potential of saving weeks, or however long it would take to >realize that the candidate isn't fit for the job -- even though their >resume looked great, and they aced the interview. However rather than a written test, having a handful of suitable technical 'test type' questions within the interview may well be just as useful, and save both you and the candidate time, while potentially giving you more visual feedback. Questions I was asked in interview: - 1. Sketch an inverting amplifier - answer was an op-amp triangle and two resistors, cannot remember if I included the non-inverting input to ground. 2. why would you twist the wire going to a sensor. - answer so it acts as a balanced line and any noise gets equally into both wires and so cancels. 3. If a pulse is injected into a transmission line, and the far end is short circuit, what will the waveform look like at the transmitting end. - answer was sketch of straight forward voltage pulse. 4. If the above pulse is shorter than the transmission time of the above transmission line, what will the transmitting waveform look like - answer (the way the question was asked wasn't as clear as this, so I checked they were talking about a pulse shorter than the transit time) from the previous answer it will have a short pulse then after double the transit time an inverted version of the pulse - again sketched. The rapidity of an answer versus the amount of umming and ahing will possibly be a better indicator than a written test.

{Quote hidden}>-----Original Message----- >From: .....piclist-bouncesspam_OUTmit.edu [TakeThisOuTpiclist-bounces.....TakeThisOuTmit.edu] >On Behalf Of Alan B. Pearce >Sent: 22 October 2007 12:45 >To: Microcontroller discussion list - Public. >Subject: Re: [EE] Test for embedded developer candidate > > >>After the resume sort, I'm normally left with just a few candidates. >>When I said "save time" I meant that the 15- or even >60-minute test has >>the potential of saving weeks, or however long it would take >to realize >>that the candidate isn't fit for the job -- even though their resume >>looked great, and they aced the interview. > >However rather than a written test, having a handful of >suitable technical >'test type' questions within the interview may well be just as >useful, and >save both you and the candidate time, while potentially giving >you more >visual feedback. > >Questions I was asked in interview: - > >1. Sketch an inverting amplifier - answer was an op-amp >triangle and two >resistors, cannot remember if I included the non-inverting >input to ground. > >2. why would you twist the wire going to a sensor. - answer so >it acts as a >balanced line and any noise gets equally into both wires and >so cancels. That a good question, but IMO it would be better to ask this as "When would you twist the wires connected to a remote sensor, and why would you do this." i.e. When the sensor is connected to a balanced input, and to improve common mode rejection. Not all sensors will be used with balanced inputs, a singled ended input with a coaxial connection is not uncommon wioth many sensors. Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

On 10/22/07, Nate Duehr <TakeThisOuTnateKILLspamspamnatetech.com> wrote: > I would have to state that so far, all of the engineers I've worked > with over the last (just under) 20 years in my career who had RPI > degrees, have all been top-notch. To a person, they've all also been > slightly over-confident, also -- but perhaps it's justified. They > all "knew" they were good. They all also had a deep love of their > engineering (a passion for it, shall we say) and would help people > outside of work hours on just about anything. > > (Side-note: Olin's an RPI grad, I believe.) > > Whether or not I've seen a large enough "sample" of the RPI > population overall, is probably up for debate. I know the number of > RPI grads I've met isn't statistically significant! :-) > > It makes for an interesting side-question: What are the values and > teaching techniques at RPI that help differentiate the people that > come out of the program? I studied in RPI for only a semester and I was only sitting in three courses (two graduate level courses and one undergraduate course. BTW, I got three "A"s). So I think my opinion may not really count. Anyway, I can think of several reasons. 1. The professors are good. 2. The course load is quite heavy. 3. There is not much to do in Troy. With 1/2/3, the students will spend more time on study. Xiaofan

On Oct 20, 2007, at 12:32 AM, William Chops Westfield wrote: > Debugging, in both the HW and SW section. A "what's wrong with this > circuit/function?" > int checkinput() > { > unsigned char c; > c = getc(); /* getc returns assorted negative vals for > errors. */ > if (c < 0) { > return -1; /* But we just want a single error val. */ > } > return c; > } Since "c" is unsigned, (c < 0) is never true; you lose the value of negative return values of getc() (which presumably returns int, as per the comment) by assigning them to an unsigned char. (A good compiler will complain about the "if", and a picky compiler will complain about the assignment.) {Quote hidden}> > ---- or ---- (this one would translate well to assembler, too.) > > int setbit (int word, int whichbit) > { > return word | (1 << whichbit); /* Set the specified bit */ > } > int clearbit (int word, int whichbit) > { > return word & (1 << whichbit); /* Clear the specified bit */ > } clearbit() needs to have "word & ~(1<<whichbit)"; as written, it clears all the other bits. (setbit() is ok; it's just there for context.) I've made both of these mistakes in real programs, and seen lots of other people make them too. Perhaps they're too hard; they ARE the sort of bug that is hard to see unless you've seen them before, so maybe they only check experience... BillW

Not that it's overly important, but isn't 2+2 = 11 in base 3 and 10 in base 4? -n. On Oct 19, 2007, at 11:27 AM, Harold Hallikainen wrote: {Quote hidden}> >> wouter van ooijen <wouter <at> voti.nl> writes: >>> some more comments from a nitpicker... >> >> You know, there are more ways to fail a test than to pass it. >> Starting a >> fight >> with the tester on the basis of Svejk logic is one of the best ... >> just >> like >> asking what the sum of 2 + 2 is and expecting to pass when >> answering 4 >> (hint the >> correct answer is: there are three possible answers: 1 in base 3, >> 0 in >> base 4, >> and 4 in all other bases higher than 4 - > > For more about number bases, listen to Tom Lehrer's "New Math" at > http://curvebank.calstatela.edu/newmath/newmath.htm > > Harold > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com - Advertising > opportunities available! > --

Vitaliy wrote: >> I've also worked with a number of MIT grads and without question >> they're all very good too, but seem less interested overall in >> "mundane" engineering -- if I had to think up a way to describe it. >> They know their stuff, but tend to gravitate away from "normal" >> problems as soon as they've shown someone else how to do the >> engineering work to fix them. Not that this is "bad" in any way, but >> definitely a different "feel" than the RPI guys. > > In what capacity have you worked with these guys? As for the MIT grad(s), I'm a "support guy" and they're senior engineers on telecommunication systems at work. The MIT guys usually have left the production products long ago by the time I am supporting the product in the field, and they're usually working on "next generation" stuff that isn't even close to a release date. Development engineers. We usually have to pull them "back" to current product problems about once or maybe in a bad year, twice a year -- when something deep in the architecture they originally designed is acting up, looking for whatever the problem is. I've been doing the support role for long enough that I usually know when something is "deep" enough to have to get them to join us for a meeting/conference and/or troubleshooting session, and my boss and I often agree on that assessment... so it's not hard to "grab" them for a day or three. (Yeah, when you start recognizing a pattern of a long-term issue across multiple product lines and then realize exactly where the problem lies and that you need to drag the original design engineer back into the "problem" to explain it to the rest of the engineering staff and management... so it can be fixed in current products... you've been working in support for too long!) As for the RPI guys, that's all outside of work stuff. RF. (Amateur Radio) I got interested in the care and feeding of a whole bunch of FM repeater systems for a local ham radio club, which led to weak-signal VHF and up contesting and other RF-based toys, and really enjoy it. Most of the RPI guys I've met were via volunteering for various other Amateur Radio "leadership"* things, and talking about projects -- they've been great folks to work with on that kind of thing, and the professionalism of really knowing their knowledge-base in their chosen specialty (RF) is high. You know how it goes, you meet one person -- learn some things from them or work on a project, do some other things later on and ask them if they have any ideas on the project, and they point you to others... just your usual "networking" but in a more "techie" way than in a political or "get a job" type of thing. Playing with setting up the Ham gear to do various things, is a lot more fun than "real work". :-) Nate * "Leadership" in ham radio often just means that you were stupid enough and/or willing to show up for the meeting. (GRIN)

I saw the errors right away, but I didn't know I was supposed to shout out the answer. =] - Marcel On 10/22/07, Dario Greggio <.....adpm.toRemoveMEinwind.it> wrote: {Quote hidden}> William "Chops" Westfield wrote: > > > clearbit() needs to have "word & ~(1<<whichbit)"; as written, it > > clears all the other bits. (setbit() is ok; it's just there for > > context.) > > > > I've made both of these mistakes in real programs, and seen lots > > of other people make them too. Perhaps they're too hard; they > > ARE the sort of bug that is hard to see unless you've seen them > > before, so maybe they only check experience... > > In fact I missed it :-( > :-) > > -- > Ciao, Dario > -