Stop Lying!

I have to vent.

Alright, here is the thing. I run technical interviews for engineers for my company. And I personally run an paid intern department. So clearly I do a lot of interviews. Especially as we are on a hiring spree right now.

I am sooo sick of half truths and lies on resume. I have become quite angry when I walk into an interview I am running.

1) So a guy I am interviewing for a tier level 1 system admin spot have "Linux" as a job skill listed and under his work experience "administed a cluster of Apache servers under Debian" for two years.

So I spun my laptop around and asked him to set the ip address on my laptop (runs Ubuntu 10.04) he then stated "that wasn't really his area". The jerk has Linux+ on his resume too!

2) Interviewing for an another level 1 lan operations, but we needed some minor CCNA level Cisco skills. The guy goes on about he is "starting his CCNP" and how he installed DS3 lines and bla blah. So I asked him "How do you backup a router config?". He had some dance here and I gave him another chance "Tell why you use a vlan?" he then went on about how design wasn't something he did. Sigh...

3) Desktop support guy, A+ and MCDST cert I asked him "what does msconfig do?" he didn't know. I asked him what tools he had used to for malware and all he said was Symantec. Lastly he had "highly experienced in Ghost" so I asked him how ghost worked? He had no idea.

I am just saying be honest. I would rather hire someone who had a simple honest resume than a boat full of lies and half truths. I have left spots unfilled for months now because of these people.

Anyhow, I am interviewing for a senior engineer spot next month. I was thinking of setting up a basic router on a stick and asking the guy to explain it. Any other reasonable ideas?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

sambuca69

RobertKaucher wrote: »

I have a section in my resumes for things that I have exposure to but at which I am not skilled (Java, PHP, MySQL).

Just curious, but how exactly do you list/separate the 2 on a resume?

RobertKaucher

instant000 wrote: »

RobertKaucher:

You are correct in that the questions aren't detailed enough, but I'm not going to pretend to be an SQL expert. (As you appear to be.) In my case, if I was answering that question, I would admit what my limitations were. I guess I can read that like a devil's advocate, and say that I did not grill the person well enough (which would be true, as the interviewer asked something general, when he/she actually needed something specific). Hopefully, I would not be tasked to interview a DB person, LOL, as I apparently failed horribly at it (admitting my lack of knowledge here).

Well, failing at something for which you are not trained to do/do not have the knowledge for is nothing to be ashamed of. Even when you know your stuff picking the right person can be highly influenced by random factors. I believe this is why it's good to have connections so that you can get some advice from people in the given field about what you should ask and the kinds of answers you should be expected to get in return. But, you are right, you needed a DBA and you just got a DB.

RobertKaucher

sambuca69 wrote: »

Just curious, but how exactly do you list/separate the 2 on a resume?

In this instance it looks like this:

Languages

Proficient in: C#, PowerShell, T-SQL, Silverlight 4
Familiar with: VB .NET, Java, Perl, MySQL, PHP

instant000

RobertKaucher:

Just to be clear, it was just a scenario with the backup admin. The scenario with the MS-SQL guy is based on a true story.

Sambuca69:

I'm also curious about that.

Of course, it would do me no good with some recruiters ... I'm sorry, but installing an application by following a wizard is not the same as developing for that same application. Also, migrating Small Business Server does not make me a DBA candidate ( it might make me a good candidate for a team that performed small business migrations).

It is okay for humans who read the resume, but some recruiters (note, I said some, not all) ... just have me shaking my head with the unreasonable jobs they somehow match to my resume. As if they searched for keywords, dumped a list of resumes, and just emailed indiscriminately ... not bothering to read the words in a sentence.... sad.

instant000

RobertKaucher wrote: »

In this instance it looks like this:

Languages
Proficient in: C#, PowerShell, T-SQL, Silverlight 4

Familiar with: VB .NET, Java, Perl, MySQL, PHP

I like this format, and I'm going to use it, OK?

Forsaken_GA

eansdad wrote: »

So, just how much should you know before listing something on your resume? Case in point, I have written some scripts in vb but only know basics. Should vb be listed as a skill?

My general rule of thumb is that, if i need to use google when performing a process, configuring something, or whatever, more than ONCE (and I allow for the once being a necessity because documentation isn't always up to date), then I probably shouldn't be listing it on my resume.

Now, with that being said, I personally understand that there's a difference between technical ability, and being really good at trivial pursuit. If a candidate is describing a process to me, and doesn't get the syntax entirely 100% correct, I won't ding them for that, I understand that in the real world, you're going to have reference material. Y'all are using databases and backups and such, I'd ask something like describe how you'd go about setting up your internal routing structure to prefer one particular BGP link for egress traffic over another one.

If they know the answer, they'll be able to work through the process, even if they're not entirely correct, I can get a pretty good idea of their knowledge level.

If they don't, then they won't have a clue where to begin answering that question, and they'll either tell me so, or they'll decide to bullshit me. I've been able to refine my pool of interview questions to go just a bit beyond anything they may have read in a Cisco Press book, in order to avoid getting rote memorization regurgitated back to me, but I'm not going to be punishing enough to ask them questions about Banyan VINES. A good interviewer knows how to be tough, but fair.

shodown

In my IT years, I've always added a little bit of spice on my resume, but everytime I've been in the job hunt I start my....Naw can't tell you where I put my extra player card. Needless to say if you have it on your resume you need to be able to back it up. People want hits and have learned that most of the time its being done by computer.

RobertKaucher

Forsaken_GA wrote: »

My general rule of thumb is that, if i need to use google when performing a process, configuring something, or whatever, more than ONCE (and I allow for the once being a necessity because documentation isn't always up to date), then I probably shouldn't be listing it on my resume.

Now, with that being said, I personally understand that there's a difference between technical ability, and being really good at trivial pursuit. If a candidate is describing a process to me, and doesn't get the syntax entirely 100% correct, I won't ding them for that, I understand that in the real world, you're going to have reference material. Y'all are using databases and backups and such, I'd ask something like describe how you'd go about setting up your internal routing structure to prefer one particular BGP link for egress traffic over another one.

This is really true. And there are somethings that a strong knowledge of should send up a red flag. If a midlevel DBA knows every option of the DBCC commands I am going to start asking more questions. My first thought is going to be, "Does this guy know this command so well because he makes a habit of fubaring his environment and needs to save his own @$$ on a regular basis?" If I were an AD admin and I were interviewing someone and he seemed to know ntdsutil really well, I would be asking similar questions.

IMO, there are somethings you just should not know well based on hands on knowledge (unles you are a consultant specializing in disaster recovery of said technology). They are complicated enough and used so infrequently in healthy environments that you*should* be checking the documnetation before you use them.

Forsaken_GA

RobertKaucher wrote: »

My first thought is going to be, "Does this guy know this command so well because he makes a habit of fubaring his environment and needs to save his own @$$ on a regular basis?"

Now, the inverse to that is 'does he know it because he's made a habit of having to pull someone else's fat out of the fire?'. Several things I know, I've learned because I had to save the bacon due to others ineptitude.

You're entirely correct though, that you need to be able to determine which one it is. I always try to figure out if I'm talking to a super hero, a zero, or a cowboy.

CodeBlox

Man, thats a shame those folks couldn't answer those questions. Seems like I could have gotten that job. It's a shame I still haven't been given a chance!!!

phantasm

CodeBlox wrote: »

Man, thats a shame those folks couldn't answer those questions. Seems like I could have gotten that job. It's a shame I still haven't been given a chance!!!

Keep it up. It took me 7yrs for my first IT position. lol.

Pash

I have to ask why you guys don't do technical screening first of all to see how quickly people think on their feet and then if you still need to be 100% sure you could set them up a small test lab or something when they come in to see you.

I am not sure how things are in the states currently but over here there is a massive skill deficit in the IT juniors applying for jobs. They will often get tips from their college mentors for putting "popular" search keywords on their CV's. This of course is morally incorrect especially if they tie this in with past job roles/experiences but remember there are several others looking for jobs and they are looking to remain competitive. You have done your job by catching these people out but it sounds like you have wasted too much of your time on doing so.

Maybe you need to be clear about what you need and test them on that rather than throwing random things to them that they have put on their CV. Some engineers can think quickly and use google searches very well to sort issues out for Level 1 positions. While I agree that people shouldnt lie on their CV's about their skillsets and experiences unfortunately they are kind of being vetted into telling untruths to get ahead of others.

SephStorm

This thread has been really helpful, im going to have to review my resume tonight.

Turgon

Pash wrote: »

I am not sure how things are in the states currently but over here there is a massive skill deficit in the IT juniors applying for jobs. They will often get tips from their college mentors for putting "popular" search keywords on their CV's.

I put this down to a number of factors.

About 20 years ago I got some assist from a University IT administrator when I was a student. She explained that she didn't have qualifications in BIS as she was a 'computer scientist', and that 'it was all easy now'. There is a lot in what she said. The drive for plug and play and easy applications has really punished those who wish to work on the practitioner side of the IT shop. The work is seen as easy and the expectations of end users on technology completely skewed. There has been an argument, somewhat justified because of this trend, to focus learning on the use of things as opposed to deep understanding of the rudimentary mechanics supporting the use. I dont blame the kids for this and I appreciate neither do you.

This is why I encourage anyone working in IT to obtain at least some formal instruction in mathematics, electronic engineering, physics, any engineering discipline, statistics, programming, operating system theory and algorithms, digital techniques particularly hardware and networking theory at the packet level. Some exposure to UNIX is good particularly sockets theory.

shodown

Turgon wrote: »

I put this down to a number of factors.

About 20 years ago I got some assist from a University IT administrator when I was a student. She explained that she didn't have qualifications in BIS as she was a 'computer scientist', and that 'it was all easy now'. There is a lot in what she said. The drive for plug and play and easy applications has really punished those who wish to work on the practitioner side of the IT shop. The work is seen as easy and the expectations of end users on technology completely skewed. There has been an argument, somewhat justified because of this trend, to focus learning on the use of things as opposed to deep understanding of the rudimentary mechanics supporting the use. I dont blame the kids for this and I appreciate neither do you.

This is why I encourage anyone working in IT to obtain at least some formal instruction in mathematics, electronic engineering, physics, any engineering discipline, statistics, programming, operating system theory and algorithms, digital techniques particularly hardware and networking theory at the packet level. Some exposure to UNIX is good particularly sockets theory.

Never thought about this. Interesting view. I did a lot of electronic theory years ago when I was in the military, never thought about how much it applied today, but now that you mentioned it, thinking about subnetting it nothing more than a digital gate in some form making a decision.

Very, Very, Very Interesting view.

Pash

Turgon wrote: »

I put this down to a number of factors.

About 20 years ago I got some assist from a University IT administrator when I was a student. She explained that she didn't have qualifications in BIS as she was a 'computer scientist', and that 'it was all easy now'. There is a lot in what she said. The drive for plug and play and easy applications has really punished those who wish to work on the practitioner side of the IT shop. The work is seen as easy and the expectations of end users on technology completely skewed. There has been an argument, somewhat justified because of this trend, to focus learning on the use of things as opposed to deep understanding of the rudimentary mechanics supporting the use. I dont blame the kids for this and I appreciate neither do you.

This is why I encourage anyone working in IT to obtain at least some formal instruction in mathematics, electronic engineering, physics, any engineering discipline, statistics, programming, operating system theory and algorithms, digital techniques particularly hardware and networking theory at the packet level. Some exposure to UNIX is good particularly sockets theory.

As always I hear you Turgz. I definitely do not have any advanced instruction in any of those subjects at all and this is something I am trying to remedy in my own personal time because of the exact reasons you have just stated.

It is true to say as most of us on these boards will state that to be a good support engineer you just need to be good at performing google searches and reading documentation. Just having good communication abilities can be a paramount skill when troubleshooting issues with 3rd party vendors.

In my own personal experience I have been very lucky in the amount of projects I have been involved with over the last few years. I am definitely not at an Architect level (I also would never be intelligent enough to be) but I can certainly help you (as an example) perform a Windows domain migration from 2003 to 2008 with minimal stress simply because I have put time into reading and doing in Virtual Environments and then performing in real world environments.

I know we do have people on these boards who can recite information from rfc's as part of their day job but at what level of skills are we talking about? Are we talking about the youth of today making their own rfc's and designing their own technology? Or just learning principals to help them support said technology better? You have an issue at the network level, do you install wireshark and spend time looking at packets or do you google the symptoms and find a solution just as quickly? What makes you the better support engineer?

Good Topic.

Panzer919

rsutton wrote: »

Completely agree. Admitting you do not know something takes courage, but the reward is trust, which is of much higher value.

I did this in my interview with my current company. There were a lot of things I knew just from the network academy labs but had not really done it in a live environment. I just admitted it and I was offered the job.

Never sacrifice Integrity or Trust, especially in our industry. I don't know about other areas of the country but I know here in Cincinnati it seems everyone knows everyone. It WILL come back to bite you in the rear!

SephStorm

Turgon wrote: »

I put this down to a number of factors.

About 20 years ago I got some assist from a University IT administrator when I was a student. She explained that she didn't have qualifications in BIS as she was a 'computer scientist', and that 'it was all easy now'. There is a lot in what she said. The drive for plug and play and easy applications has really punished those who wish to work on the practitioner side of the IT shop. The work is seen as easy and the expectations of end users on technology completely skewed. There has been an argument, somewhat justified because of this trend, to focus learning on the use of things as opposed to deep understanding of the rudimentary mechanics supporting the use. I dont blame the kids for this and I appreciate neither do you.

This is why I encourage anyone working in IT to obtain at least some formal instruction in mathematics, electronic engineering, physics, any engineering discipline, statistics, programming, operating system theory and algorithms, digital techniques particularly hardware and networking theory at the packet level. Some exposure to UNIX is good particularly sockets theory.

Obviously this makes sense. But as a hands on guy, I have to defend myself a bit.

I am a fan of hands on application of ideas, concepts, and what not. I've never seen myself as a college type computer science guy who knows the theory behind making silicon chips. Obviously those people are necessary, but I dont think I need to be one of those people. During the recent downturn in the American economy, we saw people graduating colleges with degrees, and as I would say, the "deep theory", companies needed people who could preform immediately.

Some of those things you mention (mathematics, physics, statistics, operating system algorithms, anything involving math), I will never probably get even close to becoming proficient at, but I dont think that should make me a second tier professional.

undomiel

Pash wrote: »

You have an issue at the network level, do you install wireshark and spend time looking at packets or do you google the symptoms and find a solution just as quickly? What makes you the better support engineer?

One would say knowing how to tell the difference between when you should google and when you should wireshark would be the sign of a better support engineer. From the people I've worked with most would just google and then throw up their hands after trying every odd ball trick they found that seemed even distantly related.

it_consultant

undomiel wrote: »

One would say knowing how to tell the difference between when you should google and when you should wireshark would be the sign of a better support engineer. From the people I've worked with most would just google and then throw up their hands after trying every odd ball trick they found that seemed even distantly related.

Google is my best friend, I see the opposite problem. People banging their head against the wall trying to fix something when all they have to do is research the problem a little bit. If google was a big tech manual I am sure the attitude would be different. MSexchange.org, technet, technet blogs, and experts exchange have saved me and my clients many times. Even Medical Doctors refer to their journals and texts.

My last research was why in Exchange / Outlook 2010 when you remove additional mailboxes in outlook, they reappear in the folder tree. Turns out this is a behavior MS included in Exchange so that when people were given rights to other mailboxes, outlook would automatically configure itself, in an attempt to ease administrative burden. The only way to stop this behavior is to modify the properties of the target mailbox with ADSI edit. How long would it have taken me (and how many mailboxes would I have screwed up in the process) before I figured that out on my own?

I would be more likely to hire an engineer who openly admits they use the above resources when they troubleshoot a problem they have never encountered before.

RobertKaucher

undomiel wrote: »

One would say knowing how to tell the difference between when you should google and when you should wireshark would be the sign of a better support engineer. From the people I've worked with most would just google and then throw up their hands after trying every odd ball trick they found that seemed even distantly related.

I google while I'm taking my trace. WireShark is one app I would really like to improve my skills on. But even though I am more on the dev side now you would be shocked at how often we end up sharking to see why something is broken.

instant000

Forsaken_GA wrote: »

Now, the inverse to that is 'does he know it because he's made a habit of having to pull someone else's fat out of the fire?'. Several things I know, I've learned because I had to save the bacon due to others ineptitude.

You're entirely correct though, that you need to be able to determine which one it is. I always try to figure out if I'm talking to a super hero, a zero, or a cowboy.

Hah, funny.

Had a phone interview a couple months ago, and the guy asked me what the purpose of "eseutil" was. I told him it was for doing database maintenance, such as log file replay and offline degragmentation. (a microsoft exchange utility) He said that no one else he'd interviewed even knew what the command was. He even made the remark "I guess no one else is breaking Exchange servers like you are." With all that said, I got the job offer, but significant other wasn't willing for me to go back to the sand box. That deal was paying $160k though...

Turgon

Pash wrote: »

As always I hear you Turgz. I definitely do not have any advanced instruction in any of those subjects at all and this is something I am trying to remedy in my own personal time because of the exact reasons you have just stated.

It is true to say as most of us on these boards will state that to be a good support engineer you just need to be good at performing google searches and reading documentation. Just having good communication abilities can be a paramount skill when troubleshooting issues with 3rd party vendors.

In my own personal experience I have been very lucky in the amount of projects I have been involved with over the last few years. I am definitely not at an Architect level (I also would never be intelligent enough to be) but I can certainly help you (as an example) perform a Windows domain migration from 2003 to 2008 with minimal stress simply because I have put time into reading and doing in Virtual Environments and then performing in real world environments.

I know we do have people on these boards who can recite information from rfc's as part of their day job but at what level of skills are we talking about? Are we talking about the youth of today making their own rfc's and designing their own technology? Or just learning principals to help them support said technology better? You have an issue at the network level, do you install wireshark and spend time looking at packets or do you google the symptoms and find a solution just as quickly? What makes you the better support engineer?

Good Topic.

Well I think it's more my approach to my career and my work in general that got me to Architect level than being some kind of Mr Big Brain to be honest. The access you have to project work will help you reach for that kind of role if it's really what you want to do in future. Personally I think theres much more to be being a good support engineer than simply being good at data mining information. You need to be good at understanding what you need to look for and you also need to be good at making sense of what comes back. In some senses this is learned on the job but I do think education makes it easier to be good at that. The other thing is once you get into design work it becomes harder to find vanilla solutions for your work by searching. The environments are mixed, bespoke and have a particular history.

For my part I have had a lot of education over the years in many of the things listed. While I wasn't top of the class at any of it and at the time didn't understand some of it I have still been educated. It helps. I recall several weeks elasping before class was done with TCP. We had entire lectures dedicated to each layer of the OSI model back in 1994. Later as my career progressed I found context for things I had been taught years back. I work with someone who is mathematically trained and experienced hands on with networks. No Cisco qualifications at all and that means some of the features the certification tracks cover are an unknown to him but even so, with his logical training Im confident he can learn any protocol he needs to.

A lot of things I learned I forgot or found no direct application for, but it trains your brain which is a good thing. Also, given that almost everything reduces to a binary or logic process, some micro awareness helps I think. Once you get into heavyweight networking you are looking at things like light wavelengths and latency in great detail. But I think as technology has advanced the abstraction newcomers have from the nitty gritty in their day to day job can leave them behind in the employability stakes. There is a reason why wireless, QoS and multicast give so many people difficulty to learn.

Should I find time I will write a small book entitled Network Calculations. It will cover lots of things network professional wannabees will find useful I think.

Turgon

SephStorm wrote: »

Obviously this makes sense. But as a hands on guy, I have to defend myself a bit. I am a fan of hands on application of ideas, concepts, and what not. I've never seen myself as a college type computer science guy who knows the theory behind making silicon chips. Obviously those people are necessary, but I dont think I need to be one of those people. During the recent downturn in the American economy, we saw people graduating colleges with degrees, and as I would say, the "deep theory", companies needed people who could preform immediately.

Some of those things you mention (mathematics, physics, statistics, operating system algorithms, anything involving math), I will never probably get even close to becoming proficient at, but I dont think that should make me a second tier professional.

Im hands on myself. You need not become proficient much less a PhD in these areas to feel some benefit. Any exposure can be helpful. There are plenty of light reading materials on all these subjects.

Pash

RobertKaucher wrote: »

But even though I am more on the dev side now you would be shocked at how often we end up sharking to see why something is broken.

Finally - devs I would wan't to work with. I work with some that have a rule along the lines of "when it hit's the stack it aint my problem" which is about as useful as a chocolate teapot.

instant000

Turgon wrote: »

Should I find time I will write a small book entitled Network Calculations. It will cover lots of things network professional wannabees will find useful I think.

Make sure to give a techexams.net member discount!

Hypntick

undomiel wrote: »

One would say knowing how to tell the difference between when you should google and when you should wireshark would be the sign of a better support engineer. From the people I've worked with most would just google and then throw up their hands after trying every odd ball trick they found that seemed even distantly related.

I will Google like a mad man if no one else has seen it. If that fails, i'll call whatever vendor the issue is with. They'll know their product (hopefully) way better than I ever will. Calling the vendor will not only resolve the issue, but it shows me the proper way to fix the issue in the future if it comes back up.

RobertKaucher

Pash wrote: »

Finally - devs I would wan't to work with. I work with some that have a rule along the lines of "when it hit's the stack it aint my problem" which is about as useful as a chocolate teapot.

Well, how often is it the network, really? Of all the issues I have seen here only one was caused by something out of our control on the network. It was some network device that was fiddling at the application layer. WireShark was actually useless except to tell us that the packets were not making it to the other subnet. We tested by wrapping the same traffic in SSL and it worked. So then we tried binary encoding and it worked and was fast, network team never needed to be consulted.

But this gave us some information that when the network team says they do not filter internal traffic we know that is not accurate. Something was messing with the web service's traffic until it was wrapped in a format that it was not able to understand. We believe it was the Riverbed, but it's all speculation on our part.

NOC-Ninja

Ahriakin wrote: »

I had a supposed CCNP tell me flat out that you don't put IP addresses on routers since they route transit traffic and don't need ones of their own

Nowadays I do a quick 30 min phonescreen to cover some basics and their resume and then it's straight into a remote CLI based lab. It's open book on their side so it doesn't get caught up in the minutiae that verbal questioning can, they can either walk the walk or limp away.

wow your nice giving them an open book. They can use "?"

Turgon

NOC-Ninja wrote: »

wow your nice giving them an open book. They can use "?"

Some people dont even know how to use '?', and a lot of people dont know the command to run before you need the options the '?' gives you.

Ask people about how to configure a sdm profile and they usually zone out.