Stop Lying!

24

Comments

  • sambuca69sambuca69 Member Posts: 262
    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?
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    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.
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    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
  • instant000instant000 Member Posts: 1,745
    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.
    Currently Working: CCIE R&S
    LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!)
  • instant000instant000 Member Posts: 1,745
    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?
    Currently Working: CCIE R&S
    LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!)
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    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.
  • shodownshodown Member Posts: 2,271
    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.
    Currently Reading

    CUCM SRND 9x/10, UCCX SRND 10x, QOS SRND, SIP Trunking Guide, anything contact center related
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    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_GAForsaken_GA Member Posts: 4,024
    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.
  • CodeBloxCodeBlox Member Posts: 1,363 ■■■■□□□□□□
    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!!!
    Currently reading: Network Warrior, Unix Network Programming by Richard Stevens
  • phantasmphantasm Member Posts: 995
    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.
    "No man ever steps in the same river twice, for it's not the same river and he's not the same man." -Heraclitus
  • PashPash Member Posts: 1,600 ■■■■■□□□□□
    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.
    DevOps Engineer and Security Champion. https://blog.pash.by - I am trying to find my writing style, so please bear with me.
  • SephStormSephStorm Member Posts: 1,731 ■■■■■■■□□□
    This thread has been really helpful, im going to have to review my resume tonight.
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    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.
  • shodownshodown Member Posts: 2,271
    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.
    Currently Reading

    CUCM SRND 9x/10, UCCX SRND 10x, QOS SRND, SIP Trunking Guide, anything contact center related
  • PashPash Member Posts: 1,600 ■■■■■□□□□□
    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.
    DevOps Engineer and Security Champion. https://blog.pash.by - I am trying to find my writing style, so please bear with me.
  • Panzer919Panzer919 Member Posts: 462
    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!
    Cisco Brat Blog

    I think “very senior” gets stuck in there because the last six yahoos that applied for the position couldn’t tell a packet from a Snickers bar.

    Luck is where opportunity and proper planning meet

    I have not failed. I've just found 10,000 ways that won't work.
    Thomas A. Edison
  • SephStormSephStorm Member Posts: 1,731 ■■■■■■■□□□
    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.
  • undomielundomiel Member Posts: 2,818
    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.
    Jumping on the IT blogging band wagon -- http://www.jefferyland.com/
  • it_consultantit_consultant Member Posts: 1,903
    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.
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    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.
  • instant000instant000 Member Posts: 1,745
    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...
    Currently Working: CCIE R&S
    LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!)
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    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.
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    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.
  • PashPash Member Posts: 1,600 ■■■■■□□□□□
    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.
    DevOps Engineer and Security Champion. https://blog.pash.by - I am trying to find my writing style, so please bear with me.
  • instant000instant000 Member Posts: 1,745
    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!
    Currently Working: CCIE R&S
    LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!)
  • HypntickHypntick Member Posts: 1,451 ■■■■■■□□□□
    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.
    WGU BS:IT Completed June 30th 2012.
    WGU MS:ISA Completed October 30th 2013.
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    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-NinjaNOC-Ninja Member Posts: 1,403
    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 icon_rolleyes.gif

    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 "?"
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    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.
Sign In or Register to comment.