San Diego Housing Bubble News and Analysis

Has your colleague verified that the overseas candidates actually have Android experience? That is, beyond the recruiter's assurances?

And are you sure you're not putting too much of a premium on Android-specific knowledge? I mean, there's a pretty high barrier to entry for iPhone apps (high-end Mac, Objective-C and XCode, $99 for the SDK, etc.) but Android doesn't require much beyond knowledge of the general Java/Eclipse suite. That sounds more like 4-5 weeks max, not 4-5 months.

And no, I've never done anything for the iPhone, but my employer thinks I should learn how to, on my own dime and on my own time. And that's how I'd respond to your assertion that American developers aren't picking up new skill sets -- most of us are scrambling just to meet our current employers' demands for new skills in an age of downsizing and "reorganization."

FLU - I can't say I'm familiar with the mobile app space, but I agree with the other poster that a good mobie app developer should pick up on device-specific details in a few weeks. A great one, in a couple weeks.

I don't know if there is such a thing as a class for teaching developers the ropes for the Google device, but that would be a great incentive for any applicants.

I'd suggest finding a great programmer in a space that is as close to your space as possible and wrap Google training, if there is such a thing, into the compensation package.

Or, hire a contractor that is working for Google to teach your new hires what they need to know as a side job. We contractors are whores. We'll do anything for a side job.

I know a gal who has been programming for many years in many spaces. I have never worked with her, but she seems to be very diverse. Rattled off lots of languages she worked in. Her husband is an independent Mac developer and now has several iPhone apps. I'm sure he could offer his expertise as well. She is looking for work and she doesn't strike me as greedy. Drop me a personal message with your email and we'll talk.

FLU, I agree with the last 2 poster. Any good developer worth your time can pick up a new platform easily if they've already worked in the mobile app arena before. I picked up dumb phone platforms, BREW and WinMo on the job and still able to churn out new apps w/in 6-9 months. This is not your everyday isolated apps either, we're talking about apps for OEM that do file management or camera/camcorder.

Android is also quite new, so you can't expect the applicant pool to be that big. If you want top talents, most of them already have a job and were not laid off, you have to pay the premium for it. Android seems to be a hot space right now too, so those who have Android experience probably wouldn't have too much difficulty finding a job.

I've always been pretty much a middleware and enterprise web guy. I got thrown into some E2E applications that were talking to mobile devices (J2ME) a few years ago and I picked it up pretty quickly.

The reason that I haven't done any iphone or android work? I'm busy earning a living and my work doesn't appear to be slowing down anytime soon.

Don't get me wrong, I'm always learning a few new things here and there (I read alot) but going full bore into doing phone development on a new platform requires an investment in equipment (you need at least one phone to develop to) and quite a bit of time.

And, frankly, I'd rather do the server side piece in a smartphone app than the client UI anyways ;-)

In my personal experiece, it's been challenging to find truly talented developers for some time now and I don't expect that the larger candidate pool that exists as a result of layoffs has done much to improve upon that.

I'm certain I'd be able to help you, but I'd also need to understand your needs more completely. To be clear, I'm a developer and not a recruiter. Feel free to PM me if you prefer.

BTW, there are some weird things with Android and the G1 that you don't discover when you are on the emulator but cause great pains when you deploy to the real phone...they've bit a few of my colleagues :-0

Like, your app starts and you show a login page and everything looks fine. Using the emulator, you enter your credentials with the keyboard. You don't realize that on the real phone you have to slide open the keyboard and the screen rotates..now your nice UI not so nice anymore...funny stuff.

It's been that way for years in SD. As recently as 2005 I was interviewing people and would get flooded with resumes. 90% of them couldn't pass a basic phone screen dealing with some very basic java, web development and network programming questions that virtually any developer with more than 3 years of experience in the enterprise development domain should be able to answer. All of them thought they were rockstars...

And, btw, I vetted the phone screen with some of my colleagues who are truly good senior developers and none of them had a problem with the questions.

It's like you've heard in one way or the other, the candidate pool you are choosing from when you are trying to fill an opening aren't the cream of the crop. Those people already have jobs or, if they find themselves out of work, quickly find new ones.

A real handset, er phone, is nice at some point, but the majority of your work can (and should) be done with an emulator.

[edit]Never mind. Just read your follow-up post on emulators, and yeah, a real phone is key at some point.[/edit]

I did quite a bit of work on sony ericsson handsets with J2ME...and you only found out about the device idiosyncrasies when you put the phone on the actual device; the emulators would run the app fine.

I'm talking screen resolution, UI widget placement, color, memory...everything looks slightly different when it is on an actual phone. A real device has to be part of your development loop because if you wait until you are about to release to just 'check it out on a real phone' it will be the last time you ever make that decision ;-)

Not to mention that some phone's have firmware bugs (this was very common in the J2ME space where each phone would have a hand rolled JRE) that you'd never find on the emulator..only when your app was running in QA...

One more positive DISincentive to picking up new stuff on the side ... most employers don't count your knowledge as "real" unless it's been used on "commercial" projects.

Therefore (a) there's no clear reward for picking up new skills and (b) the temptation exists to load down one's current projects with irrelevant and sometimes toxic technologies just to add a few more buzzwords to one's resume.

Not to mention if you actually develop apps that are extremely dependent on hardware, such as the camera or the file system. You can do you basic development on the emulator, but it won't get you very far. Every camera chip is different, good lucky trying to find emulator for that. Also, your PC is a lot faster than any phones out there and the file system on the phone is much less optimized than the PC. So, everything might work fine on your PC, but when you put it on the phone, you'll find out quickly that reading a list of 1000s files from the EFS would crash the phone. That alone would change how your UI would look if you designed your UI around the assumption that the phone can queries for 1000s of files from the EFS easily. There are many more examples like these that make you very weary of developing purely on an emulator for a prolong period of time w/out a device. Emulator definitely have its place, but it can never replace a real device for a long period of time. Even though Nokia have the best emulator out of all the OEM (can't speak for Apple), there were plenty of idiosyncrasies between phone and emulator that noobs would get told, when they said "but it works on the emulator", that "we sell phones and not emulator", so always check your cold on a device before check in.

The deal is, coincidently we both need folks who can do things (yesterday)...Not someone who is going to screw around for the next 4-5 months "figuring things out from scratch"....Perhaps we're both being harsh, but we're like dude, if you really want to do this, couldn't you have possibly tried to learn this during the past 1-2 years when you already thought your existing skillset needed to be expanded. Why are you going to do this on our dime?

That's what your company gets for not hiring the best 2-3 software and hardware engineers right out of college every year and then helping them grow in a rewarding career. Had your company been doing this all along you would have a rich, diverse staff of software and hardware engineers able to tackle any challenge.

That's actually the way things used to work until the MBAs took over. As soon as that chain of new talent coming in was broken, all was lost. The older high-paid guys got laid off as their work was sent overseas, and a lot of the kids entering college realized that engineering was a sucker's game and all went for law, medicine, or biochem instead. Now those MBA-run shops are screwed, always trying to find that one engineer that has every single buzzword of the day on his resume and bitching on websites like this one that they can't find one and that all American engineers are lazy and don't want to learn new stuff.

And as another poster here pointed out, no employer will consider experience done at home in a hobby as real experience. They want you to have done exactly the same thing that they are doing, never mind the fact that that implies that they aren't doing anything new. But of course most MBAs can't think that far ahead...

But yes, your last line is right on the money. Try to get your company hiring a couple of sharp grads every year, take care of them and allow them to grow and your company will be in good shape down the road. But then again what company thinks farther ahead than the next quarter anymore?

Okay, let's clarify a few things about emulators, the first of which is any phone that's worth developing for has an emulator that you can be very productive with. If it doesn't, you better build one for yourself. (and, btw, flu, a developer capable of such would best fill your needs). An emulator is at least capable of getting you productive for the platform (which is also the question at hand). If you were doing production code, would you want to get things onto a real phone, you bet.

With regard to hardware dependencies, it all depends if you're writing driver/API code. If you're developing an app on top of that (which most folks are), you can make a ton of progress with an emulator. And, in many cases, you better be if the hardware implementation doesn't exist yet. If, instead, you're the driver/API guy, you still have to consider the emulator, just from a different perspective.

Finally, and this last bit is important, the best developers won't make poor assumptions based on how things work in an emulated environment. Rather, their assumptions are based on their knowledge and experience with embedded platforms that, while closer to desktops than ever, still have important considerations regarding resource limitations. That is, folks who just might recall what it was like to deal with a megabyte of memory and slow storage mediums are much less likely to embark down a dead end road. This notion doesn't apply, of course, to things like pixel madness in bad emulators, but does apply to things like, well, reading every damn file on a device when you mean to display information about eight or so (or indexed information is required or whatever). Heck, the bigger mistake people make here is not considering scale in the first place. E.g. it works on the emulator, it works on the phone. It just works like crap when somebody who's thinking puts 5000 contacts in it.

sdcellar, you crack me up, thanks for the good laugh. I guess most of the major OEM phone manufacturers don't make phones that's worth developing for.

Not apps, my friend, not apps. And that includes the built-in apps as well.

It'll pay the bills, but the iPhone and Blackberry pretty much ate everybody else's lunch. Most apps on other phones are just noise. If you're lucky, you're working on something that competes with those (Palm Pre comes to mind). If not, you better send your resume over to flu.

Ah yes the age old lament of the employer who doesn't want to pay for pre-trained talent and doesn't want to pay for training. I know it well.

As to talent not being available, it always is at the right price. It just may be that all those lean years in IT are finally paying off. As to foreign devs who have these cutting edge skills you seek, good luck.

Josh

CONCHO 10:20 am-- Right on!!

I keep a couple of searches out on Monster.com going, just to keep some low-level antennae out on the job market, and I am amazed at the picky, specific/exotic, unique-to-their-company knowledge that many job posters are looking for.

"Oh, we are looking for a mechanical engineer with 6 years experience in designing left-handed vreeblefetzers in Pro/Engineer, who also has at least 3 years of experience in designing parts for GE retroencabulators..." etc etc for 3 paragraphs. Obviously I am not qualified for the job because obviously the guy who used to do the job just retired and they are looking to replace him... EXACTLY.

In my current work I do both ME and some CS-type work, depending on the assignment, but this work is heavily flavored by the my-company-specific nature of the expertise I have to use. (Printer-design technology, in-house CAD parts database and standards, etc). I don't care how good you are, if you are migrating to another company which is operating in even a slightly different technological area you will have to do some training up in the in-house expertise.

Not to say all Monster postings are this unreasonable, but it is pretty rare for me to see a posting where they ask for Basic Skill Set A and say "we will train you into our company-specific skills."

But I am told most job postings are written by script kiddies in Personnel with no clue about the actual job anyway.

Yep, in my experience, the most talented folks have pretty diverse technical backgrounds and can pretty much work on anything. Creating a pigeon hole and then lookly soley for those pigeons is fairly brain dead thinking in my estimation.

This isn't to say that a guy who has a narrow skillset on his resume doesn't have the capability to work on things outside of that, just that the hiring team needs to work that much harder to make the determination if he/she will be able to excel.

Not in the tech world, so cant comment specifically to the OP and why he has trouble finding the tallent he needs. But one line really got me.

"Why are you going to do this on our dime?"

Have you not allocated any dimes to continuing eduction, personal training, or something similar? None? Really? You want someone who can walk into a company, in what I am understanding is a very limited/new/hot/diverse market, and do everything perfectly from day one? Seriously? I am not a tech/computer guy, but I doubt you'll ever find that.

Sounds more like a budgeting/expecations problem than a talent problem. Maybe your job is differnt FLU, but just about any other one I have ever heard of expects a learning curve for new hires.

Hahah, I thought it couldn't get any better, but apparently, it could and did. Thanks for the laugh. I guess all MSFT employee should be updating their resume as well, since APPL is eating MSFT's lunch too. My favorite quote of all "Most apps on other phones are just noise."

Ahh, now we're talking about a different kind of bubble.

Enjoy.

Most enterprise mobile applications are running on windows mobile platforms...not the iphone or the palm. There's alot of work out there in this space.

and AN, maybe you could come back with something sustantive, like "Most apps on the iPhone are just noise."

In that case, you might have something, seeing that recent surveys indicate that only 15,000 out of over 65,000 apps available have been downloaded at all.

Then, I could at least come back with, yeah, but if you look at the built-in apps, Apple's done a better job of making each one of them useful. And then, you could say... well, you get the idea.

Which brings me back to flu and just a reminder that if you think it's hard to find good engineers, the really hard part is coming up with a product that will appeal to consumers. You've got a great idea, right?

I completely agree with this. Also, the conclusion was drawn too fast on US/foreign candidate quality. For one thing, if you pay them US wages, it will be several times their local wages. I'm sure you can persuade some people to join the company if you also pay several times the local wages here. Next, I don't think you can rely on recruit's recommendation when it comes to hiring foreign candidates, just like you don't rely on a buyer agent's recommendation on the house value. It is said that s many as one-third of all resume writers exaggerate their accomplishments, while up to 10 percent "seriously misrepresent" their background or work histories.

sdcellar, I'll pass on debating with you. It never gets anywhere. You seem to do a fine job debating with yourself though, so I'll leave it to you.

FLU, there's a price for every everyone. If you pay them enough, they'll jump off the Google/QCOM/etc ship.

I dont understand, you are going to hire overseas employees, but not have the headaches of managing overseas? So who does the managing? Is that outsourced too? Is that cost included in your estimation of 'comparable US wages'. I dont know the industry, but that seems kinda contradictory to have overseas employees without overseas mangment issues, unless someone else is doing the managing for you.

Well, my colleague's already have a customer. telco's specifically...And I'm piggy-backing off of him to build crap on top of crap :). I don't sell directly to consumers. Out of all things, I'm an enabler, not a specific app provider. There is no significant money to be made on individual apps, particularly iphone apps.

As far as the headache of managing a 16.5 hr timezone difference tell me about it. But I already got do deal with a buddy that isn't even here in S.D.

So let me ask is almost $100k/year such a shabby deal for someone with 6-8 years of relevant experience? I guess if firemen are making $150k+ pension, relatively, speaking yes? All said and done, that is how much it's looking like for a good guy from Bangalore factoring in overhead.

Oh well, gotta pay to play. Anyway, found two candidates today. One from Texas.

Good labor isn't cheap, and cheap labor isn't good.

I'm sure if you paid enough, one or more of those applicants from google or qualcomm would jump ship. That's the way the employment market should work IMO.

The deal is, coincidently we both need folks who can do things (yesterday)...Not someone who is going to screw around for the next 4-5 months "figuring things out from scratch"....Perhaps we're both being harsh, but we're like dude, if you really want to do this, couldn't you have possibly tried to learn this during the past 1-2 years when you already thought your existing skillset needed to be expanded. Why are you going to do this on our dime?

CONCHO and CricketOnTheHearth largely covered this.
Basically the world of apps on a cell phone is minuscule compared to the technical space occupied by all IT type work. It is not possible to 'train' specifically for all the types of work out there and for all proprietary systems. There will always be ramp up times on projects. Best approach would be to look for similarity in skills (cell platform would be similar to many forms of embedded, and Java engines can run on many embedded platforms, particularly those running a multitasking OS/RTOS). Outside of the programming languages, you are primarily dealing with APIs, which are really easy for a good person to pick up.

Another approach if you are uncertain about a person's qualities, is to hire them as a contract worker and convert to full time should they demonstrate the needed skill set and aptitude for the job.