Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
evol262
Nov 30, 2010
#!/usr/bin/perl

Excellent OP. If you want elaboration on Linux or THE CLOUD and what it means, happy to do a writeup (I'm in the cloud eng department of Redhat and actively work on/with OpenStack.

Where are the ACID NoSQL databases?

Adbot
ADBOT LOVES YOU

evol262
Nov 30, 2010
#!/usr/bin/perl

DragonReach posted:

I'm not trying to make the interviewee look bad or anything like that. I need to know how deep the applicants knowledge really is, and honestly I need to hear a "I don't know, but" with whatever follows the but being what the applicant thinks would work or a logical process to get somewhere near the answer.

Quoting this for posterity.

evol262
Nov 30, 2010
#!/usr/bin/perl

Tasty Wheat posted:

When my new contract start date got moved back from Mon to Wed and so far I have seen two different job titles, Analyst vs Engineer, this is going to be interesting.

How many people have jumped ship on a contract before your first day on a contract? I always have this crazy moralist point of view about running the first option year on a contract before leaving.

Do you really think this is a bad sign? As long as the job description is the same, who cares about the title? I've been "Application Systems Engineer 4", "Operating Systems Engineer 2", "Systems Analyst", "Data Center Specialist", and more. All of them were basically "systems administrator", and the first two were literally the same job on the same team, just in different locations.

evol262
Nov 30, 2010
#!/usr/bin/perl

Ursine Asylum posted:

Because the job title implies what the company is willing to pay you, generally based on the average of {job title} in the area. If company A wants to hire you as a "Senior Systems Engineer" and company B wants to hire you as "Computer Assistant II", it can end up being pretty telling exactly what your potential for advancement in the company is, not to mention the respect for your work you'll get when you're there.

It's a different title on a contract, which implies same job, same pay, same everything but title for a non-salaried, non-FTE position.

evol262
Nov 30, 2010
#!/usr/bin/perl

Docjowles posted:

Ironically tonight I decided to finally start working on my Red Hat certs in ernest. Spent like an hour building up a VM in VirtualBox that I was gonna use in turn to host some KVM-based VM's. lol, nope. VirtualBox, RHEL and KVM don't work together, you can't nest them like that. Guess I have to find a spare physical machine, so much for my surge of motivation :effort:

VMware player will actually do this (if you want a free solution). VBox doesn't do nested virt at all.

evol262
Nov 30, 2010
#!/usr/bin/perl

Misogynist posted:

  • What are five types of DNS records and what are they used for?
How often do you get candidates who go off on how idiotic it is that DNS has more security-related record types to try to bandaid various problems (DNSSEC, DKIM, SPF, et al) than address-related, and that 99% of these record types could be handled with TXT (which is almost never human-readable anyway)?

evol262
Nov 30, 2010
#!/usr/bin/perl

MC Fruit Stripe posted:

Are there any good case study "here's what we're doing" type websites? I can read books all day long but I'm curious what people are actually doing. Like company X saying oh we went with this backup solution for this reason, another went with another for this reason, so and so chose this SAN, etc? Looking to put a little real world perspective on this theory.

The term you're looking for is "Whitepaper". They're generally vendor-published, as in "Customer Y switched from A to B because $reasons, here's a breakdown of savings and performance comparisons", but startups are constantly tooting their own horn about this on HackerNews, too. You just have take the "we run our business on Haskell and alpha Javascript frameworks" people with a grain of salt.

evol262
Nov 30, 2010
#!/usr/bin/perl
"A DevOps guy would reinvent the wheel multiple times so he could put new, buzzwordy tools on his resume"

evol262
Nov 30, 2010
#!/usr/bin/perl

Bob Morales posted:

Antique programming languages and environments and the people in charge of them are usually stalwarts from the 80's. Also be prepared to work with a very small amount of high-priced consultants.

What mainframe?

System Z (and AS400 in general) happily runs Linux instances with languages and tools as modern as anything RHEL6 can throw at it. Yes, you'll have traditional COBOL/JCL stuff running on it somewhere, but they're not necessarily as antiquated as this makes them out to be.

Bob Morales posted:

It's not a really a mainframe but we are using an HP Itanium server (new in 2004) running HP/UX. We run Universe database, which supposedly could instead run on Windows or Linux. But the actual application code and hourly/nightly jobs all still run on the machine, and it's a internal piece of software that we've been working on for 25 years. It would be a massive project to move over to .NET or PHP or Rails or whatever, and would probably bankrupt the company if we tried.

It would be nice if we did - that's assuming we built modern web front ends to our applications. Right now we run a mix of green-screen terminals (most interaction with the system is done through Dynamic Connect which is a terminal emulator straight out of 1992) and a few web applications and an old VB6 Windows app that do a lovely screen-scraping job. The database connector we use for the VB6 app is no longer supported either so good luck troubleshooting that poo poo when it randomly crashes.

Another thing that would be nice is if the database ran on MySQL or MS SQL. Backups, replication, clones for reporting, all this stuff is a giant hurdle when you're using LARGE COMPANY ANCIENT DATABASE SOFTWARE.

HP still supports the OS and Strategy7 still supports our hardware. We had one of the redundant power supplies go out in our tape backup a few weeks ago and a guy showed up from HP the next morning with the part and replaced it under our maintenance agreement. We bought another Itanium on eBay that I have to scavenger the 4GB of RAM out of and install it in the production system one night.

We're getting a pair of 300GB Ultra320 drives to replace the 146GB drives in another Itanium server we have that I'm configuring as a clone that we will have ready to go in our disaster recovery colo. This project has been 'in the works' for the last 4 years, I'm the only person they've ever hired with any UNIX knowledge so we're finally getting the ball rolling on it.

You could virtualize it but not in the traditional sense because it's not x86 hardware. But mainframes have been doing their own virtualization since the days of DOS.
This is terrible. There is almost no reason whatever code you're running needs to be on Itanium. While UniVerse is a complete piece of poo poo, it runs on Linux also. And Windows, probably. It supports ODBC. Why are you using a VB6 connector? Why are you using VB6 in 2013? You don't need to scavenge parts and duct-tape together hardware.

evol262
Nov 30, 2010
#!/usr/bin/perl

Bob Morales posted:

Because of bad management and lack of technical resources.

I know it's not your fault, but keeping HP-UX servers going and eBaying hardware when a 3 month development push onto commodity hardware would probably cost less than your support contracts every year is :suicide:

evol262
Nov 30, 2010
#!/usr/bin/perl

skipdogg posted:

I thought my commute was bad. 77 miles door to door each way, but it's straight up I-35 and takes just over an hour.

Two hours every day commuting actually is bad.

evol262
Nov 30, 2010
#!/usr/bin/perl

Sepist posted:

Anyone mind looking at this and providing some criticism/suggestions. I am writing something about entry to IT and covering the different kinds of businesses you could land in.

Small shops

Small shops tend to be understaffed, overworked and not very good for upward mobility. The exception would be startups, where getting in on the ground floor has the potential to lead to very lucrative mobility and money. Lone wolfs are more common in small shops where there is no money to pay the salary for teams of peers.
This isn't necessarily true. What small shops offer is the ability to have your hands in everything and set the direction of the business' IT needs (this applies to startups and otherwise). This is good if you're a generalist, really curious, or really talented. Small shops can also be extremely lucrative if you're very good and in a niche industry (medical clinics, law, fabrication).

Sepist posted:

Enterprise

Typically in enterprise environments it will be silo’d job roles, where everyone does a specific task, rarely moving out of their comfort zone. Things move slower as red tape to approve work is thick, but not as bad as government. Work flow could go either quickly or slowly depending on the company and you will find yourself more involved in working as a group. Meetings for changes are common in enterprises, and sometimes meetings to discuss the meeting discussing changes. Change management is prevalent in enterprise, so that accountability can be recorded for auditing. In enterprise IT you're seen as a cost center that doesn't provide anything, profit wise, to the company - your budget will be awful so your technology is typically dated back several years. Enterprise is great for "lifers", those of us who just want to work their 9 - 5, collect a paycheck and go home.
"Lifers" are just as easily found anywhere else. This is probably the categorization I disagree with the most. Sure, you may end up siloed. But I've also ended up handling Windows admin, Linux admin, Linux development, VMware admin, storage admin, and web dev. As a Linux admin. In a Top 5 consumer banking shop. It's more accurate to say that enterprises suffer (more than other companies) from inter-team politics. I handled all those things because I had/have the skills, and we didn't want to risk handing over a project or part of a project to another team that might cock it up or fight us for control (and the corresponding budget) down the road.

Budget is not a problem. While IT is deemed a cost center (realistically, it's a cost center at every business not in the IT sector, not just enterprises), budgets are fine. You're more likely to see enormous SAN deployments, multi-site MPLS VMware clusters, and the like at enterprise shops. Because they have the budget. The difference (and problem) for you is that they have hardware refresh cycles. And if you come in 2.5 years into a 3 year cycle, it's going to look dated. If you come in 1 month after, it'll be impressive. But you can always get it if you prove a business need or benefit to the company. Enterprises (or groups inside enterprises large enough to have pull) standardize because it's easier on everyone.

You may find old software. And yes, sweeping changes will require meetings. But (again) that's standard at every well-run company. Somebody should be reviewing your changes and pointing out business needs you may have been unaware of. You probably won't find many enterprise shops running CoreOS. But that's not necessarily a bad thing. Enterprises don't run unproven technology.

Sepist posted:

Service Provider

Service providers are vast, often complex environments. These jobs are even more silo’d than the enterprise environment and you will find getting into one too early may pigeon-hole your career. I would only recommend service provider jobs when you are in a position to leverage your experience for great monetary gains or there are limited alternatives in your area. Starting out in a service provider call center and working your way up seems easily done as long as you have the raw talent and the desire to move ahead. Don’t be surprised if you don’t end up where you meant to go in the end due to being sidelined into a job role that was needing to be filled.
Other than there not being enough service providers to even qualify as a category relative to "Enterprise, Government, and Small Business" (even if you include utilities and other things which are questionably "service providers"), this suffers from all the same flaws as your description of "Enterprise", plus one: in 2013, you should never assume that you'll be able to work your way into the position you want at the company you work for. You should always YOTJ, including YOTJing to another company that offers you another role and coming back to the original company in the position you were gunning for a few years later.

Sepist posted:

Government

Government is a slow moving beast. Most positions within government require secret clearance and are contracting jobs, only a small amount of government IT work is full-time positions. Most government IT contractors are ex-military since you need security clearance. The two routes to get security clearance are through the military or your company sponsoring you, and why would a company that doesn't deal with the government want to sponsor you? The red tape is very thick in government, which usually leads to low turnover, high job security, and long lead times for changes.

Most positions within government:
  • State or municipal -- they don't require a clearance and aren't contracted
  • Federal -- are contracted through Dell, Lockheed, or someone else who will offer you a full-time position (for them, where they'll have you on-site like a normal job, and you don't have worry about contracting poo poo
  • Do not require a clearance (secret clearances require no more info than a normal job will do anyway -- credit+background check, basically) unless you're contracting with DoD. Energy, State, Treasury, and other departments have clearances which are broadly equivalent, but you won't need one unless you're working in a position where you're going to handle trusted information; a reasonable assumption for a sysadmin, but not necessarily for a developer. Don't lump all clearances in with DoD/DSS. You need a 'need to know' to get a clearance. You can't even get sponsored by a company that doesn't deal with the government, because they have no need to sponsor you to know 'need to know' information.
  • Turnover is very low and job security is very high because promotion through the GS system is almost wholly based on a combination of: years in service, time in grade, and education (with requisite good reviews and the normal stuff). There are less and less positions the higher you go, so it's hard to get promoted. You wait for people to retire or die. But the benefits are very good, the pay is reasonably good, and you can go in 9-5 and collect a paycheck. This is the job for "lifers"

evol262
Nov 30, 2010
#!/usr/bin/perl

Dilbert As gently caress posted:

I would love to work in the rail industry like Norfolk Southern or CSX where they apparently don't get taxed as much due to some funky old laws. Seems like it would be fun if I ever want to get out of VAR's/MSP's

You also get sweet, sweet railroad pensions through the RRB, because it's basically communism.

evol262
Nov 30, 2010
#!/usr/bin/perl

Bob Morales posted:

I just did. I am just trying to fix up everything I can and wait for the IT Director to be fired (rumors are floating). We need someone who's been where we are and took things to the next level (or up to something current).

Current guy is a loving tool who only buys AMD and only buys refurbished HP poo poo. Had I known it was this bad I would have never took the job, but at least it's a challenge in certain ways.

What metro are you in?

evol262
Nov 30, 2010
#!/usr/bin/perl

Bob Morales posted:

None, really. 2 hours north of Detroit in a dwindling old auto town of 40,000 people.

My personal situation has changed a bunch this summer so I'm going to consider re-locating over the winter but I need to sharpen some skills first. I'm back to Windows admin after almost 3 years of Ruby development.

Ouch, nevermind. For some reason I thought you were in Minneapolis.

evol262
Nov 30, 2010
#!/usr/bin/perl

smokmnky posted:

I've started to get some trickle of jobs, the lovely overnight NOC position for $15/hr.
What's your skillset? The "overnight NOC position for $15/hr" is exactly where I started. It was a good fit because it was low-stress, I had lots of free time to read up on things and I could work on non-time-critical projects I'd volunteered for at the company running the NOC. I learned Perl there. And SQL. And Python. And Linux/Windows administration. And.. it is what you make of it. It's actually a good industry starting point.

Edit: nevemind these questions. Just saw you're looking for a technical project manager and you have 7+ years of experience...

evol262
Nov 30, 2010
#!/usr/bin/perl

Motronic posted:

Holy poo poo, what did your training teach you? It's obviously only the technical side, so you best end up with a positon where you are an underling for now. If not, you need to get some relevant business sense in your head right quick. Those systems are used by businesses that value reliability and consistency over the latest and greatest fad but can't afford or utilise a proper 'frame.
They're used by businesses that have legacy code they don't understand or can't be hosed porting, because a brand-spanking-new mainframe can still run System/36 code.

Tab8715 posted:

I haven't had any training - yet. The last guy my company tried to hired worked for a month but then bailed for the same gig but they company paid much more - I'm making less but it's still good money. The iSeries System Administration gig is only a half-time deal with other random MSP-Stuff that include random Windows Servers and iSynergy.
This is actually a plus because you won't be pigeonholed as a "mainframe guy" who works with JCL and RPG.

Tab8715 posted:

I know the systems are reliable but isn't everything else just as reliable these day? We could certainly create any X86 System that has built-in redundancy and automatically failover, no?
No. Where mainframes really win is sheer throughput on a single chassis (single system image clusters like the kind that appear on Top500/etc lists obviously have higher throughput, and some of SGI's hot stuff that uses Infiniband or custom interconnects to tie together a bunch of disparate nodes can compete), and the fact that you could literally shoot the drat thing with a shotgun and keep it running. Hot-swappable CPUs, daughterboards, and everything else. There's no reason to ever turn one off. This is the market for mainframes. Like the old Timex commercials.

Incidentally, zSeries is a whole 'nother ballgame where IBM basically ships max-config systems and enables hardware based on licenses, but you're only charged all the way for "full" processors, so IBM will sell a system with Java coprocessors that are basically POWER CPUs with 1 instruction disabled to "accelerate Java" while not crippling you with license fees.

Tab8715 posted:

Second, what makes it so special? Why can't the same things processed on this platform be done anywhere else? And - if everyone is claiming the as400/iSeries is dead - why did IBM release a new Power7+ CPU last year? Why did IBMi have a release last February?
AIX was previously mentioned. The AS/400 is still around because of legacy code. Hardware partitioning and the ability to run AIX/Linux on iSeries make it an easier sell than zSeries, but IBM's market is basically:

zSeries -> India (only place it's growing)
iSeries -> hey you with the old mainframe you're thinking about porting your poo poo off of -- you can replace that with a 4U server relatively cheaply and keep going!
iSeries -> hey, you used to buy pSeries poo poo to run AIX on. We killed that and merged with with iSeries so our marketing docs can say iSeries is expanding. Your new AIX gear will be iSeries, not pSeries, so we can prop up our brand.

Motronic posted:

Redundancy of that type adds complexity. Which defeats itself in terms of (scheduled) uptime. While it may have less unscheduled downtime, moves/adds/changes can take a hell of a bite and require a whole lot more experienced personnel to pull off successfully.
That's why you get a second mainframe and shuffle your batches/partitions/jobs over to it while you do maintenance. Serious.

Motronic posted:

What makes it's so special? It's a proven platform that has huge uptime and built in proven transaction integrity. IBM released a new one BECAUSE THERE IS A MARKET. I don't care what people who don't understand that think, and obviously IBM doesn't either or they wouldn't have put the money in to do this.
Solaris has "huge uptime". So does Linux. And AIX. And any well-maintained system. ACID-compliant databases have "proven transaction integrity". These are literally phrases from IBM marketing pamphlets.

Motronic posted:

You need to understand that there are a lot of 20-something people in this business. Most of them have never touched a system like this and have no idea what they are capable of and just think it's "old poo poo." And they are right....it is old poo poo, but some things are worth keeping around for the right reasons. We still haven't reasonably replaced these things in "PC hardware." That's a simple fact.
You're right that we haven't replaced these things in "PC hardware". SGI's pretty close. Nonstop wasn't "PC hardware" but it did replace it. System/${whatever} is around principally because of legacy poo poo, if we're being honest. I can't buy PC hardware that lets me randomly rip out hardware and keeps running, albeit slower. But I don't need to. I can buy a blade chassis and run distributed jobs on a clustered database that can handle the loss of an entire node. Or virtualize it and swap out the entire backend. It doesn't automatically make legacy code resilient (where mainframes are sweet), but new development can be just as reliable. The amount of customers running Linux on z Series should be a very good indicator to you of where the market is going.

pram posted:

SMIT

well most of that stuff is absolutely useless for Linux. When it came time to leave the Banking world I basically flushed all that experience down the toilet. I guess my advice is to just do it for a few years and move on, unless you feel like doing it for the rest of your life.
I actually felt like SMIT was useful because it actually dumped the commands it ran to a log. Sure, some of the stuff was AIX-specific, but looking at smitty output when I started in the industry really helped me understand how powerful basic coreutils could be if chained correctly.

Tab8715 posted:

It does seem like investing my time into Linux as opposed to Unix would be more valuable but this door opened for and I'm taking it.
Mainframe's not UNIX. But investing your time into UNIX is just as valuable as Linux. Realistically, the concepts between Solaris/AIX/RHEL/SLES/HP-UX are all extremely similar. And while SAM vs. SMIT vs. YaST vs. whatever (if you want vendor tools for configuring them) or figuring out HP-UX VxFS software RAID vs SVM vs ZFS vs MDRAID can be confusing, and low-level (disk/kernel/driver) systems administration skills don't transfer, there's not a lot of trouble going back and forth unless you mean going wholesale from a very large pure Linux environment to applying for a position as a senior Solaris admin.

Basically, investing your time into "UNIX" vs "Linux" is equally valuable. "Mainframe" vs "*nix" is very different.

Tab8715 posted:

On the flip-side, how come you left the banking/AIX world?
Speaking for myself, consumer banking had a lot of internal politics. The bank I worked for was extremely large, but you constantly had teams duplicating effort then fighting for control. Outside VMware/Tivoli/whatever groups who'd come out of nowhere, and because their manager was better at politics, we'd be stuck justifying why we should be allowed to manage our own VMware environment that's not subject to all the restrictions the Enterprise Architects laid down (which amounted to "no control over your VMs"). Or our manager would outmaneuver a different one and we (a systems engineering group focused around AIX, Linux, VMware, and C++ with other projects as they arose) would suddenly be taking over the effort to port some application to run on Cygwin because we have "expertise". And taking over this project gave us part of their budget. It was all budget wars, really.

This says nothing about regulatory compliance, 10-year-old ksh scripts to provision your environment, contractor culture, etc. The best word for it is "legacy". Even when you'd write new tools, the person who came behind you to build on top of it would use the same outdated development paradigms and you'd be stuck arguing about why you will not copy libexpect.5.40.so onto a brand-new RHEL6 install because they can't be hosed updating their application to link against a newer version. Or devs who ship packages that need to be installed in a specific order to work but have skeletonized RPM spec files, require /usr/local/bin/sh in scripts (which isn't there, but used to be there 10 years ago when they first ported it to HP-UX and they never updated their scripts), etc.

They're not technical shops and they're hard to be in long-term as a technical person without getting burned out from constant pushback every time you want to use current best practices.

Bob Morales posted:

I don't think that's too terribly out of line if it's basic info to prove your knowledge, instead of letting you 'take it home and spend an hour on it, and email it back'
Honestly, I'd probably just say "thanks, but I'm not interested" if anyone handed me a written test for a senior position. I mean, I've done the "live programming" thing for Google and Redhat, and it's fine if you know it's coming, and it's basic stuff (read this code and tell me what it's doing, what does this regex match, etc). For anything moderately complicated, if you can't suss out my capabilities in a conversation, it's going to send up enormous red flags about you as a boss.

Bob Morales posted:

I was thinking more along the lines of 'what does X command do', what's the first thing you could check if X isn't working, explain where you would use X, that kind of thing

Misogynist posted:

Another manpage question. It's unfair to candidates who might have solved the same problem a different (better?) way. I've worked with AWS for months, but if someone asked me what ec2revoke did five minutes ago, I wouldn't be able to answer, even though I could give three other ways off the top of my head to remove a rule from a security group if I knew what they were actually asking.

I've run across this a few dozen times interviewing with different shops, and almost invariably, this isn't a question chosen because it's appropriate for cross-section of applicants with a certain technical skill. Most of the time, it's a very specific question tailored to the technical environment of the shop asking the question. More importantly, it's the Dunning-Kruger of technical interviewing. We often fall into the trap of thinking that people who have run certain things in production should know how to deal with the same very specific operational issues that we have. The truth is that very competent shops might have avoided the problem in the first place. "What do you do when your MySQL database is corrupted" is a reasonable question, but one that is much more likely to be answerable by a shop that didn't design their storage environment properly than by a candidate who did.
This is an enormous complaint, really. Ending up in interviews where somebody asks you "what could you check if X", and continues pressing for their pet answer after I've given them 4 other routes for figuring it out. Then they say "anything else you can think of?", and when you finally give up their response is "I was really looking for ${obscure_utility}". Not that there's anything wrong with knowing you can use obscure_utility to solve the problem, but I always get the feeling that the interviewer thinks that's the only way and doesn't realize that your given responses would suffice.

How to find out that you don't actually want to work for the company that's interviewing you: Dunning-Kruger-style questions. It's a good description, Misogynist.

evol262
Nov 30, 2010
#!/usr/bin/perl

Misogynist posted:

You need to be very careful with how you approach this. When you tailor the list of tasks to what the person has on their resume, what you're effectively saying is "we're going to waste an hour of your time making you convince us that you didn't lie about your resume." This is literally the baseline for what you are trying to accomplish with the entire exercise. This doesn't say good things about your organization's culture and its attitude towards trust. When you say things like "it's a point against the candidate," you're making a game of somebody's livelihood. There's no rubric for knowledge work. These are lovely things.

If you want to get a good idea of the candidate's skills in a hands-on way, consider basing the test on their resume in the opposite way, and ask them to set something up that they've had no exposure to. Maybe ask them to research and then set up a Redis or MongoDB cluster, or try to configure a SQL Server mirror, with minimal experience. Don't keep score with "points against the candidate," but work together with them and ask them why they're making certain design decisions, determine how they deal with certain tradeoffs, and figure out how they would work within your organization. When you're working in greenfield, you're allowed to make as many mistakes as you want as long as the project gets done on time. The interview process really needs to reflect this.

When you ask someone to do something in a vacuum, and demonstrate rote technical knowledge, you're reinventing certifications that your candidate might already have. If you're spending your interviews not seeing how the candidate adds value to your organization specifically, and your team specifically, you're just wasting everybody's time.

This is also a perfect response to the "lab" question.

I'd also say that putting me in a lab tells me absolutely nothing about you and what your knowledge level is or what your team is looking for. It tells me you can set up tricky problems. But if you give me hypothetical problems, it gives you a chance to see how deep my theoretical knowledge is and how many similar situations I've dealt with which don't exactly match your description. It gives me a chance to figure out how competent you are, what kind of problems your environment normally has, whether I'd be able to come to you for technical assistance if I ran into a problem like this in the future or whether I'd be Googling things, etc.

Interviews are a two-way street.

evol262
Nov 30, 2010
#!/usr/bin/perl

sanchez posted:

Perhaps I should have added some more detail, these are always windows admin positions of some sort. The candidate will always have some level of windows admin experience on their resume. I don't know of a more concrete way to know how comfortable they are doing that job than to see them doing it. The tasks (emphasis on tasks, nothing is broken) we have are not difficult, they take 15-20 minutes and people rarely fail to complete them. The difference between the way the best and worst candidates do so is huge though, and it's never failed to carry over to actual job performance. Attention to detail is one thing it's easy to pick up on by doing this. If someone makes a typo or clicks the wrong thing and notices at some point, no problem (did they test their work?) If there is a glaring error in something they've done and they don't, that is something that could have serious implications if they were actually working for a client.

Perhaps you are dealing with people above this level, I'm sure at a certain point this kind of setup would be insulting, but for us, it is necessary.

I don't see any advantages to this over just talking to the candidate unless your knowledge level is below theirs and the only way you can assess performance is by how quickly and completely they performed the task. But this is junior-admin or level 3 helpdesk type poo poo, bluntly. And it's a complete loving waste of time. Even from a consulting perspective.

evol262
Nov 30, 2010
#!/usr/bin/perl

Spambort posted:

Any suggestions for which direction of IT I should take if I'm looking to get into Telecommuting? I've been working on getting my MCSA for 2012 but have a CCNA and background in networking. I'm also currently 16 months at my current job of ASP.NET help desk.

This depends much more on your company than your specialization.

evol262
Nov 30, 2010
#!/usr/bin/perl

Dilbert As gently caress posted:

"hey dilbert did you know your lancer only gets 129HP, while my car gets >150?" HOLY poo poo NO I DON'T GIVE A poo poo CAN WE PLEASE TALK ABOUT VMWARE/NETWORK/STORAGE?

Sometimes I think I am the only one at my job who goes home at night and spergs over network storage and hypervisiors.
This just in: some people care about things which aren't directly related to their job. This tends to be when you're over 25 and you're not quite so driven or you realize it's a bigger world.

As long as you're so passionate, you may want to read about non-vmware technologies. Even if it's just so you know more about Xen, KVM, HyperV, Openstack (not really a hypervisor, but y'know), etc.

I'm a Linux Dev who loves Linux and hypervisors. But I also want to talk about whiskey. And lifting. And Warmachine. And whatever. It's normal for other people to also talk about the poo poo they're into or knowledgeable about.

evol262
Nov 30, 2010
#!/usr/bin/perl

ElHuevoGrande posted:

Has anyone ever interviewed with Google for a network security position? I've got a phone interview this afternoon and I'm a little curious on how grueling this is going to be. I read that they don't do the brainteaser type questions anymore, so is it more "Tell me about a type when. . ." questions?

Development/admin (site reliability) interviews at Google aren't very different from anywhere else. Maybe a little live coding on Google Docs. Some internals questions. In your first interview, you'll rate yourself in given subjects on a scale they give you, and they'll ask a few questions to evaluate the truth of that (if you give yourself a 6 on UNIX internals, you may be asked about certain syscalls; if you give yourself a 6 on TCP/IP, they may ask you to calculate subnet masks; if you rate a 6 on both, you'll get both). It'll take 30-45 minutes. Then they'll schedule multiple follow-ups with various people in the same general realm as you if you do well enough, and those aren't really different from interviewing at any other technically competent company.

evol262
Nov 30, 2010
#!/usr/bin/perl

Jedi425 posted:

Why would anyone brag about being a former MENSA member? Does MENSA have an impeachment process, or something? :confused:

MENSA has yearly dues, but it's so full of spergs that only the gooniest people renew. Presumably his intention is to say "I'm smart enough to be a MENSA member and I could rejoin any time I wanted to prove it", but it's so :downs: anyway...

evol262
Nov 30, 2010
#!/usr/bin/perl

22 Eargesplitten posted:

So, if I'm in the process of getting into the industry, how can I put the home network and acquaintance computer type of experience so that I'm not overstating it, but I'm still showing that this is what I do in my spare time?

Also, am I missing a new resume advice thread anywhere? The old A/T one is archived, and I don't see any more either here or there.

Beyond what Misogynist said, you don't. Talk about it if they ask (and they will), but don't put it on your resume unless you're comfortable with those concepts in production (generally), since the plethora of terrible interviewers will see "Network" and start asking you about TCP/IP fundamentals. Which is great if you know it, but makes you look like you're inflating your resume otherwise.

Trust that good interviewers will ask and are good at winnowing candidates.

evol262
Nov 30, 2010
#!/usr/bin/perl

Sepist posted:

:hellyeah: Managed to convince my boss to hire my best friend who is just starting in networking. He's almost completely green so he's going from GNS3 labs and working on ASA ACL's at work to configuring and deploying a Nexus 9k/Nexus 5k/8510 WLC environment. Lucky gently caress I wish I had cool friends when I was starting out :smith:

:frogsiren: WOO NEPOTISM :frogsiren:

evol262
Nov 30, 2010
#!/usr/bin/perl

Dilbert As gently caress posted:

Seriously if I am so busy that I need to work >40 hours don't you think it is completely counter intuitive for me to try and take off time? I feel like it is largely an excuse for companies to not pay OT to their employees.

Flex time is intended to be a "you got a call in the middle of the night" or "there's this deadline, but you're not busy next week" or... whatever. Your company won't fall apart without you. Take some time for personal sanity.

Flex time isn't intended to make up for routinely working more than 40 hours a week. It's there to make up for unexpected events. Routinely working more than 40 hours a week when nobody else in your company is doing it is a sign of a problem. They're not required to pay you overtime. IT is exempt pretty much everywhere. Including some hourly positions. Bonuses just make you money focused, in which case you should go into sales. You're at a point in your career where you want to work 50 hours a week and go home to read about more VMware bullshit. Which is fine. But your compensation isn't oriented around that. And working hard doesn't get you more money, generally. Company hopping, good salary negotiating, making yourself invaluable even if you only work 30 hours a week, and setting boundaries do.

Bluntly, if they know Corvettefisher will work 50 hours a week, not take his flex time, and not leave for a different company, why wouldn't they exploit that? The problem is you. Sometimes that's how you get your career ahead. Especially in the beginning. But the knowledge is its own reward. If you expect "more time worked = more money", you're going to have a very disappointing 40 years in the industry.

evol262 fucked around with this message at 21:43 on Oct 21, 2013

evol262
Nov 30, 2010
#!/usr/bin/perl

Protokoll posted:

At that point you're either so high up the totem pole that you have 4 levels of underlings handling everything for you or your job sucks and you do nothing exciting/groundbreaking/relevant. Call me naive
You're naive. Not because you still enjoy solving problems, but because you believe there isn't a middle ground between "4 levels of underlings" and "working 65+ hours a week", and because you somehow believe that you can't do exciting/groundbreaking/relevant things without working yourself to death. The top companies in the industry are famously lenient about what you do with your free time (Google's 20% time is probably the most famous example), because employees who aren't working from 8AM-8PM plus drive time are more productive and happier.

evol262
Nov 30, 2010
#!/usr/bin/perl

Protokoll posted:

Find me a job where I'm designing a nationwide carrier network from the ground-up, solving difficult issues on a daily basis and working 40 hours/week for 120K and I'll sign up. Right now I'm happy where I am. I can't see myself being happy at a job where I have time to surf the internet during the day, it would be boring to me. Gotta solve those problems...have to be constantly challenged.
Networking isn't my field. But I'm meeting your requirements working from home as a software developer for Redhat. And before that as a sysadmin for Highwinds. And before that as a systems engineer for Wells Fargo. And...

Networking may be really different. But I doubt it.

I have skills other people don't have. Because I put my nose to the grindstone and worked 60 hours a week, or 40 and went home to read about it more. But since I have skills not many other people have, I get the luxury of being in a position where I'm only presented with challenging problems. At some point, the mindset of "gotta solve every problem" goes away. I don't care to diagnose your permissions problem or library error. But when files are disappearing off an NFS share and you need me to write Systemtap probes to figure out who's doing it from the kernel level, I'm in.

The advantage of "seniority" is that some of those levels of underlings make sure I don't get bothered with every little problem. It's a different story in my current position (small team, no "underlings" on upstream projects -- communities that I'm part of instead, etc), but I'd :yotj: if someone wanted me to work 60 hours a week.

This strikes a chord with me because of personal poo poo with a sibling who also believes that spending his entire life working somehow makes it more meaningful, valuable, or interesting. It's not #corporatemachine. It's #stockholmsyndrome

evol262
Nov 30, 2010
#!/usr/bin/perl

Protokoll posted:

Maybe I'll eventually get to your level and have more of a social life, but I doubt it. There will always be something else to learn and master.

Ugh :youth:

I know we've all been there, and everyone in this thread is, has been, or will be the guy who wants to work 60 hours a week. But I'm not "learning and mastering" less than you are at 40 hours a week with a social life. At some point, having more experience actually makes you pick up skills faster, because there's a baseline level of knowledge that's already acquired which makes the barrier to "mastery" much, much lower.

Work smarter, not longer. Really.

evol262
Nov 30, 2010
#!/usr/bin/perl

Protokoll posted:

Everyone I know that is successful (i.e. makes a decent salary) is either one of X people in the country that can do something (my buddy works with nano-optics and he's one of 3 people that can do what he does), they work like a loving crazy person or they found a miracle job. I can name 20 friends in different fields that work way longer hours than I work, specifically in the legal field (3 of my best friends work 80+ hours/week), the technical sciences and in IT.

I guess the counterpoint to your anecdotal evidence is the people coming out in this thread. You don't have to be "one of 3 people, work like a crazy person, or find a miracle job". The average job (especially on the west coast) will pay a CCIE a "decent salary" at 40 hours a week. There are people who like working 65 hours a week and getting called for everything, and it's great if you're one of those. But it's not a prerequisite to a "decent salary".

evol262
Nov 30, 2010
#!/usr/bin/perl

Protokoll posted:

I don't know that this is necessarily true. I think if the volume of [things you want to learn] is large enough, no amount of experience is going to be a substitute for raw hours. I'm also somewhat unique in that I can remember the ASN/RD:RT/non-unique IP addressing scheme/routing protocols used by basically every customer on our network, almost everything I've ever been told or read as it relates to networking, what I ate on March 13, 1997 and the Office 2000 product key from my first job out of college, so I'm able to learn differently than most people.
I don't want to keep beating a dead horse, but that Heinlein quote:

Time Enough for Love posted:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

Is almost close.

When you can provision a LUN, configure a switch, parse a regex, use a raw socket in C, write a generic, troubleshoot VLAN trunking, write a perl oneliner, optimize a right join, read kernel sources, set GPOs, plan a vSphere deployment... Do you see where I'm going? If you get a broad set of skills, they cross-apply readily. I don't care about memorizing addressing schemes, though I'm certainly capable of it and I memorize some accidentally even now. But what's new and revolutionary to someone new in the field is, if not old hat, a reapplication of familiar principles to someone who's been around the block.

evol262
Nov 30, 2010
#!/usr/bin/perl

Paladine_PSoT posted:

This wears off. When it does, not only will you be re-reading what you read 7 years ago, but you'll also realize you wasted your 20's.

It's also not learning. A lot of people in the industry have the same skill. Knowing how to solve a problem you encountered 7 years ago does exactly nothing to help you solve a problem with extremely similar symptoms and a totally different root cause.

Protokoll posted:

I want to be an expert in as many different things as I possibly can before I die. That's it. That's what keeps me going.

Edit:

Hey, you can do that on 40 hours a week, too.

evol262 posted:

Resume quote

Not that I'm :toot:ing, but I have no degree, and I've been in the industry for less time than you. And I've been a Windows admin, .NET developer, Python dev, Linux sysadmin, Linux systems engineer, VMware admin, storage admin, network tech, etc. My expertise is Linux and UNIX. But I also know that I could get offers as a Windows admin. And VMware. And with very little work and a little luck in the interview, network admin. And... You can be an expert in as many things as possible. Because there are very few revolutionary things in the industry. Java and .NET are very similar. And Powershell along with those. If you know storage, networking, and Linux, you can do VMware. If you know Kerberos, DHCP, and DNS, you can do AD. If you know VMware, you probably know storage and networking. It all ties in.

There are niches. I'm in a niche. You're in a niche. But it all goes back and forth more than you seem to think it does.

evol262 fucked around with this message at 00:10 on Oct 22, 2013

evol262
Nov 30, 2010
#!/usr/bin/perl

Misogynist posted:

Anyone interested in an SH/SC mentorship exchange for people within our community here who are starting out trying to build careers for themselves?

I'm interested in this as well, despite my sometimes-aggressive demeanour.

evol262
Nov 30, 2010
#!/usr/bin/perl

syg posted:

Many people here have luck actually uploading resumes to indeed/careerbuilder/linkedin? Is it usually just bad recruiter spam?

Internal recruitment from $companies_youve_heard_of is big on LinkedIn. Google, Amazon, Apple, Redhat, Microsoft, Netflix, Facebook, VMware, etc. The "big names" in the industry also trawl LinkedIn, plus the usual non-tech companies that need tech people. I've probably had the best response from LinkedIn. Careerbuilder, Monster, Dice, Indeed, and the rest get you a lot of "keyword match for Java on your resume -> job requisition for something which doesn't match your skillset at all sent to you by clueless recruiter". And LinkedIn gets a lot of connection requests from random recruiters as well, to be fair, but the pain is worth the reward if you're not actively looking for another job but you're open to moving if the right opening comes up.

evol262
Nov 30, 2010
#!/usr/bin/perl

Caged posted:

I think a bit of light relief could come by finding bad job listings and tearing holes in them, so people know what jobs are probably best avoided and people trying to recruit know how not to list vacancies.

I have a number of needful requisitions on LinkedIn I could post...

evol262
Nov 30, 2010
#!/usr/bin/perl

insidius posted:

I was just reading the OP and a thought struck me.

Are there many people who can confidently straddle multiple areas of expertise?

Ie sysadmin/networking?

Can that be a path? Or should I only focus on one specific thing? The phrase "jack of all trades, master of gently caress all" comes to mind.

Ive been working for the one employer for seven years where the term sysadmin encompasses everything that is not networking. I have also now joined the networking team. I am starting to wonder if that means long term I might need to hang up my sysadmin hat. So far its been ok because I am only a junior and not all my time is dedicated to networking and when I am required its all switching related stuff rather than uber complex routing scenarios.

While it's unlikely that you'll be at the upper echelons of both network administration and systems administration simultaneously, it's certainly possible to become better than average at multiple problem domains.

evol262
Nov 30, 2010
#!/usr/bin/perl

Malkar posted:

On the topic of not sucking at my impending job, anyone have any good resources on bash scripting?
Learn perl or python instead unless shell is absolutely required for your job. You should learn it anyway, but it's not a great general-purpose language.

evol262
Nov 30, 2010
#!/usr/bin/perl

joe944 posted:

If you're a linux sysadmin you had better know bash. Most of the time when I'm doing something complicated enough to warrant actually thinking about using another language I'll write a ruby script. Basically, if I can write a one-liner to accomplish what I need done (90% of the time) it's vastly more efficient than writing a script in perl, python or ruby.

Which really wasn't the argument at all. You should know bash. You should know how to assemble a oneliner, whether it's a "cat something | while read" or "for ...". If you want to script, learn a real scripting language.

evol262
Nov 30, 2010
#!/usr/bin/perl

Malkar posted:

Yeah, to clarify, I'll be working in a Linux environment- I know a little Ruby, a tiny bit of python, but I've never really used bash scripts, hence my asking for a recommended resource.

TLDP's bash scripting guide is as good as it gets. But take it from a Linux guy: if you want to do anything more complicated than 10 statements or so, don't use shell.

Adbot
ADBOT LOVES YOU

evol262
Nov 30, 2010
#!/usr/bin/perl

Dilbert As gently caress posted:

Anyone down for just merging the IT thread with a mentoring piece?


I'd like to keep it as a "help only thread"; it seems we have a lot of lurkers but some people who don't want to ask questions due to nerd battles. Basically, I don't want people thinking about getting in IT or just starting feel worry about some high level nerd coming in an making them feel like rear end. I'd like it to be a learning experience thread for all.

E: I really need to refresh my avatar

I'm in, but if so, you should probably clarify "help" and its definition in the OP. Personally (and I'm probably not alone), I sometimes see telling people that their situation is hosed and they should gtfo or react differently as helpful. No problem participating in a feel good thread, but set expectations of :eng101: instead of :smugissar:

  • Locked thread