|
If they are straight out of university, they are largely stuck with what the university teaches: Java in this case. That doesn't mean they CAN'T learn, it means they were taught Java.
So... can they make the jump? Depends on the person. Bring them in, give them a chance. Realize they have a steep learning curve and don't let them make production changes. Mentor them, code-review them, but allow them to learn.
|
|
|
|
|
|
Sorry but no, unless he has some side projects with C or C++ on Arduino.
|
|
|
|
|
That's for sure, if he/she only program in Java, then it would have a hard time with C++, but if he can learn another language and use several ones besides Java, hire him/her.
|
|
|
|
|
It will get hard, because Embedded C is pure C and a lot of bitshifting and memory access. And the Java is high end server stuff. If the guy is smart and willing he can and will learn it, but he will need its time and a lot of passion. But it will take time and maybe the guy isnt satisfied and leaves after some months.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I'm going to argue the other direction. A bit over a year ago I was drafted for an internal PIC32 embedded project despite my professional career having been in .net and other high level languages; with C++ being something I did and forgot over a decade ago in school.
It was a major shift; but I didn't have any major trouble picking it up. I only had two majorish problems that would've been managable if I'd had more than a month or two for a crash project. The first was the slow deployment process horking up a lot of my (especially early) time estimates. (The amount of time I spent coding was in line with what I was expecting; but the difference between being able to click run and stopping at a breakpoint a few seconds later and having to spend several minutes programming multiple chips first slowed everything down a lot.) The other was a combination of my not knowing how to read board schematics/translate data sheets into reality (and for most of the time not even having a viewer for the format the schematics were made in); and limited information flow with the person who designed boards and wrote the lowest level code about how the low level bits he was writing were intended to be used and where IO pin multiplexing meant that I couldn't use X and Y at the same time even if I wanted to.
I'd talk to the kid and make sure he understands what he's getting into. If he's expecting to have a bunch of huge libraries and to never worry about memory use I'd be worried; but as long as he understands what he's getting into and appears able to learn I don't think it should be a major concern. It's not like a kid right out of school is going to be able to work in whatever they thought they were learning without a non-trivial amount of ramp time after all.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I'll agree with the others who say it depends. I got a BSEE back in 1994. The place I was working at the time was a C/Assembly shop doing embedded programming. Our program at my school had 1 semester of 6502 Assembly, and a semester of FORTRAN. No requirement for C. I learned how to do C on the fly, and actually got to the point where I could write faster, smaller, and more efficient C code than most of my colleagues' assembly code. I was writing ISRs using C when that was frowned upon. I did that because it was easier to debug, and then just tuned the C to output the assembly I wanted.
We had a mix of people. Some were EEs like me, some had CS degrees. We basically split the work up so that the EEs were doing the board level stuff, and the CS people were doing the application level stuff. This was layered so that we could do a lot of the application level stuff on the PC first and debugged there.
The personality of the person I think has a lot more to do with how good or bad they are as a developer. One of the best developers I have worked with didn't even have an associates degree in anything, just a high school diploma. One of the worst ones I worked with had a masters degree in EE.
I'd say to talk to the person yourself, and you can tell if they are someone who likes to learn or not.
|
|
|
|
|
You guys are great. I was going to post this over in the Java forum, but the first 12 posts were clearly homework related.
I do agree that SOME people could make the jump. It's funny, one of my programming questions to candidates is: What's the largest unsigned value you can put in a byte? I'll usually clarify it by saying, "You know, 8 bits...". If they have a clue they know I'm setting a trap  . So we agree that the largest value is 255. Good. Now, what's the largest value you can put in a word - 16 bits? And if they have no concept, they'll say ... 510.
Anyway, I like the idea to try them out, sort of a no-fault clause.
I truly appreciate all of the feedback.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
size of a word in c is processor dependant. if the size of a word is 32 bits the largest value would be 0xFFFFFFFF. If it is 64bit it would be 0xFFFFFFFFFFFFFFFF... at least if the word was unsigned... else the largest value would we 0x7FFFFFFF and 0x7FFFFFFFFFFFFFFF.
Can I get the job?
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
lol, I disagree. You CS types f'd it all up. point taken, but to avoid confusion, we now have word, long word, long long word, etc.
but specifically I would even mention the # of bits I was talking about, just to see if they have a clue for binary. I want to know what they see in their head mentally. Interestingly, if you put that you know C, you better know something about this... otherwise you lost me. Have had people with MS in computer science.
fwiw, the company I consult for is actively hiring embedded or close to embedded. If you like or think you like the Atlanta area, contact me off line.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Yes, no, perhaps ...
It largely depends on the person. I used to work with a developer who could switch (self-taught) to almost any language and be quite proficient and knowledgable within weeks. I have also worked with people who could not program their way out of a wet paper bag. So you need to look much more closely at the person, and their skill and ability, not just what they have worked on in the past. Face to face interviews can usually weed out the ones who think they can blag it*.
*Although TBH, that's what I got away with for much of my career.
|
|
|
|
|
This is true.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Biggest concern: Java has memory management. C and C++ do not, you do that on your own. If the Java developer has never had to be concerned with memory management they will create a program that will leak memory and program will run for some time then it will fail, especially in embedded world. I came from assembly, C / C++. Then I learned Java and thought, wow that is nice, memory is managed for me. Going from Java to system level programming language like C will be a big learning curve.
|
|
|
|
|
Most likely NO!
And not because of not be able to program, but because he will soon be fed up with how hard some things must be done with c++.
For example, we had to do a C++ embedded project after more than 10 years of C#/.NET; after a thorough analyses of the c++ project and how it was supposed to be implemented, I ended up implementing first a full garbage collector.
Even the most careful programmer that comes from a garbage collected environment, that never in his life used a delete obj; statement will forget to free the memory even months after the start with c++.
|
|
|
|
|
|
Fresh out of college is tough. His/her depth is probably not nearly what they believe it to be.
If they really want to learn C/C++ and you have a run at them about embedded. Then maybe.
You could make it happen. But this would be a heavily mentored situation.
I would make them read a boat load of code, learn to build and test the systems you are working on.
They would have to read the libraries you leverage, and build a spreadsheet of .o file sizes, and impact on the executable sizes.
Then, they would be on small bug fix tasks (identify, verify, repair, review). The review is a review of their entire thought process, and a code review. Preferably DAILY of all code they propose to change. Until they are writing better code. Then they can start with small changes/enhancements, but I would review EVERY line of code for many many weeks.
If they are off by 10 degrees and you are not reviewing. In 9 months, they are going to be breaking everything. If you can keep them to 1 degree off, and constantly monitor, you should both be happy.
The great part of this, is that SOMETIMES when you go through this with management, they realize why it costs more to hire the people with the right skills up front.
But I don't mind investing in good people. Doing this has led to near lifetime relationships with these guys for me. They appreciate getting up to speed at an accelerated rate.
HTH
|
|
|
|
|
It's not just about language - does the candidate have an appropriate knowledge of and inclination towards low-level programming, as you're likely to see in small embedded systems? Bits, bytes, addresses, malloc and free... Realising there's no garbage collector to handle memory for them - maybe no heap allocation at all! Tight timing requirements, low latency responses... All of that is kind of non-Java... Just saying...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I'm inclined to also say no, but really what that means in this case is that their resume would not be at the top of the stack.
If they've only ever done Java, then I would expect a serious deficiency in their knowledge of memory management/garbage collection, since they're used to having that handled by the VM. Java also doesn't have pointers, so expect that to be another pain point.
That said, my company does hire a lot of kids fresh out of school. We start them with a 3 month paid internship (roughly $10/hour). If they're able to get up to speed in that time (and we have enough work), we offer them a full position. So far it's worked out pretty well. Out of 20-25 interns over that last 4 years there's only been one that we had to let go due to incompetence. The rest we either hired, or they got positions at other companies in our industry.
|
|
|
|
|
If it's a guy straight out of college, then he probably can't write in C++ OR Java, but just thinks very highly of himself. It's not like he's disabled or anything. If you have time to train him up, Java isn't unrecoverably dissimilar to C++. But it will be slow going for about two years until he has basic mastery of C++. He could be productive sooner if the project is not too demanding. (Without meaning to be insulting, if EEs do the coding now, it's probably not too demanding). But he won't be able to just sit down and start cranking out code the first day. You said you were agile, and hinted that to you agile means cronically in a rush. Retreading an enterprise java guy doesn't seem like what you want to do in a rush.
The mindset for embedded C++ is all about optimization and performance, templates and inlining and profiling. The mindset for enterprise Java is all about memorizing design patterns and writing elaborate factory methods. Learning the difference in syntax is easy. Unlearning the enterprise mindset and acquiring the embedded mindset is probably harder.
|
|
|
|
|
(Without meaning to be insulting, if EEs do the coding now, it's probably not too demanding).
Oh, hell, maybe soapbox? 
Without taking offense, I understand exactly where you are coming from. I work with the one CS guy in our group. He's amazing. He can couple systems together so fast. 
I like the other idea of bringing people in as interns, I'd pay them a bit more though. The issue is that you have to have the manpower of being able to support said interns. That part is a management decision. Right now, I'm dealing with code written by said whiz kid that has no real mapping to the problem domain. So, sometimes a CS can cause issues
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Microsoft missed the shift to mobile because it was focused on the PC, Microsoft CEO Satya Nadella said in an interview with ZDNet.
Is this also called a blunder?
A small mistake here is that this is possibly "Insider News" stuff 
modified 15-Jul-15 6:19am.
|
|
|
|
|
|
objection
item -> object
atom -> ion
|
|
|
|
|
well done, you are up tomorrow.
|
|
|
|
|
Damn. There goes my evening... figuring out a clue for tomorrow 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
