Random Thoughts - Part III The Search for Spark (No Politics)

[Tcoat]

Originally Posted by soundman98

i'm becoming more and more convinced that any company that complains "we can't find anyone qualified" really means "we set our standards so impossibly high that literally no one meets those standards, but we can't admit to it"

Aren't you the same guy that complains about almost every single new guy that you ever have to train being totally useless and won't listen to you? Is that a to high standards issue.
No doubt that having too high a standard comes into play sometimes but far more often it is candidates that think the standard should be lowered to their level. I am sorry but no matter how well you did in school having 2 years experience doing AutoCAD work does NOT qualify you for a senior design engineer position.
So any company complaining the can't find anybody qualified actually may not be able to but still have to listen to many unqualified people complain that it isn't "fair" because they "want" that position and could learn it. If we are looking for trainees we will ASK for trainees.

[cjd]

Originally Posted by Dadhawk

Well, yea 11 interviews is excessive. I don't think I've ever had more that 3 for any job. Personally, I rarely call someone back for more than a second interview session (which could include more than 1 individual interview).

Hope things look up for you soon. We can't get candidates here, so when we do, we treat them gently!

Mentioned before, but she did find work finally a few months ago. I think that one was 11people, 7 interviews. Still nuts, but it seems to be the thing now

Originally Posted by NoHaveMSG

After 3 I would have told them, "I don't think you are the right company for me."

It seems all the rage now. Been part of a chain where they're doing 5 for fairly junior roles.

Originally Posted by spike021

For all you programmers out there, today I failed an interview for panicking and totally forgetting to question the value-types of the data I was working with.

i.e.

array: [["1230", "testing", ""], ["200", "testing3", ""], ["1230", "testing1", ""], ["2000", "testing", ""]]

Basically the first value is a timestamp in 2400 format. I had to sort first by the 2nd value (some word), and then sort by the first.

So I did a Python library sort with a lambda.

But I messed up one thing, I kept getting the list back in a different than expected order.

With that bug, I screwed up the rest of the interview.

The bug was... I was sorting the first values (the timestamps) as strings, not type-casting to integers.

24hr format it shouldn't matter unless it's not actually a proper timestamp, which would have to be 0200 not 200. That's an evil trick question. Not a good place to work anyway.
I'm not sure we have anything near you but would be happy to take a peek at your resume and dig through / keep an eye on postings.
I think other developers are half the problem. We've gotten into one-upping each other. Expecting candidates know exactly what we knew at a level and ignoring the guidelines.

[Capt Spaulding]

Originally Posted by spike021

Thanks, will let you know. I've got a few more in the pipeline and then I'll probably take a couple weeks to re-coup a bit and prep some more.

Riffing a bit on humfrz comment, it sounds like a bit of a confidence problem. Several years ago my son got an SE job with one on the Seattle tech monsters. He and I talked about the interview process a lot. My advice was, “you know what you’re doing, allow yourself to show them that.

I spent years counseling prospective law students about the LSAT. One thing that I told each of them was, “if you let it, test anxiety will steal 10 points from you. Don’t let it. If necessary, become a Buddhist for 6 months. Life is a process, all each of us can do is the best job we can. That’s it. Focus on the process, know your shit, focus on the problem. Worrying is your enemy.”

Racing motorcycles made me a closet Buddhist. I learned a lot of things. The most important were 1. You go where you focus. So focus on the apex and then move on to the exit. 2. Don’t panic. Work the problem. You’ll overcome it or you won’t. Your best is the best you can do. Allow yourself to do it.

Just remember, relax, stay calm, be you, they are their problem, not yours.

[Dadhawk]

Originally Posted by spike021

For all you programmers out there, today I failed an interview for panicking and totally forgetting to question the value-types of the data I was working with.

I'm not a fan of these type of practical tests, particularly if they are done under an unreasonable time constraint or, worse, done live with people watching. Most people, particularly coders, don't work that way.

Well, unless you are on some CSI/NCIS type show on TV where you can stop massive attacks or hack into an government system with a few dozen key strokes.

I started off my career as a programmer. My second job I wrote a series of quasi-stand alone software packages for the hospital industry that sold relatively well for my company. The fact that I could prove my skills just on my resume should be good enough.

(Well, not now, I haven't written a full program in 15 years or more, and most of it was in languages that are no longer in vogue, not that matters, a programmer is a programmer, give them a reference book and they can figure it out).

If hiring Level 1, the person probably can't do this stuff under pressure because they are new outside academia. If they are a higher level, then their resume and references should tell you if they are good enough. Make them talk at a higher level about the code they've written, the bug that it took them the longest to squish, that type of thing and you can get a good feel for them.

Even now, where I'm hiring network engineers, data center system engineers, end user support techs, and service desk techs, I have my team spend less than 25% of the interview on technical knowledge and 75% on cultural fit, professional background and "conversation".

[humfrz]

Originally Posted by Dadhawk

I'm not a fan of these type of practical tests, particularly if they are done under an unreasonable time constraint or, worse, done live with people watching. Most people, particularly coders, don't work that way.

Well, unless you are on some CSI/NCIS type show on TV where you can stop massive attacks or hack into an government system with a few dozen key strokes.

I started off my career as a programmer. My second job I wrote a series of quasi-stand alone software packages for the hospital industry that sold relatively well for my company. The fact that I could prove my skills just on my resume should be good enough.

(Well, not now, I haven't written a full program in 15 years or more, and most of it was in languages that are no longer in vogue, not that matters, a programmer is a programmer, give them a reference book and they can figure it out).

If hiring Level 1, the person probably can't do this stuff under pressure because they are new outside academia. If they are a higher level, then their resume and references should tell you if they are good enough. Make them talk at a higher level about the code they've written, the bug that it took them the longest to squish, that type of thing and you can get a good feel for them.

Even now, where I'm hiring network engineers, data center system engineers, end user support techs, and service desk techs, I have my team spend less than 25% of the interview on technical knowledge and 75% on cultural fit, professional background and "conversation".

[p1l0t]

Originally Posted by spike021

For all you programmers out there, today I failed an interview for panicking and totally forgetting to question the value-types of the data I was working with.

i.e.

array: [["1230", "testing", ""], ["200", "testing3", ""], ["1230", "testing1", ""], ["2000", "testing", ""]]

Basically the first value is a timestamp in 2400 format. I had to sort first by the 2nd value (some word), and then sort by the first.

So I did a Python library sort with a lambda.

But I messed up one thing, I kept getting the list back in a different than expected order.

With that bug, I screwed up the rest of the interview.

The bug was... I was sorting the first values (the timestamps) as strings, not type-casting to integers.

So they failed you for some quotes. Like that type of thing doesn't happen and get fixed 7x a day...

Sent from my SM-G975U using Tapatalk

[Tcoat]

Originally Posted by p1l0t

So they failed you for some quotes. Like that type of thing doesn't happen and get fixed 7x a day...

Sent from my SM-G975U using Tapatalk

He is assuming they did. They may have not wanted him because he looks goofy, had bad breath, is too young, too old or a hundred other reasons.

[p1l0t]

Originally Posted by Tcoat

He is assuming they did. They may have not wanted him because he looks goofy, had bad breath, is too young, too old or a hundred other reasons.

That's why you work remote

Sent from my SM-G975U using Tapatalk

[Dadhawk]

Originally Posted by p1l0t

That's why you work remote

You flying drones these days?

[p1l0t]

Originally Posted by Dadhawk

You flying drones these days?

Ha I should be

Sent from my SM-G975U using Tapatalk

[spike021]

Originally Posted by p1l0t

So they failed you for some quotes. Like that type of thing doesn't happen and get fixed 7x a day...

Sent from my SM-G975U using Tapatalk

Well, if they do fail me it'd probably be more because I didn't notice that was the problem causing the code to work incorrectly. Which would make me look like I'm bad at debugging buggy code. Which, in that context sure I am. But then I figured it out on my own without someone watching my every move so .

It's more like interviews like these can have a bunch of factors to be judged on. Sometimes it comes down to nitpicky interviewers.

That's what's frustrating lately. I know I've done well on a few of these the past couple weeks and solved the problems, but I had some minor bugs while solving them and most likely that was enough to get the thumbs down. Some people care and some don't.

[p1l0t]

Originally Posted by spike021

Well, if they do fail me it'd probably be more because I didn't notice that was the problem causing the code to work incorrectly. Which would make me look like I'm bad at debugging buggy code. Which, in that context sure I am. But then I figured it out on my own without someone watching my every move so .



It's more like interviews like these can have a bunch of factors to be judged on. Sometimes it comes down to nitpicky interviewers.



That's what's frustrating lately. I know I've done well on a few of these the past couple weeks and solved the problems, but I had some minor bugs while solving them and most likely that was enough to get the thumbs down. Some people care and some don't.

Yeah but bugs are normal part of the process that's why we do test. I'm not sure they are expecting you to debug in a live interview though.

Sent from my SM-G975U using Tapatalk

[spike021]

Originally Posted by p1l0t

Yeah but bugs are normal part of the process that's why we do test. I'm not sure they are expecting you to debug in a live interview though.

Sent from my SM-G975U using Tapatalk

Most of the time they do expect it, in my experience.

I actually wrote this up on twitter the other day lol. But here's kind of how things go:

1. They say they want to know if you can write code that compiles and runs.
2. They want to know that you know your algorithms and data structures.
3. We want to test that you can work with people, debug code, pair program.

I've had a few interviews now where IMO I did all three. One of them the guy even told me "that's the approach and algorithms/data structures I would use", and for one bug he offered himself to double check it for me while I was focused on another part of the code. The code compiled and ran fine, got the correct results, etc. Then this week I got the rejection email.

[soundman98]

Originally Posted by Tcoat

Aren't you the same guy that complains about almost every single new guy that you ever have to train being totally useless and won't listen to you? Is that a to high standards issue.
No doubt that having too high a standard comes into play sometimes but far more often it is candidates that think the standard should be lowered to their level. I am sorry but no matter how well you did in school having 2 years experience doing AutoCAD work does NOT qualify you for a senior design engineer position.
So any company complaining the can't find anybody qualified actually may not be able to but still have to listen to many unqualified people complain that it isn't "fair" because they "want" that position and could learn it. If we are looking for trainees we will ASK for trainees.

sometimes it's best to be a pot-shaped kettle.