Well, any time you're storing data in a central place, you have a greater consequence of failure. That's a downside of "cloud computing", or any web application that stores data in a database too.

The alternative approach is everyone to have a local version of their data, which will be lost by individuals all the time but not by everyone all at once.

Obviously, if you have a server that's a single point of failure for your company, and you botch a maintenance, something went very wrong. And not having a backup - it seems strange for a company that's been around the block a few times and has big resources behind it. You have to write this off as more of a specific failure and not a failure of the concept of storing data on a remote server.

I do have a good friend that works for Danger - I really don't envy the week he must be having.

Good! Cursive is a skill for writing fast, not for writing legibly. I haven't used it since leaving school.

Print is easier to read in the circumstances where you can't use a computer, and those situations are rapidly decreasing. The vast majority of interaction and professional work is typed these days.

This is the counterpoint to the recent article asking if typing should be taught in schools - yes, in elementary, in the slot that cursive used to live in.

Well, a good interview test isn't about trivia or things you could find in 30 seconds of google. It's things like: What does this code sample print to the screen? Write a regular expression to capture the phone numbers from a file with the following sample data. Write a SQL statement to select all the people from these two tables who have an outstanding balance (ie, can you do a join). That sort of thing.

Well, I mean, it's hard to really compare the before and after, because you don't follow the people you don't hire. It's all going to be anecdotal. That doesn't equate to blind, though.

But anecdotally, we expanded at WhitePages.com from about 8 programmers before we implemented the test, to a team of about 20, in the space of about a year. The quality of hires after that point was, IMO, very high, and more consistently good than before. (Only one was an abject failure, and that was for personal reasons that had little to do with his capabilities.)

And it's a mistake to distinguish between 'taking tests' and 'actually writing code' - what do you think is on these tests? (Hint, it's writing code.) Multiple choice is okay (and my current job has one of those), but actually writing real code is substantially better.

I've worked several places that had some sort of practical skills test for programmers.

I consider them a strong success.

There's a surprising number of people that can talk a really good game, but fall apart when asked the most basic actual questions. And, conversely, people who aren't extroverts or for whatever reason aren't stars in the verbal part of the interview, but clearly know their stuff when given a written test. It's a really good way to fairly judge technical skills across candidates, and weed out the fakers before you have to fire them later.

And as an employee, I like working with smart, competent people. I know how much, from experience, a bad hire wastes my time and ruins morale, so I'm happy to work for places that put out effort one way or another to not enter into this trap.

Anyone who'd refuse on principal, I'd worry is either a) faking it, or b) too arrogant to work well with others. A good candidate is happy to prove that they're a good candidate, and won't have to work with idiots.

A test isn't the _only_ way to do this. Any sort of nice, concrete technical grilling will do. But for a programmer, it _must_ involve actually writing code of a non-trivial nature. You can't believe resumes - even if people aren't lying, a Senior Programmer at one shop may only be barely competent at another, and not even realize that the bar is set differently.

Of course, the quality of a test can vary just like the quality of an interview question, but the goal is good for the company _and_ the employees, and in my experience it works better than most techniques.

Now, if your shop isn't terribly compelling based on product, and you're desperate to not turn people away... well, you probably should be looking for places that feel like they need a test to screen out unqualified candidates, so you can stop hating your job, and not worry about fixing this particular problem. :)

You should clearly get them a ThinkGeek gift certificate. $20 gets most sysadmins a T-Shirt they really would like.

-- Kirby, ThinkGeek programmer

(Okay, see, I'm biased, but I'm _still_ right.)

You're not going to come out of school with the expertise to be a professional software engineer in any case, whether you focus on one language or many. It's a hard job, and 90% of what makes it hard are factors of time longer than a quarter/semester, and factors of dealing with non-Computer Scientists and people with demands other than your professor.

It's okay, we (the hiring industry) know this, and a lot of us are willing to put in the investment to do the appropriate apprenticeships. CS Degrees are one way to select people who are more likely to succeed, but it's a discipline that's only learned through doing for the most part, and best done with people who are more senior teaching you. (I self-taught a lot after my CS degree, but I advanced more in the first year I had a real mentor than I did in the previous 6 I was doing it mostly myself. But people do vary, and if you're the exception, great.)

I'd recommend the variety approach, because people _do_ vary. Some people love the rigid structure of a Python, the massive infrastructure available to Java, the exposure of the bare metal of C, the total control of Assembly, the flexibility and rapid development of Perl, or whatever suits you. At this stage: Try a lot! Find a language you have fun with, and code more in that. You'll be a lot happier with your job if you don't find the language you use every day to be high in however you define bullshit. And if you don't fall in love with a particular approach, you've got a lot more starting nodes for your resume and can do a broader job search.

Employers have hired college students before, and we know that what you learn in your CS classes with respect to being a professional programmer is _really_ not that much, and hire more for people who we think will learn quickly, not be a pain in the ass, and actually have some amount of work discipline. Whether someone took one or three C# classes is not very interesting. (Personal side projects using the language of choice, those are more interesting.)

Good luck!

I tend to think that the goal is not to learn specific instances of skills in college (ie, a particular language), but learn principles. It's very much worth any science student's time to know a programming language. It's a reasonable thing to learn programming well enough to pick up any language - but really, this is one path of many, and is probably best called 'minor in computer science'. Yes, Fortran is not exactly cutting edge, but it's a fine example of one kind of language.

If you wanted to learn the language most commonly used in science labs, sad to say as a programmer type, probably spend some time with Visual Basic.

As an ecosystem, the best thing is probably variety. It's good that some percentage of new graduates know Fortran, so it doesn't become burdensome to hire people to work at places with legacy codesets, but it's also good that it's possible to hire someone working in a language that might be more suited to what you're doing. Or to a different type of brain. Diversity is good in a larger sense - someone who might be a mediocre Java programmer might be a star Perl programmer, and vice versa. The more diversity gives more individuals a chance at finding a niche they excel in. I think this aspect is overlooked massively when people talk about 'the right tool for the job'.

If you're a scientist that likes programming, though, a minor in CS so you can pick up whatever language comes your way is an approach with a lot of practical potential. (Or a double major, but CS is hard and most Science programs are hard, so I'm not sure it's worth it - even the people that hire programmers that like degrees would not find fault with a Physics degree and a CS minor.)

The same way anyone else gets respect. Actually get to know your coworkers, make sure that they know you understand their concerns and needs (and it helps if it's true), be someone who isn't just the weird guy in the server room that nobody ever talks to.

Don't consider getting to know your coworkers to be 'politics'. That's an anti-pattern.

It's not a cure-all, but if at least some people start thinking of you as a human with a name, and actually trust you, it helps a lot.

And also, return the favor. They're not just users violating policies and expecting miracles - they're stressed out people with demanding jobs that need support. If you don't respect them, it's _blindingly obvious_ and they will respond in kind.

Not everyone's personality is suited to this approach, but a little bit of empathy goes a long ways.