Because we are coming up so quickly on Cisco Live 2013 in Orlando, and because it is a Sunday evening and I cannot find a single thing I am motivated to write about, I decided to build a photo gallery of some of my photos from last year’s Cisco Live conference in San Diego. Some of these photos are blurry; some are of things you don’t care about; others are of people you do not know. That being said, please enjoy and I look forward to reuniting with the social media crew in a few short weeks.
DisneyWorld Discounts for CLUS Attendees
May 21, 2013 by 1 Comment
My wife and I were reviewing our post-Cisco Live plans (hint: we’re Disney junkies) and came across a nifty deal that we were unaware of. We’ve already made our plans, but this might be useful to some of you out there who may be thinking about visting the mouse during or after Cisco Live in Orlando.
http://www.mydisneymeetings.com/cl13/
Some good deals there exclusively for Cisco Live attendees. Maybe your spouse or significant other wants to have something to do during the day, or maybe you want to hit some parks before or after the convention. Either way, check it out.
Incoming search terms for the article:
Cisco Live – Convincing your Boss to Send You
May 3, 2013 by Leave a Comment
“Knowledge has to be improved, challenged, and increased constantly, or it vanishes.” Peter Drucker
One of the questions that gets asked a lot when people find out that I go to the Cisco Live convention every year is, “How in the world did you convince your boss to send you?!” To be fair, that question gets asked more often in certain years than others, like when the convention is in Orlando, as it is this year. If the convention was in Juneau, Alaska in January I don’t think I’d get as many questions.
That said, the question is relevant because I know plenty of people who would love to attend and quite simply can’t get their boss to approve the expense. These are not companies where a revolving few members of the network team get to go each year and maybe your number will be up next year. These are companies where the predominant culture is “we don’t waste money on trade shows.” It’s a deeply flawed sentiment, but one that is, unfortunately, somewhat common outside of the Value-added Reseller (VAR) and manufacturer space.
Why? I think it has to do with way trade shows have historically been marketed to the masses–as giant 24/7 parties with free-flowing liquor, late night debauchery, high-profile musical performances and the like. Even Cisco is guilty of this, emphasizing the “fun” aspect of the convention and downplaying (at least in marketing materials) the seriousness of the convention as a learning experience.
That is unfortunate, because the Cisco convention is much more than just a fun time (although it is that as well). In fact, if you work primarily, or even significantly, with Cisco technologies in your day-to-day life, this is the most bang for your training-buck you’ll find anywhere.
Why?
There are a lot of reasons to go, but I’ll list just a few below:
- Thousands of training sessions over the course of the week, all taught by experts, Cisco employees, Cisco Press authors, etc. Where else are you going to meet all of the authors of Cisco Press materials, or the designers of some of the protocols you use on a daily basis?
- Access to Cisco engineers via Cisco’s Meet-the-Expert program. You can schedule a meeting with high-level Cisco engineers in a specific area of expertise and “white-board” out problems you’re having. Last year, for instance, I worked with an engineer to validate a large-scale routing restructure I had planned for my corporate network. The planning and review session was absolutely invaluable; and as a result the project went off without a hitch.
- What I’ll call the “floor show” and what Cisco calls the World of Solutions. This is where hundreds of vendors set up booths and show off the latest and greatest technology within the Cisco ecosystem.
- Peer-group networking. The connections and friends I’ve made over the years at Cisco Live have proven invaluable time and time again. I have a large cohort I can turn to with problems, and I usually find the information I need from them well before I need to turn to any other method. Thousands of people who do what you do, all in one place, at one time. The value of that simply cannot be overstated.
At the end of the day, you’re going to find yourself working for one of two kinds of employers, and I’ve worked for both:
- The kind who values your input as an expert in your field; who values what you bring to the table and see Cisco Live as a further investment; not only in you, but in their own business. These employers value training, they value life-long learning, and they generally want their people to succeed even if it’s at a different company.
- The kind who see you as a cog, as a cost center, as something to be managed. These employers tend to undervalue continuing education, and assume that everything you learned in college is all you’ll ever need. They give lip-service to learning, but at the end of the day you’ll go years with limited training, and no approval to attend events like Cisco Live.
As the IT Manager of a multi-national company, with a whole IT team reporting to me, I can tell you that I do everything I can to be the type of boss who helps my team to succeed. I attend this conference yearly, and I advocate that my team members all attend relevant trade-shows and educational seminars annually. I also try to get quarterly training approved as well.
At the end of the day, there are other things you can and should do to learn; things like reading white papers, attending web seminars, trying to build a real or virtual lab for more hands-on experience. I would suggest to you now, however, that if you aren’t being allowed to attend trainings and trade shows like Cisco Live, you’re probably in the wrong position at the wrong company.
I personally negotiate attendance at Cisco Live as a condition of employment because of what I do and how valuable my knowledge and career are to me. The day I’m working for a company that doesn’t value those same things is the day I move elsewhere.
Incoming search terms for the article:
- cs co
- waht to go at cisco live
- cost to attend cisco live
- when di cisco networkers become cisco live
- what to wear to cisco live
- need cisco live orlando customer appreciation event 2013
- cancer displayed next to your comments not displayed publicly if you have a website link to it here
- ciscolive party 2013
- cisco live orlando parties
- cisco live find friends
Cisco Networkers/Live Breaking News
May 3, 2013 by 1 Comment
Transformers
Incoming search terms for the article:
ASA Upgrade to 9.0(2)
April 9, 2013 by Leave a Comment
“In theory there is no difference between theory and practice. In practice there is.” Yogi Berra
Usually, no matter how much planning, testing, thinking about, or stalling you build in to an upgrade project, the bill comes due at the end and isn’t what you expected. Maybe someone ordered the lobster, or multiple drams of Johnny Walker Blue, but either way you have a situation to deal with… right now. How you deal with it determines many things about your skills and your character, but that’s for another post as I’m going to try my best to keep this one short and to the point.
I recently had the wonderful experience of upgrading an Active/Passive failover pair of ASA units to the newest of the new code, 9.0(2) from 8.4.2(8). After the 8.3 kerfuffle (NAT changes automagically, anyone?) I was particularly keen to not miss any possible gotchas in this upgrade. I also scheduled a larger than usual maintenance window–even though we didn’t expect any downtime–just in case.
I should interject here, for those of you aghast at the thought that we would possibly implement new, some would say, bleeding edge code on production systems, a couple of things:
- We always run bleeding edge code, usually because we have need of the bleeding edge features the code brings. In this case, IPv6 features sorely lacking in prior code versions
- We have adopted a very aggressive IPv6 stance, as I have written about before, and we tend to find our aspirations and designs are well out in front of significant portions of the code available for our equipment
- Noting the prior two items again, I’ll also add that Firewalls, in particular, seem to have code that is months or years behind the route/switch world. That holds true across all vendor platforms. Why? I don’t know, but that’s another post.
With our need-for-upgrade bona fides established, I dutifully read the entire Release notes for the 9.0(x) ASA code and while I was excited at many of the new features–mostly around IPv6–and disappointed at others (No OSPFv3 address families? Really?) something immediately jumped out at me: Page 19 and its disturbing title, “ACL Migration in Version 9.0″
Any time you see the word “migration” in any documentation referring to an upgrade of production code or configuration, you know two things:
- It probably happens auto-magically, which is basically a synonym for “we’re going to bork your code but we’re only going to loosely tell you where, how, and why.”
- You’d better have good backups and be prepared, because a roll-back is likely going to be as painful as just plowing ahead.
To summarize the boring details for you, prior to the new code you had two categories of Access Control Lists (ACLs): those for IPv4 and those for IPv6. Inside each of those macro-levels you had the normal standard and extended lists and whatever other features. You applied the IPv4 and the IPv6 access-lists to the interface in whatever direction and that was that. True to the dual-stack model, you really were running two parallel networks and never the ‘twain shall meet.
During and after the upgrade to 9.0(x) ASA code, a couple of things happen:
- IPv6 standard ACLs are no longer supported, and any you have are migrated to extended ACLs.
- If IPv4 and IPv6 ACLs are applied in the same direction, on the same interface they are merged.
- The new keywords any4 and any6 are added in place of the old any keyword.
- Supposedly, if certain conditions are met (and they were in my case) your IPv4 and IPv6 ACLs should be merged into one (they were not).
While it is a bit scary to have any vendor automagically migrating portions of your configuration to a new format, it happens and as long as they document well and you do your due diligence, things can work out just fine. Other times they completely go to hell because of an undocumented feature. This upgrade fell somewhere in the middle.
As it turns out, a critical fact was left out of the documentation. Namely, that all of your access-groups that had been applied in some direction or another would now, quite frankly, not be applied to anything. In other words, my firewalls were now letting anything out of the network and nothing in. I quickly applied my new access-lists to the interfaces a couple of times before I discovered that you can now only have one applied in any direction (par for most IOS devices).
Since these were production and I had some higher risk on the IPv4 side (we have a lot of rules, and a default-block outbound policy) than the IPv6 side, I did the following:
- I blocked IPv6 in and out, then applied the IPv4 lists to the interfaces in the correct directions.
- I hand migrated (notepad is your friend) the IPv6 access rules into the IPv4 lists and brought IPv6 access back online.
- I then deleted the redundant (old) ACLs.
Everything came back, life was good, mostly nobody noticed anything. What’s the lessons learned from this experience? Besides don’t upgrade ASAs? How about these:
- Always have a backup of your configuration, preferably taken a few minutes before you start the upgrade. In this case I didn’t use the backups for more than a reference, but they were available if I had wanted to roll back.
- Know your configuration and your devices. This seems intuitive, but a lot of people would have gotten part way through this migration, saw that their ACLs were borked, and been lost. If you’re going to live on the edge, at least have a helmet.
- Read the documentation. I did, and while it didn’t directly help, I at least knew ahead of time what was likely to break. I also knew once it broke what the likely problem area was. To tie this into the CCIE Lab (back to studying, so it’s on my mind) it’s a bit like being able to look at a network diagram and instinctively know where you’ll have problems (two routers doing redistribution between EIGRP and OSPF, check).
At the end of the day, it all worked out for a variety of reasons listed above. Would I suggest any readers out there try this sort of “no net” upgrade to bleeding edge code? Probably not. In my case, I’m a masochist it seems, and this is my therapy. Now on to my 6500 upgrade to 15.1(1)SY. I’m sure I’ll be writing about that not long from today.
Incoming search terms for the article:
- asa 9 0(2)
- asa after upgrade to 9 0 rules gone
- upgrade asa 9 missing acces rules
- migrate asa 8 4 to 9 x e-mail problems
- ciscos asa 9 02 instalaltion
- cisco asa issue with nat after upgrade 9 0 2
- cisco asa failover active/passive
- cisco asa 9 0 2 upgrade
- asa upgrade 9 0(2) best practices
- asa not working after upgrade 9
Working the Comp Plan
April 2, 2013 by Leave a Comment
We’re adding a little something to this month’s sales contest. As you all know, first prize is a Cadillac Eldorado. Anybody want to see second prize? Second prize is a set of steak knives. Third prize is you’re fired.
In a previous life, I worked as a pre-sales engineer specializing in network restructuring. As such, I was attached to the sales organization, and always participated in sales conferences, meetings, etc. I was paid a base salary, plus had a comp plan for bonuses–though I had more of an 80/20 split in salary/bonus potential, whereas the sales folks had a more traditional 30/70 or so split.
Every year, right after the hustle and bustle of the holidays had settled down, the same drill would begin again for the new year: the forecasting and associated compensation plan roll-out. Luckily enough, this was usually somewhere nice, like a posh resort in Scottsdale, so I didn’t really mind much. Of course, I also had a little less on the line than the true sales folks since most of my bonus split was based on the entire region in total, and not on a particular vertical market or small territory.
Inevitably, after the glow of the open bars, sunshine, expensive dinners, and golf outings had died down, reality would sink in. No one would make as much as the legendary (and usually fictitious) rep from last year who had landed the big whale account; we’d all be lucky just to make the mortgage payment. Some people would talk about leaving and others would just worry.
Then there were the experienced reps; the ones who had been around for a few years or more and understood the game. Sure, they may have a complaint or two about the forecasting numbers or something, but they largely weren’t flipping out like the new guys. If you asked them why, or what their secret was, the answer was one you’ve heard before: work the comp plan.
Let me explain. Ostensibly, the company sales leadership has crystalized the strategy for the next year into goals, targets, etc., based on what’s been deemed to be important or critical for success, down into specific targets for each territory and sales rep. They have decided how much to pay in bonus money, sales multipliers, etc., based on this. The stuff that was less important would be paid less lucratively.
Hence, the experienced sales people would mostly ignore whatever speeches, memos, or strategy discussions came from the mouths of the leadership team, and instead focus like a laser on how they were being paid: the comp plan. I get a 10% for selling vendor X’s product, but only 5% for vendor Y? Then Vendor Y doesn’t exist for all intents and purposes. Work the plan.
This usually had the predicted outcome, of course, with goals and compensation wildly swinging from one extreme to the other as targets were hit, missed, or wildly exceeded. Often the company would have to perform some sort of course-correction mid-year to overcome the errors made manifest in a system like this. Through it all, the veterans would smile and keep “working the plan” as the younger, newer folks burned themselves out trying to keep up.
Why do I bring this up now? As the head of IT at a company in the enterprise space, I’m not selling anything, at least not in the traditional sense. I still have customers, however, and I still have a bonus structure. In fact, we just finished up this process internally and so this was all on my mind.
You would expect that my goals–and those of my team–would be based on critical company goals, distilled and crystalized over many planning sessions, with a lot of thought behind them, right? You would think that, yes, but you would be wrong–or at least partially wrong.
Sometimes, in both the VAR world and the enterprise or ISP spaces, the gap between the high-level company goals and the individual departments’ goals get run through a blender of sorts (will it blend?). High level company goals of “maximizing shareholder value through increased paradigm-shifting cloud strategy” sounds great if you’re a recently minted MBA getting paid by the word, but it translates into exactly as much gibberish as you’d expect by the time it gets to be time to make it an actionable metric. So, you get random goals and projects as your key metrics instead of a more measured and appropriate metric.
For instance, as the guy in charge of IT for the entire company–world-wide–you might expect that a major goal of my team and I would be… uptime. It’s a fairly standard measurement of how reliable the overall architecture of the network is, and it’s relatively fair and has the benefit of being easy to quantify. Do I have uptime as any kind of metric this year? No. In fact, most of the goals I have are special projects that pull in stakeholders from other parts of the functional side of the business, but very few are actual, real, quantifiable IT metrics.
I asked about this and was told that that “other stuff” just goes without saying. When I asked what things during the year, and at the end of next year, would contribute to any possible bonuses, raises, and good reviews I was told that the goals are the metrics by which my team and I will be assessed. All of that redundancy stuff? Nope. All of that failover, uptime, increased efficiencies, lower staff hours, quicker help-desk resolution? Nope.
So why am I still smiling? Because I’ll be working the comp plan.
Incoming search terms for the article:
Complexity is Relative
March 17, 2013 by Leave a Comment
“There is always a well-known solution to every human problem–neat, plausible, and wrong.” H.L. Mencken, Prejudices: Second Series, 1920
I had an interesting conversation today with a cohort of mine regarding network complexity. Specifically, the conversation started out with him mentioning that he thought my network was “bloated with complexity”. He didn’t mean it in a bad way–necessarily–but my first instinct was to take it that way.
Then I started thinking about it. I wondered what, specifically, he might be referring to. Was it the dual-stacked IPv6? The VLANs? The VRFs and multiple redistribution points between protocols? The MP-BGP? Multicast?
It was probably some of these and all of these since he had just been pouring over some network diagrams that I had sent. He did hone in a bit on the IPv6 portion, but more specifically he seemed concerned about the redundancy. Yes, we have multiple routes out of offices, with multiple routers–no single point of failure and all of that. In my mind, however, that is a bonus and evidence of seven years of effort to rebuild this world-wide network into a very, very reliable and robust network.
“We like to keep things simple,” was his response. I pointed out that I could probably rebuild the entire core infrastructure in 12-24 hours, at the command line, from memory, so I didn’t think it was really that complex. He wasn’t necessarily persuaded.
Now don’t get me wrong, the entire conversation was very cordial, and I respect this guy’s bona fides and his judgement. He has a great track record, and a great set of skills in both management and systems administration. But therein lies the rub. His skills mean that what I see as simple solutions to a problem, he sees as a massive level of complexity to be reverse-engineered. Honestly, I’d probably react the same way to some of what he can do on the Active Directory side of the house.
My specialties are data center, bridging/routing, and converged infrastructure, and I’ve been doing that for 19 years professionally, and a hell of a lot longer if you count the years before I figured out someone would pay me for what I know. I briefly wondered if that has put me into an insular world where I can’t see what could be made more simple?
I spent most of the rest of the day thinking about the various parts of my network, and where I had implemented solutions to particular problems. I thought long and hard about what I could do to simplify that particular area of the network and couldn’t come up with anything.
I then turned my attention to whether or not I could add complexity just for the sake of doing it. In most cases the answer was a resounding yes. In fact, I compared what I had done in many places with some of the similar layouts in some of the CCIE labs (admittedly these are at an almost asinine level of complexity, but still…) and found that I had “taken the easy way out” as some of my past teachers were wont to say.
So, then I turned to the more philosophical question of knowledge and the relative nature of it. One of the things that seems to happen to me more often than I’d care to admit is this: I’ll find something in my network that needs fixing, and as I’m looking at the code and the diagrams I’ll wonder what moron did this thing. You’ll probably not be surprised to learn that it was a previous version of me who was the moron.
At the time I was working with what I knew, and I solved the problem using the tools I had, but looking back on it now I realize that I didn’t have all the experience and knowledge I needed to fix the problem correctly. I was approaching the problem based on what I knew, and I probably would have, at the time, viewed my new solution of today as “overly complex and bloated”.
The idea of “keeping it simple” is a good one, and one we should embrace as network engineers and architects as often as we can. If the simplest solution meets all of our requirements without breaking anything else, we should use it. What we should not do, however, is use the concept of keeping it simple to be a catch-all of keeping it so simple that you can hire a CCNA to run a CCIE-level network.
If what you want is a CCNA-level network, and that’s all your business needs, then you’ll be fine. As soon as you start incorporating higher-end systems like top tier ERP systems based on Oracle, redundant SANs in order to provide a certain level of resiliency and performance, 10 and 40-gig Ethernet, blade servers, virtualization, redundant paths and automatic failover, you’ve pretty much let that ship sail, however, and you need to acknowledge that you have a greater need for skilled maintainers of your network than maybe you’d like to believe.
Maybe “keeping it simple” is management code for “we can pay a monkey to maintain this, and maybe make our bonus because we made the IT costs look good this cycle.” In the short term that works. But in the long term there’s a cost to be paid, and if you miscalculate when the note comes due, you’ll likely find yourself in a much worse position when you have to fly a team of high-cost consultants in to clean up the mess.
Incoming search terms for the article:
Cisco Live 2013 Announcement
March 14, 2013 by 3 Comments
I just received this from one of my Linked-in groups and thought I’d share it:
| Early Bird pricing discount for Orlando ends this month. Register now to save up to $300 http://bit.ly/2013Rg
Scheduler opens 26 March. Search for the courses you want here http://bit.ly/WHC06q or go to the course listing http://bit.ly/15KpVhT and then visit the Event Catalog for course details. NetVets can begin to schedule their courses on 19 March. View our rebroadcasts of two very popular IPv6 sessions from Cisco Live and connect with the course speakers during the event on twitter. Find the session and chat details for the 21 and 28 March events here http://bit.ly/Chat13 We look forward to seeing you in Orlando in June http://bit.ly/CLpage and connecting with you in Cisco Live 365 http://bit.ly/VxZ5Um for thousands of on demand sessions all year, for free! New sessions have just been added from the Melbourne event. |
Incoming search terms for the article:
The Burnout – An Engineer Becomes Disillusioned
March 3, 2013 by 4 Comments
The Burnout
“You don’t burn out from going too fast. You burn out from going too slow and getting bored.” – Cliff Burton
I used to wonder how a person can “burn out,” get bored, or otherwise grow tired of doing something they absolutely love. I really never understood the premise, and I didn’t understand the people to whom it happened. Until it happened to me.
To be fair, after having been diagnosed with a pretty rare form of cancer midway through last year, it’s not retrospectively surprising that my focus would change; that I would want to spend more time with family and less studying to the nth degree the various technologies I love. That wasn’t it, though.
I felt tired. An almost depressed kind of tired, to the point that I was just going through the motions but with no particular excitement about any of it. The books from Cisco Press and INE, the stacks of RFC printouts, and the hundreds of pages of white-papers on this or that technology sat in my office only occasionally moving when one of my oddly overweigh cats clumsily knocked something over in a vein attempt to gain higher ground.
In short, I was done; done with the arguments about Apple vs. Microsoft, or Android vs. iPhone, BSD and Linux, Emacs and Vi. I started spending my free time watching more television with my family thinking that meant quality time, when it mostly just meant passing time. I began a couple of hobbies, started planning more vacations to warmer places, and generally found myself just being.
Just recently, however, I had a revelation. It wasn’t that I was burned out on the whole of IT, I was burned out on two things: stuff that doesn’t matter, and maintenance. To wit:
The little things that I was burned out on were all of the little, petty, fairly unimportant things that everyone in IT gets hung up on at some point: the “this vs. that” arguments that inevitably devolve into quasi holy wars. To be honest, I couldn’t care less which phone you have or which operating system you use; if it works for you, great.
That’s a minor point, though. The big point of burnout for me was the maintenance–the daily grind of resetting passwords, looking at endless streams of alerts, scheduling maintenance windows, negotiating with management, budgeting, re-budgeting, etc. This is what I’ll call the cat-herding part of my world. This is the part that was burning me out.
I sat down one night and started reading one of the classic self-help books–which one escapes me this second, but probably Dale Carnegie or some such–and I started thinking about what it is that I actually enjoy about IT. What is it that drew me in when I was much, much younger and sustained me for so long?
The short answer? Projects. Figuring stuff out, implementing new technologies, making something work that solves a particular problem. That’s what gets the proverbial juices flowing. That’s what I needed to get back to.
Throughout most of my career I’ve been a bit of a designated hitter. What do I mean by that? I mean that I’ve done a lot of post-sales implementation, and pre-sales engineering, and a lot of evangelizing of different technologies. In short, I’ve been the guy who helps a company fix a particular problem.
For the last few years, however, I’ve gotten away from that. I’ve become a successful Sr. Network Engineer and IT Manager of a multi-national company and I’ve spent almost 7 years rebuilding an entire world wide network from the ground up. It’s been thrilling, challenging, and frustrating all at the same and different times.
Now, however, the network is almost all done. It is built. The problems have all been solved, and now we’re in a maintenance mode–where the focus shifts from expanding and problem solving to maintenance and cost-cutting. And therein lies the crux of the issue.
It may be that I’m some sort of masochist, or extreme type-A personality, but I have an almost narcissistic, obsessive need to be fixing something. With me, it is not a case of “if it’s not broke, don’t touch it,” it is more like “if it’s not broke, I don’t care about it.”
To wrap it up for now, it seems as if what I’ve been dealing with is not a case of burnout at all; it is boredom. And that, my friends, is much more insidious. I’m much more aware now of all that boredom can do: It drags you down, it robs you of the joy of moving forward, and it takes the fun out of what used to sustain you.
The good news, however, is that with this awareness comes a better, move revived focus, and I’m starting to come alive again. I’m starting to look forward to the conventions, to the new technologies, and to some of the inevitable arguments and technology holy wars. In the meantime, I’m off to reset some passwords and work on some budgets… at least until the next big thing comes along.
Incoming search terms for the article:
Open Letter to a Failed Job Applicant
October 24, 2012 by 7 Comments
“Life is hard. It’s harder if you’re stupid.” – John Wayne
Dear Applicant,
I know it must have hurt you to find out that you were not selected for the position you interviewed for with my company. I know that based partly on my own experiences looking for work, but also by the way you attempted to high-five me when the interview was over. Rest assured, the fact that you almost punched me and that I had to get my glasses adjusted (turns out they aren’t made to hit the wall that hard) had no direct bearing on you not being asked to join our team. I feel a certain sense of duty, however, and would like to see you succeed in the future. To that end, please consider my topical suggestions for improving your interview performance below.
Timeliness–I understand that unforeseen complications can arise at any place, and often at the most inopportune times, which is why I didn’t cancel the interview when you were 35 minutes late to meet with me and the rest of the interview team. Life can happen to anyone, and I was feeling a little forgiving that day. Thanking me profusely for allowing you to interview was a good start, but explaining to me how drunk you were last night probably wasn’t your best move, strategically speaking.
Clothing–I know that in several print and other media outlets it is a well-hackneyed meme to eschew the idea of wearing a suit to a job these days. Some even say that you shouldn’t wear a suit to the interview. I tend to disagree, but I do understand that now that I’m in my late 30′s I am officially an old codger from your perspective. Let me just say this, then. Showing up to the interview in a wrinkled gap shirt, a pair of what I have to imagine are extremely uncomfortable jeans, and some oddly colored shoes that may have been made out of recycled rubber boots was a regrettable choice. You can probably skip the tie if you need to, but you may want to consider a pair of good slacks, a button-up shirt, and a coat. You may be a fresh-out-of-college hipster, but some of us aren’t.
Confidence–I admire confidence in people, I think it’s a good trait. Confidence during a job interview is also a good trait, and I’m glad to see you have it in spades. You should consider tempering that confidence just a bit, however, and perhaps relegating your stories of other-worldly deeds to things you have actually done, and not just things you have heard about. Also, the phrase “back in the day” should probably not be used to describe something I remember implementing less than 10 years ago.
Questions–I have to admire the way you showed absolutely no interest in my company… none, nada, zip. It takes a remarkable amount of focus and dedication to remain that entirely disinterested in a company you, ostensibly, are interested in working for. I have a hard time hitting that level of indifference on topics as mundane as toilet paper color, so that’s something. For future interviews, however, you may want to come armed with some basic questions that show you are at least aware of the company name. Start slow, then work up to more detailed questions like:
(1) What kind of company is this?
(2) What do you make? Or sell? Or do?
(3) Will I be paid?
(4) Am I expected to wear clothes?
I do applaud you for having questions at the ready, and for asking them in a serious manner, but I do question the content a bit. For instance, the few minutes we spent discussing what it *really* means to take a random drug test, whether they’re truly random or not, and how much notice you’d be given were insightful to say the least. Your concern about background checks was also good to see, though perhaps not in the way you might have hoped. The story about your wrongful arrest was colorful, if not helpful to your cause, and was 10 minutes of my life I’ll never get back.
Salary Negotiations–Here is an area where you really shot for the moon, and that is commendable on some level. Your tenacity in maintaining your worth to my company, despite all evidence to the contrary is a model of confidence and self-worth. The fact that your last job was as a help-desk technician for the local chapter of the there-but-for-the-grace-of-God society, that you had responsibility for two computers, and that you spent the majority of your work week in what I’d charitably call the custodial industry notwithstanding, you stood your ground and demanded a six-figure salary. As a quick aside, I have to apologize again for blowing coffee out my nose at you during this discussion. I assure you it was simply a lingering illness and nothing to do with our conversation.
In closing, while you were not offered this position–or any future position, ever–I hope that my suggestions above will be taken under advisement and help you as you explore other opportunities with–and I can’t stress this enough–other companies. Oh, and the position was filled by a guy in a suit. He wasn’t as fun to interview as you were, but again, he had a suit.
Thanks
Incoming search terms for the article:
- failed interview letter
- letter failed interview
- Did Not Hire Letter
- job applicant not hired letter
- feedback letter failed job interview
- legal weed if you have a website link to it here post a new comment
- in working for I have
- interview letters for applicant when you did not get job
- failed interview
- letter that i failed the interview
