Support NeoGAF

[ronito]

So today we interviewed an individual that the phone screener said was among the best people he phone screened. Not like those hacks we had face-to-face interviews with last week, this person was legit.

So we brings the guy in. We sits the guy down, and we says to him... we says to the guy... we says we says we says, he's sitting there, we're sitting here, and we says to the guy...

Oops, fell into a little Hank Doodle.

Long story short, it was yet another bombed interview. I don't know what gives, if the people are just so incredibly nervous that they can't form coherent sentences on the basic questions, or what. These people have years of experience listed on their resumes. 5 years, 8 years, 20 years. Can't answer the most basic of questions. I'm talking basic. "Difference between X and Y and if you've even made it to chapter 3 of your 'Intro to C#' book you couldn't possibly not know the answer" type questions. Database 101 type questions. "Do you even have a pulse" type questions.

We had a guy who supposedly worked at a community college as an instructor on a language. He didn't know the language.

:/

It hurts when these people bomb so hard.

Might I suggest that perhaps you're going about this wrong?
I mean look at this thread. It's 11 pages long (5.5 if you're GAF gold) full of a bunch of different developers talking about how they might solve such a problem. It's not my bidniss to tell you how to interview but if you've consistently gone up against qualified candidates and found none work....I mean I'm pretty hard on my interviews but I still have about a 30% pass rate.

 

[Randolph Freelander]

Might I suggest that perhaps you're going about this wrong?
I mean look at this thread. It's 11 pages long (5.5 if you're GAF gold) full of a bunch of different developers talking about how they might solve such a problem. It's not my bidniss to tell you how to interview but if you've consistently gone up against qualified candidates and found none work....I mean I'm pretty hard on my interviews but I still have about a 30% pass rate.

Trust me, I'm not asking anything that's anywhere remotely complicated. I'm not asking about reversing strings, recursive functions, anything about trying to come up with some clever answer to an irrelevant logic puzzle.

The people simply are not qualified. They can't answer basic questions. They cannot debug simple 5 line methods. They cannot explain to me what's happening inside a simple loop. They cannot talk to me about various collection types, generic versus non, stuff that anybody writing C# code longer than a week as a professional should be able to at least mumble their way through.

Trust me, I don't even think I'm asking difficult enough questions. And given the application they would be working on, if they can't explain a 5 line method, there's no way I'm going to recommend (and, again, I can only recommend, the hiring decision is completely not my call) that they work on fixing a 500 line method. A 1000 line method. A 1500 line method. Those exist in our code! They came from the offshore development group that created the application, and they have been steadily added to in the 3 years the application has been in house by all the contractors that have come before. I'm just one more contractor in the line of people that have had to deal with the mess and hopefully leave it in a better state, I just get the opportunity to sit in on the interview process for the next person(s) to be brought in.

These people simply cannot code or, at the very least, cannot talk about it, which is just as bad, given an interview setting. Hopefully it gets better.

 

[ronito]

In that case seems you need a better recruiter to filter out the clowns you have a recruiter right?

 

[Randolph Freelander]

In that case seems you need a better recruiter to filter out the clowns you have a recruiter right?

Yes, we're working with several recruiting agencies in the area, and we have phone screens prior to the face-to-face. I told my boss we might have to fire our phone screener.

(My boss is the phone screener.)

I don't know what gives, although we can certainly speculate. My boss feels he needs to change up his own screening tactics a bit, he thinks the recruiting companies are supplying the questions in advance. He's also well aware and even detects when candidates are actively googling the questions (he weeds those people out). We've even heard (a recruiter told me this directly) that some of the more shady agencies will have senior level developers take the phone screen for more junior level candidates (we don't think that's happened with us).

Whatever the reason, the candidates that have made it through the phone screens have so far faceplanted during the face-to-face. And, believe me, if I sent you the list of questions I was asking... well, you'd think we were being entirely too soft.

 

[cpp_is_king]

Yes, we're working with several recruiting agencies in the area, and we have phone screens prior to the face-to-face. I told my boss we might have to fire our phone screener.

(My boss is the phone screener.)

I don't know what gives, although we can certainly speculate. My boss feels he needs to change up his own screening tactics a bit, he thinks the recruiting companies are supplying the questions in advance. He's also well aware and even detects when candidates are actively googling the questions (he weeds those people out). We've even heard (a recruiter told me this directly) that some of the more shady agencies will have senior level developers take the phone screen for more junior level candidates (we don't think that's happened with us).

Whatever the reason, the candidates that have made it through the phone screens have so far faceplanted during the face-to-face. And, believe me, if I sent you the list of questions I was asking... well, you'd think we were being entirely too soft.

Recruiting companies absolutely do this, 100%. You mention level developers. Is this a game studio? If so, I'm not sure why you're having trouble finding applicants without going through a recruiter in the first place.

 

[Godslay]

The people simply are not qualified. They can't answer basic questions. They cannot debug simple 5 line methods. They cannot explain to me what's happening inside a simple loop. They cannot talk to me about various collection types, generic versus non, stuff that anybody writing C# code longer than a week as a professional should be able to at least mumble their way through.

I find this amazing myself. Why even apply if you don't know what the hell you are doing?

To be entirely honest though I have locked up on a technical test before. It was my very first interview outside of an internship, and I had heard what to expect. It was for a defense contractor. I answered the basic questions, but after these questions things changed quickly. I knocked out a factorial method, and a couple others than I don't remember now, but after that it became very specific and difficult. Quite frankly it intimidated me at the time, because I didn't know how to solve what they where asking me. It just wrecked my confidence in the interview because I thought I had prepared. To make a long story short I didn't get the job. It was brutal at the time, but it made me a better programmer in the sense that it took me down a notch and made me refocus rather than be overly confident in my abilities.

 

[ronito]

Maybe a new recruiter is in order? Maybe one that won't give them the answers? If so pm me I got a recruiter that I trust. Also you're paying a competitive salary right? You pay peanuts you get monkeys

 

[Proelite]

Maybe a new recruiter is in order? Maybe one that won't give them the answers? If so pm me I got a recruiter that I trust. Also you're paying a competitive salary right? You pay peanuts you get monkeys

No salary talks until the guy is hired.

 

[Zoe]

No salary talks until the guy is hired.

Not even a range?

 

[Hop]

Recruiting companies absolutely do this, 100%. You mention level developers. Is this a game studio? If so, I'm not sure why you're having trouble finding applicants without going through a recruiter in the first place.

Senior-level developers, I assume, not senior level-developers.

I'm worried this thread is gonna make me cocky come interview time myself XD I mean, yea I've bombed interviews, but I can't possibly be this bad...

 

[Proelite]

Not even a range?

Companies usually only post doe or competitive on the job descriptions.

-sent from iPhone.

 

[Ravager61]

Ok, this seems like a good place to ask this actually. I have a basic coding test tomorrow for a Jr. level software developer position tomorrow.

Im fairly certain this will be pretty basic. The HR lady who I talked to during my initial phone interview mentioned for/if loops, and setting parameters (I assume she means within classes). All easy stuff. It's just been a while since I graduated with my CS degree and I haven't been doing programming at all in my current positions (I'm more of an infrastructure guy). I'm a little worried they are going to throw something basic at me that I just won't remember and choke.

So, what specifically should I review before I take this test? It's only about 30 minutes and over live meeting so I know they aren't going to have me do anything too intense but I'd like to get some direction on some basic CS concepts that I should review. It's in .Net by the way.

 

[Randolph Freelander]

Recruiting companies absolutely do this, 100%. You mention level developers. Is this a game studio? If so, I'm not sure why you're having trouble finding applicants without going through a recruiter in the first place.

No no, not games. Senior, as in skill level, as Charron said.

 

[Sharp]

Senior-level developers, I assume, not senior level-developers.

I'm worried this thread is gonna make me cocky come interview time myself XD I mean, yea I've bombed interviews, but I can't possibly be this bad...

Some people interview well and some don't. Often it's as simple as that. There is a brilliant CS guy I know who ended up moonlighting as an ER technician because the moment he gets in front of an interviewer he loses all confidence and forgets everything he knows.

 

[deadbeef]

Ok, this seems like a good place to ask this actually. I have a basic coding test tomorrow for a Jr. level software developer position tomorrow.

Im fairly certain this will be pretty basic. The HR lady who I talked to during my initial phone interview mentioned for/if loops, and setting parameters (I assume she means within classes). All easy stuff. It's just been a while since I graduated with my CS degree and I haven't been doing programming at all in my current positions (I'm more of an infrastructure guy). I'm a little worried they are going to throw something basic at me that I just won't remember and choke.

So, what specifically should I review before I take this test? It's only about 30 minutes and over live meeting so I know they aren't going to have me do anything too intense but I'd like to get some direction on some basic CS concepts that I should review. It's in .Net by the way.

It's too late at this point. Just be loose and verbose on your thought process as you break down the problem so they can see how you are thinking through the problem. Good luck.

 

[Spoo]

I can't lay claim to it, it's paraphrased based upon something Eric Lippert (C# compiler team) often has to write on StackOverflow as he's explaining classes and objects and references and copy-by-value semantics to other confused developers.

I used to TA for an intro CS class, and used a very similar analogy (with a dollar bill) to explain passing by reference vs. by value, and during it a student who had just been listening in turned to me and said "That is by far the best explanation I have ever heard. Better than my professor, anyway."

It made me feel great, but it also underscored I think a real problem in academics where features of a language are taught in text-book style.

A lot of us don't remember mathematics due to rote memorization, we actually had tangible, simple examples, that conceptually and instinctively made sense.

My guess would be, when someone is bombing an interview, they are simply A) full of shit and don't know what they're talking about, or B) Never learned -- just emulated, watched, and read. For some people that's enough, for the rest, not so much. There are, of course, people with anxiety problems or maybe depression who have troubles face-to-face (I should know, as I'm one of these people), but those issues can be solved.

 

[Sharp]

Well, the issue is, in C++, the "+=" is an append operation. For C#, it creates a new string object with the text " barney" at the end. I like that one because it tells me whether or not the programmer can realize if they're adding unneeded garbage to the heap.

I rarely use the STL in C++, but does it actually allocate a lot of memory for string objects in advance? If it doesn't, more than likely it's actually allocating a new string with the text "barney" at the end, then switching to point to it, finally freeing the old memory. Depending on how it handles it, that might actually be less efficient than the C# version.

 

[Randolph Freelander]

Maybe a new recruiter is in order? Maybe one that won't give them the answers? If so pm me I got a recruiter that I trust. Also you're paying a competitive salary right? You pay peanuts you get monkeys

We use basically all the agencies in the market. The TekSystems, Apex, etc., including a bunch of agencies I've never heard of. We're a large bank, we have very established relationships with the recruiters. (I say "we," like I'm not also a contractor or something from one of these same agencies!)

 

[wolfmat]

It's too late at this point.

Pretty much. In the future, try to start with preparations at least a week before shit gets real.

As a programmer at a job interview, you want to be able to tackle generic problems in the programming language the job is about, and you want to be able to speak about concepts in general.

Furthermore, you want to be able to analyze problems meaningfully that are associated with the position you're supposed to fill. A game engine programmer should know things about collision detection (among lots of other things), for example.

 

[Sharp]

I don't understand how the second function could possibly be considered faster, even by initial inspection. Memory related activities would make it noticeably slower. It's a basic tenet of programming and embedded systems.

Modern (and not so modern, actually) computers are designed to be able to copy large blocks of data quickly because they predictively load it into the cache. So if you copy a lot of data linearly with memcpy it will often be faster. Faster still can be to copy the memory by word rather than byte, of course.

 

[mugurumakensei]

I rarely use the STL in C++, but does it actually allocate a lot of memory for string objects in advance? If it doesn't, more than likely it's actually allocating a new string with the text "barney" at the end, then switching to point to it, finally freeing the old memory. Depending on how it handles it, that might actually be less efficient than the C# version.

It allocates a certain minimum amount of space by default (can be tuned by calling another constructor). Functionally, it works the same as the append operation in StringBuilder.

 

[Sharp]

It allocates a certain minimum amount of space by default (can be tuned by calling another constructor). Functionally, it works the same as the append operation in StringBuilder.

Yeah, in that case I agree with you. Just wasn't sure of the implementation details.

 

[Randolph Freelander]

My guess would be, when someone is bombing an interview, they are simply (...) B) Never learned -- just emulated, watched, and read. For some people that's enough, for the rest, not so much.

We call these people cargo cult programmers, based upon the similar cargo-cult religious practicies.

 

[Sharp]

Oh, and to the people earlier bitching about how the swap two integers question wasn't a real-world one: so the fuck what? Programmers are asked to deal with limited, restricted systems where they'll have to think creatively in order to find a way to do what they want all the fucking time. Questions like that are an excellent way to see someone's problem-solving skills on display. Asking about code or giving a real-world example is fine, I suppose, but once you've learned a few languages the question of what function or API call does what or what method is more efficient in a particular language become almost irrelevant IMO. All that's easy to learn on the job and a good programmer isn't going to get hung up on implementation details. But basic problem-solving skills are much harder to learn. And even if they don't get a question like the swap one right, you learn a lot from how the interviewee went about solving it.

 

[Spoo]

We call these people cargo cult programmers.

Haha, I've actually always just used the name "black box" programmer, but that seems in line with it.

There's a surprising amount of things those people can do, though, and in certain scenarios I would assume they're quite valuable. I have a friend who has never taken a CS class before, probably knows pre-algebra levels of mathematics, and knows one language (PHP, in this case). Out of a sincere need to get a job and maintain his family, he was able to learn enough from myself and his own hard work to get to a point where he's apparently very valuable to the company and makes a little less than a CS degree-holder would out of the gate.

And it's very clear when you look at their code the orientation they have towards solving problems, where no expense is spared on memory, no consideration for algorithm complexity, and yet, these are functional programmers (in that they can program) to get their work done. And it may feel very comforting to be the "white box" programmer who can reverse a string, swap without a temp variable, not have to refer to a data structures book to write a graph or a tree, etc, and I would suggest any programmer attempt to reach those levels of fluency, but for those that haven't, getting shut down in an interview being asked to do something that people rarely do (top 1%?) seems like a raw deal for candidacy.

Just my opinion, though.

Edit: To be clear, when I say top 1%, I don't mean that there will never be a need to reverse something, but there's a difference in calling reverse() on a structure and having to write your own reverse out of real necessity.

 

[cpp_is_king]

Modern (and not so modern, actually) computers are designed to be able to copy large blocks of data quickly because they predictively load it into the cache. So if you copy a lot of data linearly with memcpy it will often be faster. Faster still can be to copy the memory by word rather than byte, of course.

Faster still is to use the memcpy() function provided by the CRT. Dissasemble it sometime if you want to blow your mind about how something so seemingly simple can be so complicated.

 

[butzopower]

Oh, and to the people earlier bitching about how the swap two integers question wasn't a real-world one: so the fuck what? Programmers are asked to deal with limited, restricted systems where they'll have to think creatively in order to find a way to do what they want all the fucking time. Questions like that are an excellent way to see someone's problem-solving skills on display. Asking about code or giving a real-world example is fine, I suppose, but once you've learned a few languages the question of what function or API call does what or what method is more efficient in a particular language become almost irrelevant IMO. All that's easy to learn on the job and a good programmer isn't going to get hung up on implementation details. But basic problem-solving skills are much harder to learn. And even if they don't get a question like the swap one right, you learn a lot from how the interviewee went about solving it.

I don't think that's a good question due to it's trivia nature. You don't really solve that problem, you just know THE method to solve it or you don't.

 

[noire]

for mobile / web / backend and it's nearly impossible to find any that are currently looking for a job. We've been searching for a year for candidates that can reverse a string and do the fib sequence recursively and we'll only found three.

Any one else experiencing the same talent drought at their company?

My company, IAC, is based in NYC.

Hey, we're co-workers.

 

[deadbeef]

Again, this is why I hate developer interviews. It's all about the e-peen and that's really not helpful.

This is so true.

"Haha! I stumped you!!!!"

 

[Sharp]

I don't think that's a good question due to it's trivia nature. You don't really solve that problem, you just know THE method to solve it or you don't.

That's not really true unless you think you're expected to give an answer instantly. To me, questions like 'reverse a string' or 'write the Fibonacci function' are far more trivial, any decent programmer's going to solve them instantly and you pretty much won't see any of the process he or she normally uses to solve actual problems. Then again, I guess it depends on the candidates you're seeing.

 

[cpp_is_king]

I don't think that's a good question due to it's trivia nature. You don't really solve that problem, you just know THE method to solve it or you don't.

This might be a controversial opinion, but in my experience people who know/enjoy CS trivia are often passionate about the subject as a whole, and are not the type that just want to be code monkeys. So things like that, for me anyway, are a plus if you know them, but not a minus if you dont

 

[mugurumakensei]

I don't think that's a good question due to it's trivia nature. You don't really solve that problem, you just know THE method to solve it or you don't.

Not really... It's a lot easier once you figure it out, but, if you have the mathematical skills necessary, it's more than possible to figure it out on your own.

 

[Slavik81]

Which method did ypu use? Subtraction or xor'ing

I dont know if the xor method was mentioned here so i wrote the xor version below

a = a ^ b;
b = a ^ b;
a = a ^ b;

Oh, I see where I was confused earlier. This is acceptable if you know &a != &b. Something seemed off when I was thinking about this earlier. I'd been thinking it was required that a != b, but that is not the case.

 

[Sharp]

Oh, I see where I was confused earlier. This is acceptable if you know &a != &b. Something seemed off when I was thinking about this earlier. I'd been thinking it was required that a != b, but that is not the case.

Yeah, if a and b share the same memory you're screwed (though I haven't usually seen the question phrased in the context of a particular language or a physical machine). But it's not like there's anything stopping you from doing a quick if(&a == &b) return; or anything. Actually, if you've written your function properly in the correct language, that shouldn't even be an option.

 

[mugurumakensei]

Oh, I see where I was confused earlier. This is acceptable if you know &a != &b. Something seemed off when I was thinking about this earlier. I'd been thinking it was required that a != b, but that is not the case.

If &a == &b, the compiler has introduced some really weird aliasing bug into your code. Both are assumed to be primitive integers.

 

[butzopower]

This might be a controversial opinion, but in my experience people who know/enjoy CS trivia are often passionate about the subject as a whole, and are not the type that just want to be code monkeys. So things like that, for me anyway, are a plus if you know them, but not a minus if you dont

Sure, but I don't think you should be asking a question in the first place. Also, if someone just threw that in some other code example for reasons of being "efficient", I would probably not hire them.

 

[Sharp]

If &a == &b, the compiler has introduced some really weird aliasing bug into your code.

Well, not necessarily, especially since you're probably swapping references to integers (otherwise there's not much point in a swap function). You could easily have written your function like this:

void swap(int &a, int &b) {
  a ^= b ^= a ^= b;
}

If you just pass that off blindly to people it's pretty easy to see where that could trip up.

Sure, but I don't think you should be asking a question in the first place. Also, if someone just threw that in some other code example for reasons of being "efficient", I would probably not hire them.

Again: why? Not going into the second part since I agree that an interviewee who is trying to impress you with bit tricks might not be the best fit for the job, but what makes this such an awful question?

 

[mugurumakensei]

Well, not necessarily, especially since you're probably swapping references to integers (otherwise there's not much point in a swap function). You could easily have written your function like this:

void swap(int &a, int &b) {
  a ^= b ^= a ^= b;
}

If you just pass that off blindly to people it's pretty easy to see where that could trip up.

Ah yes. As a function, it could be problematic. This particular method works best inline.

 

[butzopower]

Again: why? Not going into the second part since I agree that an interviewee who is trying to impress you with bit tricks might not be the best fit for the job, but what makes this such an awful question?

Same reason I explained before, it's a trivia question. Under what context do you ask the question? Simply just, "How do you swap a and b in place?" There are two outcomes:

- You know the answer.
- You know the answer is through some trick that there's no way in hell you are going to be able to figure out under the pressure of an interview.

For the later, I don't think it's a good problem to base someone's problem solving skills on. The solution is too far out to expect any sort of consistency in how they are going to approach it.

It's one step below giving someone a Rubix cube, and asking them to solve it.

 

[Sharp]

Same reason I explained before, it's a trivia question. Under what context do you ask the question? Simply just, "How do you swap a and b in place?" There are two outcomes:

- You know the answer.
- You know the answer is through some trick that there's no way in hell you are going to be able to figure out under the pressure of an interview.

For the later, I don't think it's a good problem to base someone's problem solving skills on. The solution is too far out to expect any sort of consistency in how they are going to approach it.

It's one step below giving someone a Rubix cube, and asking them to solve it.

I think it depends very much on who you're interviewing. Not all development jobs are created equal or require the same type or level of programmer. But personally I'm not sure why you think putting people under pressure or giving them a problem they may have a hard time solving correctly during an interview is a bad thing when many programmers do work under significant pressure or are pressed for time. As I said earlier, I really do think that giving someone problems that he or she may struggle to solve, but has all the tools at his or her disposal to answer, are much more revealing than mechanical questions like the ones in the OP--though if the programmer can't answer the OP's questions all this probably isn't really relevant. All that said, if you don't feel comfortable with it as a question you don't have to ask it; I just don't think it's as simple as "lol trivia."

 

[mugurumakensei]

Same reason I explained before, it's a trivia question. Under what context do you ask the question? Simply just, "How do you swap a and b in place?" There are two outcomes:

- You know the answer.
- You know the answer is through some trick that there's no way in hell you are going to be able to figure out under the pressure of an interview.

For the later, I don't think it's a good problem to base someone's problem solving skills on. The solution is too far out to expect any sort of consistency in how they are going to approach it.

It's one step below giving someone a Rubix cube, and asking them to solve it.

You say the answer, but there's at least two answers you can give for that question. If you can't work all the way through the answer in the time of the interview, you should at least verbalize your thoughts which is the idea. I would also give the interviewee hints if they ask. Asking for help if you don't know the answer is pretty important. It means you're not too prideful.

 

[Nerevar]

That's not really true unless you think you're expected to give an answer instantly. To me, questions like 'reverse a string' or 'write the Fibonacci function' are far more trivial, any decent programmer's going to solve them instantly and you pretty much won't see any of the process he or she normally uses to solve actual problems. Then again, I guess it depends on the candidates you're seeing.

I work for a consulting firm that primarily hires CS grads from top-tier universities or engineering schools in the northeast and the Carolinas. I'd say when I interview on campus 75% of the interviewees fall into two camps; they either can't do a simple programming problem (two strings are anagrams / reverse words in a string / etc) or they don't speak english well enough to interface with a client. It's pretty depressing to see the state of CS education. Maybe if you're only interviewing for experienced candidates and have a decent pre-screening team or process it's a different story, but my experience is that most of the people out there are pretty clueless.

 

[butzopower]

I think it depends very much on who you're interviewing. Not all development jobs are created equal or require the same type or level of programmer. But personally I'm not sure why you think putting people under pressure or giving them a problem they may have a hard time solving correctly during an interview is a bad thing when many programmers do work under significant pressure or are pressed for time. As I said earlier, I really do think that giving someone problems that he or she may struggle to solve, but has all the tools at his or her disposal to answer, are much more revealing than mechanical questions like the ones in the OP--though if the programmer can't answer the OP's questions all this probably isn't really relevant. All that said, if you don't feel comfortable with it as a question you don't have to ask it; I just don't think it's as simple as "lol trivia."

I didn't say anything about not wanting to put people under pressure, or even asking them hard questions, and I agree it's good to see someone's approach to a problem in an interview, rather than see if they can solve the problem or not. I'm just saying that I don't think that question would yield interesting results. I think it'd be a waste of my time, and the time of the person I'm interviewing. I wouldn't ask it for the same reason I wouldn't ask someone how they'd figure out how many bits are flipped in a number, in constant time or not.

EDIT:
I'm totally bias, though. When I interview someone, I interview them on a real project, so I wouldn't ask them any sort of whiteboard interview question, I'd see what they can do.

 

[ronito]

We use basically all the agencies in the market. The TekSystems, Apex, etc., including a bunch of agencies I've never heard of. We're a large bank, we have very established relationships with the recruiters. (I say "we," like I'm not also a contractor or something from one of these same agencies!)

well that's part of your problem. These are great companies for infrastructure projects and such but really not so great at dev resources. Have you played with the idea of contracting it out? In this economy it's totally possible that the only people worth having are contractors/consulting. That's very much true of "especialized skill sets' from time to time.

Oh, and to the people earlier bitching about how the swap two integers question wasn't a real-world one: so the fuck what? Programmers are asked to deal with limited, restricted systems where they'll have to think creatively in order to find a way to do what they want all the fucking time. Questions like that are an excellent way to see someone's problem-solving skills on display. Asking about code or giving a real-world example is fine, I suppose, but once you've learned a few languages the question of what function or API call does what or what method is more efficient in a particular language become almost irrelevant IMO. All that's easy to learn on the job and a good programmer isn't going to get hung up on implementation details. But basic problem-solving skills are much harder to learn. And even if they don't get a question like the swap one right, you learn a lot from how the interviewee went about solving it.

But that's just the thing it's not a problem solving question it's a "Gotcha!" question.

I'm all about being creative and testing problem solving skills but I find realistic problems much more helpful not these 'If you happen to know about the register you can prove your problem solving skills. Otherwise, hahaha my e-peen is bigger than yours!'

 

[Phoenix]

Yes, we're working with several recruiting agencies in the area, and we have phone screens prior to the face-to-face. I told my boss we might have to fire our phone screener.

(My boss is the phone screener.)

I don't know what gives, although we can certainly speculate. My boss feels he needs to change up his own screening tactics a bit, he thinks the recruiting companies are supplying the questions in advance. He's also well aware and even detects when candidates are actively googling the questions (he weeds those people out). We've even heard (a recruiter told me this directly) that some of the more shady agencies will have senior level developers take the phone screen for more junior level candidates (we don't think that's happened with us).

Whatever the reason, the candidates that have made it through the phone screens have so far faceplanted during the face-to-face. And, believe me, if I sent you the list of questions I was asking... well, you'd think we were being entirely too soft.

Recruiting companies are not your friend. Their goal is to get you to hire someone so they can get money and they will 'update' resumes, generate brain benches, etc. to make their candidates look like the best thing since sliced bread.

 

[ronito]

Recruiting companies are not your friend. Their goal is to get you to hire someone so they can get money and they will 'update' resumes, generate brain benches, etc. to make their candidates look like the best thing since sliced bread.

I dunno. A bad recruiter can do a ton of damage to your search. But a good one can really cut out a bunch of the crap. But the thing is you have to have a recruiter you can really trust and hold acountable if they waste your time/sell you bad goods. Big nameless companies tend not to care.

 

[GamerSoul]

I have a question..Are Link-List questions ever asked? Like for optimization?

 

[Phoenix]

I dunno. A bad recruiter can do a ton of damage to your search. But a good one can really cut out a bunch of the crap. But the thing is you have to have a recruiter you can really trust and hold acountable if they waste your time/sell you bad goods. Big nameless companies tend not to care.

As with most things it only really matters if you have a personal relationship with the recruiter themselves. I work with some and the ones that I get great candidates from are those that I know personally and have a good relationship with. The ones that just have a corporate relationship with us just send me piles of resume crap in the hope that 1 out of the 30 they send will be worth something.

 

[GamerSoul]

Yes, we're working with several recruiting agencies in the area, and we have phone screens prior to the face-to-face. I told my boss we might have to fire our phone screener.

(My boss is the phone screener.)

I don't know what gives, although we can certainly speculate. My boss feels he needs to change up his own screening tactics a bit, he thinks the recruiting companies are supplying the questions in advance. He's also well aware and even detects when candidates are actively googling the questions (he weeds those people out). We've even heard (a recruiter told me this directly) that some of the more shady agencies will have senior level developers take the phone screen for more junior level candidates (we don't think that's happened with us).

Whatever the reason, the candidates that have made it through the phone screens have so far faceplanted during the face-to-face. And, believe me, if I sent you the list of questions I was asking... well, you'd think we were being entirely too soft.

Ouch. I hope I'm not that bad. >.>

 

[SuperLurker]

So I had an interview today and only 1 question was asked. This was also the first interview that I've had in some time where I didn't actually write any code. I actually found it much more difficult to explain myself rather than just writing code. Thankfully it didn't go too bad and I have another interview with them later this week. It was a recruiter that got me the interview and they didn't give me any answers to anything beforehand, the only information they gave me was background info on the company.