Pain of Recruiting Developers

[spiderz]

I hear the same things as the OP says from people in my company who do interviews. I dont understand it personally. I think what grates me more is what I see as lying. If I suck at Python, I'll tell you. But I'll point out how quickly I could learn it. I wont lie and tell you my Python skills are 9/10, as some candidates do.

But but but , my Python skills are 9/10 ... i can spell python right 9 out of 10 times
Haven't seen any error handling yet ...

 

[deweyzeph]

Why bother if they cant solve logical problems?

I dont get why people are still shocked at the idea of a technical test. Every company I've ever interviewed at, bar none, has either had a technical test/exam or technical questions from a senior developer. Or both. And sometimes also "write us a program/website that does X and Y"

I hear the same things as the OP says from people in my company who do interviews. I dont understand it personally. I think what grates me more is what I see as lying. If I suck at Python, I'll tell you. But I'll point out how quickly I could learn it. I wont lie and tell you my Python skills are 9/10, as some candidates do.

When we interview people for .NET developer positions we write out a spec for a small website and we sit them down in front of a computer and ask them to create the website in Visual Studio and SQL Management Studio. The test includes html, SQL, ASP.NET controls, DB design, xml, etc. They have 3 hours to do it. That's a technical test. Asking people to write out pseudocode is just pointless and actually potentially could mean you miss out on a good developer. Not everyone thinks in terms of pseudocode.

 

[Nerfherder]

I recently moved down to CT and I have about 4 years of dev experience, I have a computer science degree and have coded in a few different languages, quite a few actually.
My problem is that it so many that I have not really had the chance to become very skilled in any one of them.

I interviewed with a few different companies all who had very different ideas on the kind of developer they needed. Unfortunately for me and them the recruiters don't really understand my skills and the skills needed for the various jobs... so they didn't really match.

I was very unprepared for the type of interviews that I had, some interviews went well despite this and others were horrible.

I have now focused on a language and been pushed to get to a much higher level of skill in my current position, I now know how unprepared I was for those tests... even more than I felt during the interviews !

The thing is... despite being able to nail those kind of tests I still think that I could have "cheated" them a bit looking back.

All I would have done is Google "c# interview test", printed out a few different ones and practiced them for a few days before. They are all so standard and I even got asked the same problem in two different interviews LOL
I'm not saying that I would have got the job but I was certainly able to bull**** my way through the rest of the interview. Most of the guys that interviewed me took it as an opportunity to show me how clever they were and their own interpretation of the problem, just begging to have their ego's stroked.


I think for recruiters to really add value to what they do they need to find a way of effectively evaluating the candidates and prepping them for the interview.
Even just manage the expectations of the employers....

 

[Ancalagon]

When we interview people for .NET developer positions we write out a spec for a small website and we sit them down in front of a computer and ask them to create the website in Visual Studio and SQL Management Studio. The test includes html, SQL, ASP.NET controls, DB design, xml, etc. They have 3 hours to do it. That's a technical test. Asking people to write out pseudocode is just pointless and actually potentially could mean you miss out on a good developer. Not everyone thinks in terms of pseudocode.

But every developer should think logically. Pseudocode can help illustrate that. Come on, it is a language with no rules. You can say whatever you like. Its just useful for breaking down thoughts and problems into smaller components.

If a developer can only code in one language, he is not a good developer because he is still tool bound. .Net is still just a tool to me - perhaps one day it will be replaced, and when that day comes, I will be ready to learn something new. I can still think logically and write my thoughts down in pseudocode, or plain english, or java script, or whatever. So to think that asking a developer to know pseudocode is asking too much is quite ludicrous to me.

 

[Nerfherder]

Here's a suggestion, why not sit your interviewees in front of a computer and ask them to write real code to solve your problem.

One of the interviews I did they asked me to do that.

I told them I only had 3 months exp in the lang they wanted me to do the test in (I was trying to move in to that lang) and they weren't worried.
During the test I struggled with syntax and remembering the structure of the language. I wanted to google and thought that they would be more upset if I did that.

When they came back they asked me why I didn't google.... SMH

Testing some one's knowledge of a particular language is one thing... its only part of evaluating their skills. in previous jobs I was expected to pick up a new lang in weeks, so that I could fix old code etc..

How do you test that... if you are not going to test my problem solving abilities then you have the wrong candidate and need to tell me upfront.

 

[Other Pineapple Smurf]

This is a bit of a rant about my pain we have finding developers to recruit at my work. I created and evaluate the technical tests. Finding developers that are even halfway competent is scary. But I want to bounce something from forum. We have an question in our interview - with the idea to test basic problem solving skills. The structure of the question is as follows:
....
So my question is: Do most "developers" exclude problem solving skills from their job description? Is this something that is not expected from developers? Is "pseudo-code" such a foreign concept that it is reasonable for a developer not to know what it is? Where can we find junior developers with the basic skills?

I do believe the problem is not your candidate but rather you and your expectations of what Pseudo-code is!

As a current BSc student with 5yrs on the job development experience and 15yrs prior as a hobby, what is pseudo-code for me seems not to be pseudo-code for you. If your trying to get your answer as some sort of "pseudo-code standard", then you would need to supply a Pseudo-code cheat-sheet.

I've worked with super-ninja developers that have never used Pseudo-code and would tell you to sod off if you asked them for it. Yet they are 100% competent in problem solving and explaining on a whiteboard how the workflow happens. I also consider these guys as my peers, oh and they all know Haskell.

 

[Ancalagon]

I really dont think his pseudocode expectation is the problem! There are no standards for the language by definition!

I only used to put Haskell on my CV when I was fresh out of varsity and it was one of the few languages I knew.

 

[MagicDude4Eva]

I have found that those "technical tests" during an interview are mostly pointless. You will attract the "theorists" who are not streetwise and have no connection to real-life problems. Just finding candidates who have a company cultural fit poses a huge problem (doesn't help to hire a mousy rocket-scientiest - or?). I prefer hiring people on their working-experience, personality and mostly gut-feel - people will always be placed under probationary period and during this time receive sufficient tasks to prove themselves. If you are good, you stay, otherwise leave after the probationary period - quite simple and efficient.

Many interviewers are in my opinion outright egotistical arseholes, trying to show off in front of their bosses how much better they are than the candidate and in most instances it always turns into a pissing contest. For me the biggest concern is that developers come in at really high salary-packages despite no real working experience. Everyone nowadays has their SUN/MS certifications and it is worrying to see people with 3 (or less) years of work-experience asking >650k p.a.

 

[Johand]

One of the interviews I did they asked me to do that.

I told them I only had 3 months exp in the lang they wanted me to do the test in (I was trying to move in to that lang) and they weren't worried.
During the test I struggled with syntax and remembering the structure of the language. I wanted to google and thought that they would be more upset if I did that.

When they came back they asked me why I didn't google.... SMH

Testing some one's knowledge of a particular language is one thing... its only part of evaluating their skills. in previous jobs I was expected to pick up a new lang in weeks, so that I could fix old code etc..

How do you test that... if you are not going to test my problem solving abilities then you have the wrong candidate and need to tell me upfront.

1. The only reason is why we ask for pseudo code is because we want to focus on the problem solving part of the problem, and not on syntax. We also do not want to make the question programming language specific. We do give them the option to write it in any real programming language if they want.

2. We are not looking for pseudo-code syntax - we are looking for the structure of the problem solved. They can use pseudo-lisp. If they gave me graphical pseudo diagram of their own invention in Korean I will work with it, as long as it solved the actual problem.

3. The test is on paper, and you are not allowed Google. We are not testing experience in a language with this question, but basic problem solving skills required for coding. If we teach you a brand new language, you should be able to solve the problem in the language we just taught you. I do not want to work with developers that comes back to me with "I solved this problem in language X, but now I use language Y and I cannot do solve the problem anymore."

 

[deweyzeph]

I do believe the problem is not your candidate but rather you and your expectations of what Pseudo-code is!

As a current BSc student with 5yrs on the job development experience and 15yrs prior as a hobby, what is pseudo-code for me seems not to be pseudo-code for you. If your trying to get your answer as some sort of "pseudo-code standard", then you would need to supply a Pseudo-code cheat-sheet.

I've worked with super-ninja developers that have never used Pseudo-code and would tell you to sod off if you asked them for it. Yet they are 100% competent in problem solving and explaining on a whiteboard how the workflow happens. I also consider these guys as my peers, oh and they all know Haskell.

Completely agree with this.

 

[PapercutPrincess]

In school, a lot of emphasis was put on pseudocode... I'm shocked that something that simple (in your entity's interview) is misinterpreted and even so, if the candidate doesn't understand, he/she must ask!

I don't remember if it was in first year or this year but we did some algorithm solving in pseudocode and it confused quite a few people :/

 

[Johand]

I have found that those "technical tests" during an interview are mostly pointless. You will attract the "theorists" who are not streetwise and have no connection to real-life problems.

Yes and that is why I hate the "Why is a manhole cover round?" type of questions.

Just finding candidates who have a company cultural fit poses a huge problem (doesn't help to hire a mousy rocket-scientiest - or?). I prefer hiring people on their working-experience, personality and mostly gut-feel - people will always be placed under probationary period and during this time receive sufficient tasks to prove themselves. If you are good, you stay, otherwise leave after the probationary period - quite simple and efficient.

I do get what you are saying and this is only one test of many - we also do psychometric testing etc. I am not in HR, I just help the technical test. But bear in mind that there are certain legal requirements that a company has to comply to - and as far as I understand "culture" is not a legal reason NOT to hire somebody (although I think it should be). And probationary periods are also not all it is cracked up to be - you cannot simply let somebody go after that period because you felt like it, there are some procedures mandates by law to go through. You have to document everything you do with recruiting, and show that a person was hired or not hired based on something you test. If you decide to hire one person above the other, legally you have to be able to prove that the candidate you hired was better qualified than the candidate you did not hire.

Many interviewers are in my opinion outright egotistical arseholes, trying to show off in front of their bosses how much better they are than the candidate and in most instances it always turns into a pissing contest. For me the biggest concern is that developers come in at really high salary-packages despite no real working experience. Everyone nowadays has their SUN/MS certifications and it is worrying to see people with 3 (or less) years of work-experience asking >650k p.a.

I don't think I am an egotistical arsehole. We have very comprehensive testing, with input from our entire team - this was just one question vetted by a lot of people. The test is not administered by team who created the test. One of the reasons we have these tests is that we do not have the capacity to pull technical people for every interview, and that HR must be able to make a "first-pass" decision on their own. I am not directly involved in hiring, but as far as I understand our hit rate on interviews for new employees is in the single digit percentages and even then we have trouble with people coping with the job requirements.

We are pretty confident that the skills we test is the ones that will also be required on the job. I would have thought that this skill is a requirement for most "enterprise" programming jobs.

 

[Ancalagon]

Do you meet with prospective candidates before giving them a test?

That has become a deal breaker for me - if a company wants me to do a test before they are willing to tell me about themselves, I'm not interested. Your time is no more precious than my time.

 

[roguemat]

Most people will disagree with me here, but I don't think asking them to problem solve is always the best idea.
You may - actually, you WILL - miss some great devs this way, just because they aren't totally proficient in writing pseudo-code, or are nervous etc.
This is where experience comes into play. If a dev comes to you and has written great apps before, then why does it matter that he can't do a simple little test. Problem solving skills or not, he has made stuff before and obviously found a way around any problems he had (whether googling the answer with bing or SO).

 

[Ancalagon]

Most people will disagree with me here, but I don't think asking them to problem solve is always the best idea.
You may - actually, you WILL - miss some great devs this way, just because they aren't totally proficient in writing pseudo-code, or are nervous etc.
This is where experience comes into play. If a dev comes to you and has written great apps before, then why does it matter that he can't do a simple little test. Problem solving skills or not, he has made stuff before and obviously found a way around any problems he had (whether googling the answer with bing or SO).

I just dont see how someone can be proficient in solving problems with code if they arent proficient in solving logical problems. It doesnt have to even be pseudocode, I mean you should be able to ask someone and have them tell in plain english face to face.

 

[Nerfherder]

1. The only reason is why we ask for pseudo code is because we want to focus on the problem solving part of the problem, and not on syntax. We also do not want to make the question programming language specific. We do give them the option to write it in any real programming language if they want.

2. We are not looking for pseudo-code syntax - we are looking for the structure of the problem solved. They can use pseudo-lisp. If they gave me graphical pseudo diagram of their own invention in Korean I will work with it, as long as it solved the actual problem.

3. The test is on paper, and you are not allowed Google. We are not testing experience in a language with this question, but basic problem solving skills required for coding. If we teach you a brand new language, you should be able to solve the problem in the language we just taught you. I do not want to work with developers that comes back to me with "I solved this problem in language X, but now I use language Y and I cannot do solve the problem anymore."

I replied to the part where he said that he wanted to put the candidate in front of a pc and have them develop a solution.

Here's a suggestion, why not sit your interviewees in front of a computer and ask them to write real code to solve your problem.

I agree with you about pseudo code.

If you have a degree that means you have the ability to code in a language, solving a problem in pseudo code means you can analyze a problem and understand it in a logical way.
The two things are very different.

 

[reactor_sa]

All the good dev shops do a prac assessment(3-4 hours), either before or after the interview.

Personally I prefer to do a interview first to get an idea of what kind of person the interviewee is, and if we like them then we schedule a short follow up interview and a practical assessment to get a better idea of whether they are junior / intermediate / senior.

 

[Johand]

Do you meet with prospective candidates before giving them a test?

That has become a deal breaker for me - if a company wants me to do a test before they are willing to tell me about themselves, I'm not interested. Your time is no more precious than my time.

The technical people often doesn't meet the potential candidates. But HR is really really good in providing the information. In fact some of the normal HR questions unrelated to technical tests relates to things like: Did you Google us? Do you know what we do? Have you any questions to ask about what we do?

I just dont see how someone can be proficient in solving problems with code if they arent proficient in solving logical problems. It doesnt have to even be pseudocode, I mean you should be able to ask someone and have them tell in plain english face to face.

+1. One of the requirements of the job is working a team and the ability to document what you have done. Any developer needs to most basic communication skill. I would think that for any but the most basic development this is a requirement? Or do most developers work in dark rooms on their own?

All the good dev shops do a prac assessment(3-4 hours), either before or after the interview.

I would like it to. Unfortunately it will not solve the problem. The number of recruits to sift through before you get even remotely to a good candidate is just too high. 3 to 4 hours for 100 applicants is a ridiculous amount of time to engage our technical people with (especially because they are not all in the same cities, the same progress in the recruitment process etc). That is why we need tests that can give us answers - even if it is just to identify candidates with more potential and THEN do a full on technical test.

But I must say - I have heard from some of these "good dev shops" with insane tests. But some of them just test language syntax (no problem solving skills). Some of them do a practical test but a lot of them have really low bars -> if you can connect to the database you are set, even if the tests have far more elements.

I must say that the bar is quite high in our company - nobody is going to sit idle and just plonk along 9 to 5. We have real projects to deliver and there is an expectation of delivery.

Personally I prefer to do a interview first to get an idea of what kind of person the interviewee is, and if we like them then we schedule a short follow up interview and a practical assessment to get a better idea of whether they are junior / intermediate / senior.

Yes - that happens as well. As a side note on the senior developer side (not to do with this test) I have seen some super experienced high-level smooth talkers who just cannot apply concepts that they will happily chat about. So they understand ACID principles of databases verbally, but when they have to logically structure it, they just fail. Random database commits ("the code works when you do it" instead of "you have to commit at this point to ensure consistency").

 

[Ancalagon]

But I must say - I have heard from some of these "good dev shops" with insane tests. But some of them just test language syntax (no problem solving skills). Some of them do a practical test but a lot of them have really low bars -> if you can connect to the database you are set, even if the tests have far more elements.

Some of the tests I've done have been far too narrow in focus. Its like, if you read page 547 paragraph 2 of How to Win at C#, then you will know this, otherwise we arent hiring you. I dont like that kind of stuff. Obviously the candidate needs a solid background of whatever it is you are doing, but if they miss out on one or two things, but get the logical problem solving and theory stuff right, then I think they are worth hiring.

 

[walter_l]

This has been quite an interesting thread to read (even infuriating at times). I guess there are simply different strategies and likes/dislikes among us.

To get back to the original issue... Yes, it is apparently quite common to find many such "devs". Jeff Atwood asked this same question in '07: Why Can't Programmers... Program? From there the FizzBuzz test became quite widely used as an interview question (in fact, I added it as the first question to the technical interview test for a previous employer). For those who didn't read the article, the FizzBuzz test is only slightly harder than Johand's example, but a great tool to eliminate early on those candidates that you really don't want to waste any more time on.

I understand that companies need to make a compromise between acquiring resources (to get stuff done) and finding the very best, but "devs" who can't solve these basic types of problems will be more of a burden than a resource.

Also... be wary of people who use Paint to pad their CV's with.