Fog Creek Software
Discussion Board




actively hiring

Hi all,
Given the state of the economy,does anybody know if any companies are actually hiring developers?

concerned
Tuesday, February 04, 2003

Having been laidoff almost 4 months ago, I can tell you about the Chicago market.

THere are companies hiring, but they are all being extremely specific in their requirements, they are taking a long time in looking over resumes, and they don't hire if they don't find someone who meets their long list of requirements.

Also, I once told a recruiter I know/trust that I'd take less money if I could get a position that'd help strengthen my Java skills (I'm mainly C/C++). She chuckled and said that there were plently of Java people willing to take less just to get a job.

jeff
Tuesday, February 04, 2003

In the DC area there are companies advertizing on the radio that they are hiring engineers.  They are all big govenment contractors and mostly require security clearances.  Overall things are still very bad, but there are a few nitches with some hiring.  At this point I am getting nervous about my own situation.  I am still employed, but my employer will be losing some positions in the near future and there hasn't been much new coming in.

mackinac
Tuesday, February 04, 2003

Seattle's still tough.

barbarosa
Tuesday, February 04, 2003

I'm in Silicon Valley, and things are really bad here. I've been laid off 2 month ago, no job offers and can't even get an interview, so far. I have almost 20 years of expericnce, C++, Java, Perl, OOD/OOP, UML, etc.

Just for the contrast -- I came here in 1996, sent a dozen of resumes the same day, got an interview in 3 days and a decent offer in a week.

raindog
Tuesday, February 04, 2003

I work for a Bay-area company, we have been looking to fill one or two more senior developer spots in our group for the last 6 months to no avail.  The quality and/or experience of applicants have been disappointing.

Realtime client-side financial software, MFC, C++, etc... Seems like most financial programmers are on the East Coast.  Daytrading experience a big big plus.

Would love to add someone who cares about software quality and usability.

cheapo
Tuesday, February 04, 2003

Yes, I know, tere's the otehr side of the coin... Because so many programmers are unimployed here (10-15%, AFAIK), the signal-to-noice ratio is pretty low. I have a friend who are trying to find right candidate, but with an average of 100 resumes per day they just physically not able to review all candidates. And they are still looking.

Another recent anecdote: a friend of mine posted a QA/developer position on one of the big job boards, went for lunch, got back in 1.5 hours and found 1200 resumes in his mailbox.

So, yes, it's very difficult time for both employers and unimployed.

raindog
Tuesday, February 04, 2003

Microsoft is hiring.

Prakash S
Tuesday, February 04, 2003

Microsoft is always hiring.

It's just damn tricky to get in.

Pavel Levin
Tuesday, February 04, 2003

And, according to Microsoft's job site, most of the openings they want to fill are in Sales.

jeff
Tuesday, February 04, 2003

yeah, it is tricky to get in, but they are hiring.

Prakash S
Tuesday, February 04, 2003

Sounds like right now it is tricky to get in EVERYWHERE! 1200 resumes!

dmooney
Wednesday, February 05, 2003

I've been looking for an average C/C++ developer for some months now. Most of the people rate themselves 8/10 or 9/10 in C and C++. Before the actual interview I usually ask a couple of "smoke questions" to determine the candidate's knowledge level.

1) int *p = 0; delete p; What's going to happen?
2) int *p = NULL; free(p); What's going to happen?
3) What's the difference between <stdio.h> and <cstdio>?
...

Maybe 10% of people get it right ...

GK
Wednesday, February 05, 2003

1) & 2) If you have a standards conforming compiler, nothing happens (it's legal to pass 0/NULL to free/delete, they just don't do anything with them).

3) <cstdio> is basically <stdio.h> with everything put in the std namespace.

If you job is in Chicago, I'd like to talk with you...

jeff
Wednesday, February 05, 2003

yeah GK, Null is basically  defined as (void*)0, and it's okay to delete Null according to the standards.

Mind calling me for an interview GK? I am pretty much open to relocation anywhere.

concerned
Wednesday, February 05, 2003

>>> I've been looking for an average C/C++ developer for some months now. <<<

It is hard to believe that you haven't found a single qualified applicant in several months.  Even if you've eliminated 90% with your smoke test, that still leaves a large pool of applicants.

I would be interested in hearing what the size of your total applicant pool had been over those months and how it is that the number of acceptable applicants has been zero.

mackinac
Wednesday, February 05, 2003

I'm gonna raise the BS flag on GK.  That 'test' does'nt appear to be a very 'defining' piece of material.

BS
Wednesday, February 05, 2003

I think most programmers are now getting offers for less than half what they use to make. In my case, doing boring work was great for alot of $$$ but for peanuts it's a deadend. I am in grad school and moving on along with alot of the smarter people.

Dumas
Wednesday, February 05, 2003

Hiring is not as trivial as it seems. When you’re looking for someone who is required to write independently solid code, little things matter. Yes, they do. We all know what happens if people have buffer overflows in their code. Main cause for buffer overflows – “I don’t have enough time to write another fancy if-statement, because nobody will ever pass me data which exceeds my current buffer size”.

Is person who doesn’t know what happens if you delete NULL-pointer a bad programmer? Definitely not. But if you have \emph{n} resumes and \emph{n} is not small number then you have to do some filtering on the data you have. Will this blow some good candidates away? Yes, it’ll. Will it make sure with higher probability that you won’t be wasting your interview time? IMO it’ll.

When it comes to the people who passed the initial screening. Can they explain what’s the difference between SEH and C++ SEH? Do they know when it’s appropriate to use binary tree and when not? Can they explain how to implement semaphore and can they code it? And so on.

Let’s take a sample interview question: “Implement a function which reverses the string.” Simple, right. Everyone can do this in 5 minutes, just two pointers, swap the characters and we’re done. But will the candidate ask: Are we dealing with ANSI or Unicode strings? What's the typical size for the string which will be passed to this function (maybe all strings will be four characters long)? Does the function have to be thread-safe? What should I do in case of invalid parameters: assert, raise an exception, log message somewhere? Etc. etc. And of course the real interview questions are more complicated and raise more unknowns which need to be clarified.

Yes, the bar is high. Bugs cost lots of money. I’m not even referring to differences in productivity between highly competent professional and not so competent person. DeMarco, McConnell, and other classics have written enough about why it’s important to hire good people.

GK
Wednesday, February 05, 2003

Which does raise the question about why everyone is so interested in hiring cheap people.

Seriously -- I keep seeing roles I'm perfectly qualified for advertised week in and week out. They pay 3/4 to 1/2 of what I'm currently on.

I know other really top notch C++ developers. They're earning the same figure.

It's a market where hundreds of people send a CV for every job. And yet I turned up to several interviews and was the only person they saw who could do templates - and they said as much, but price was still their sticking point. They won't pay enough to get me to move.

They want the best, they get hundreds of CVs and still can't hire anyone and no-one thinks that price is still the issue: and it is.

Katie Lucas
Thursday, February 06, 2003

Jeff and 'concerned'

I think your answers to GK's questions are wrong. While it is fine to pass zero (or NULL) to delete, which will ignore it, I believe that 'free' will treat zero like any other pointer to memory that was not allocated with 'malloc'. The results will be undefined, but probably some sort of memory corruption.

David Clayworth
Thursday, February 06, 2003

>>I believe that 'free' will treat zero like any other pointer to memory that was not allocated with 'malloc'.

Nope, Standard (i.e. ANSI) C allows you to pass NULL (or 0 - same thing) to free and it works 'correctly' with it - it doesn;t do anything.

There are several reasons the ANSI C groups did this. First, malloc(0) can return NULL, and it should be proper to do free(malloc(<variable>)) - even when <variable> is zero.

Also, it makes it easier for the programming practice of setting a free()'d variable to NULL and then not having to worry about 'double frees' and you also don't have to put an 'if...NULL' guard at every free().

jeff
Thursday, February 06, 2003

GK >>> Hiring is not as trivial as it seems. <<<

I have only a little experience with the hiring process from the employer side.  It has never seemed trivial, but then never as complicated as it is for you.

>>> Will this blow some good candidates away? Yes, it’ll. Will it make sure with higher probability that you won’t be wasting your interview time? <<<

If it has taken you months and you still haven't found  someone, it sounds like you are wasting time anyway.

>>> Yes, the bar is high. <<<

High?  Wow, definitely.  I have checked out the Construx web site, Steve McConnel;s company and find that I easily make their 95 percentile.  But I won't even try at your company.  Sounds like you are going for 99 percentile or better.

How many people of this caliber do you have working for you now and how did you get them? 

mackinac
Thursday, February 06, 2003

Jeff

Going to concede to you on that one. I thought the standard said results were undefined. I checked several reference sites: some (e.g. Novell ) said that passing NULL would have no effect, others  (e.g. ACM ) said only that a value not previously allocated would cause undefined results. I can imagine ignoring NULL would be a sensible improvement that most library writers would make, and if the standard says the results are undefined, that would still be standard conforming. Since I don't actually have a copy of the standard I don't know any more.

David Clayworth
Thursday, February 06, 2003

>>...a value not previously allocated would cause undefined results

Yep, freeing any random integer *would* cause undefined results. NULL is a special case - according to the ANSI standard (for both C & C++), malloc/new cannot allocate an actual memory block starting at 0 (since NULL == 0).

The standard does guarantee that freeing/deleting NULL is a valid/defined operation.

jeff
Thursday, February 06, 2003

1) int *p = 0; delete p; What's going to happen?
2) int *p = NULL; free(p); What's going to happen?
3) What's the difference between <stdio.h> and <cstdio>?


This is idiotic stuff. Read the Joel article on hiring. Buy a clue. Stop embarrassing yourself.

Geeze.

The Anti-Bella
Thursday, February 06, 2003

I've been working, after I graduated, since July 1999 (3 1/2 years).  The last 2 years I've been using C++ in a Windows environment, Embedded C++ in a PocketPC environment.  For one project I used C++ in a Palm environment, one other project the main language was Visual Basic in a Windows/Tablet PC environment.

I would consider myself a pretty good programmer.  My friend/co-worker has referred to me as a programmer that writes "bug free code".  I think that I'm a good programmer because I am very, very good at debugging (one of the more importan skill IMHO) and I'm very meticulous.  VERY meticulous when I code.  I can't repeat that enough.  That's why I feel I have a low ratio of bugs-to-code written.

Now that being said...

maybe I don't know enough details of the position that GK is hiring for, but I saw this question he asks:

"3) What's the difference between <stdio.h> and <cstdio>"

and all I can say to myself is ... I have never used or heard of <cstdio>.  Even though I use C++ pretty much every day.  But I'm also in a Windows Environment.  Also, am I even using <stdio.h> often (I've heard/used this one before)?  I'm sure in some of the MFC libraries that I use, that file is declared and used, but those details are hidden from me.  Most of the time I'm using some MFC abstraction.

That's why interviews like this, where there is some pre-conceived notion that every single C++ programmer has used something like <cstdio> scare the poo out of me. :)  But does that make me a bad programmer?  How long would it take me to use and understand <cstdio>?  Not long.  It's just another library.  You look up the functions in that file and figure out how to use them.

I think about how I've interviewed candidates in the past, and I think about how this guy is interviewing people, and I wonder if it would be better for an interview to have more of:

a) code that's already sitting there on a computer that the interview candidate must debug.
or
b) questions like 1,2,3 that could be easily looked up in a 5 minute googling experience.

I might not know something off the top of my head ... well, I knew that you could free/delete NULL ... but sometimes I'm un-sure or maybe not even un-sure, it's just that I'm so meticulous that I double-check while coding (I'm always double-checking until something is fully committed -- you know, 6 months might pass before I try to free/delete NULL again).  And I think that's what is important!!!

Maybe I don't know it off the top of my head, but while I am coding, I look these things up.  If I know that NULL could possibly get free'd/deleted while writing a function or something, I'm going to go to google and look up what happens if I do something like this.  It seems to me that most interview sessions don't test for the fact that I would look this stuff up.  How can one test - or as a candidate, how can one show that maybe if I didn't know it off the top of my head OR was "un-sure",  I still would have looked this up and I wouldn't introduce dumb bugs into the code.

This is where maybe pre-written code that the candidate has to debug comes into play.  Leave me alone in a room for an hour and let me go to town on some code (just make sure I have access to google!)

==

Later GK brings up this, "“Implement a function which reverses the string.” Simple, right...."  And then gets into a long explanation of what he's really looking for.  See, the thing is, I've asked questions similar to this.  And what I was looking for was to see if they WOULD use two pointers.  That was what I was looking for!  You know, some people will come in, declare another array, and use this temp array to reverse the string.

So if I was ever asked this question on an interview, until today when I read what GK was looking for, I would have been trying to show you that yes...I do know how to use pointers.  Because being on the other side of it, that's what I was looking for.  I guess it was dumb to assume things or not "think outside the box" or something...but I don't know, I've only interviewed at so many places in my life.

The thing that kills me is...as shown by some of the projects I worked on...I do know what a Unicode string is (all strings in PocketPC code are unicode)...and I know there is a difference between that and an ANSI string.  Of course, it's not often (because of the environment) that I have to reverse these strings myself.  Usually I just need to make sure that I put _T(" ... ") around my strings!  So maybe I have to do a quick google search about unicode strings before implementing the reverse string.  But I would have thought about that!

I've written thread-safe code ... but then again, I was also using MFC stuff like CSingleLock.  So maybe in a C environment I'd have to refresh my memory on some things...but I would do the refreshing.  And I would understand it, quickly.

Other stuff mentioned by GK:

1) SEH and C++ SEH.  -- See I must not be using "real" C++ or something (I'm joking here)...but I've never heard of SEH or C++ SEH.  And I've been using C++ the past 2 years.  Can someone tell me what I'm doing wrong here!? :)

2) Do they know when it’s appropriate to use binary tree and when not? -- Last time I used a binary tree was in college.  4 years ago.  It might be a little foggy in my brain, but I can understand this stuff, I can refresh my memory, and get back to using binary trees again.

3) Can they explain how to implement semaphore and can they code it? -- Again, last time I used a semapore was in college.

Obviously if this guy is looking for a senior developer, I suppose he/she should know this stuff off the top of his head.  But if he was hiring someone where the requirements were 2+ years of C++ ... a more jr. developer ... I think he'd make me poo myself with the questions he asked! :)

I don't know, the point I'm making is I could easily pick up the stuff he mentioned that I was unfamiliar with or I could easily refresh my memory on any of the topics that were foggy to me in an hour or two of googling.

Also throw in the fact that I would be a jr. developer under the guindance of sr. people (I don't think I'd need to bug them much because I can seek out info on google)

Also, there is the fact that everybody when they first start a job needs a few months of figuring out the companies proprietary code.  So I just feel if I was looking at other code for a few months (what every new employee has to do), you pick up on how people are using things, or what they are using, etc.  And by the time you learn what the company is doing ... you learn how to use the languages in the same way the company is using it.

This is why I think debugging is more important and this quality doesn't really get brought out of a person during an interview.

Of course...I could also be totally babbling and completely wrong! :)

William C
Saturday, February 08, 2003

We've recently been looking to hire a few junior developers who are competent in C/C++.

We asked questions on pointer arithmetic, bitwise operators, differences in types, and memory allocation. None of it particularly taxing.

Out of 200 resumes we found 3 people who could answer them all.

Incidentally - following up on the earlier sample questions - I wouldn't have known it was okay to free NULL. In fact, I'd have assumed it was undefined, and I always check for non-NULL before trying a free. You can't malloc something into NULL, so why try freeing it?

Better than being unemployed...
Friday, February 21, 2003

*  Recent Topics

*  Fog Creek Home