Change majors, do a second major, etc. "Assuming I know the relevant programming languages and have some experience" is a big assumption. Computer Science (or any science major) is very hard to pick up part time. For your first job you will be competing with CS grads. I bet it will be an eye opening experience for you since CS grads do get an unfair advantage in the industry. The chances are you will have to take a much less lucrative position and will be playing catch up for many years. Ask yourself - why go that route?
If you decided to do programming - do programming. Consider yourself lucky to have it figured out while you are still in school.
> "...since CS grads do get an unfair advantage in the industry"
Really?
Considering that the IT industry is wide open to people without CS degrees, it is exactly the other way around. Engineering, Medical or Law students don't have an "unfair advantage" to their respective profession - they've simply met the minimum requirement. Meanwhile, a CS major has given up several years to maybe have a better shot of getting an interview, never mind a job.
1. Interview questions for fresh grads are very CS oriented. For example, I have seen candidates immediately dismissed for not being able to estimate algorithm complexity. Same for memory requirements. Same for variants of knapsack problem. Same for not being able to get to alternative approaches. Good luck getting those questions right without spending 4 years doing CS.
2. Internship. CS grads get 2-3 very solid internships on their resume. This comes up during the evaluation as a big factor.
3. The "he is not a CS major" comment popping up during the reviews unintentionally.
4. Cultural fit (very true for other industries as well). People hire people like themselves. CS grads have a lot more in common with other CS grads.
Google/Facebook/Microsoft/Amazon/Apple/LinkedIn/etc are at the top of the food chain. If you want to be the best, you have to compete with the best.
Ask yourself if you trust your partners. If you trust them, then don't even worry about head-hunters and recruiters. If you do not, then you should not be in the business together anyway.
There are so a lot more patterns of high availability architectures other than load balancing.
Distributed Queues, Pub/Sub, Gossip just a few that come to mind.
In your example, you are using what is called a classical three-tier web architecture - a Load Balancer + Stateless Nodes + Scalable Storage. The most interesting part of HA setup in a three-tier web architecture is HA setup of the persistent storage component. It looks like you actually haven't figured that out that piece yet and are waiting for a vendor (Microsoft) to solve this for you.
You can improve availability of your persistent storage (MSSQL) in several simple (or not so simple ways):
1. Use a SQL proxy load balancer (or a cluster setup) - a similar load balancer HA pattern you are already using
2. Shard. You will scale writes and significantly reduce the probably of your system becoming completely unavailable.
Disk device level replication like DRBD, plus a failure control framework like Linux Heartbeat, goes a long way in providing HA cluster for database. Since the replication and failover are at the device level, the solution works with any disk-based system, including databases.
In my experience, failure can be detected in seconds and switched over. Adding a reverse ARP setup to share a virtual IP for the clustering servers, the clients won't even have to talk to a different IP in the case of failover. The only case the clients need to handle is to retry upon failed connection, which they should have handled to deal with the occasional network failure.
If your article on how to architect for uptime ends with how the authors system isn't architected for uptime I don't think they should have written it. How do we know their advice applies once they actually institute the changes they talk about?
This is a really good point and I appreciate your viewpoint, but just because I wrote the article for/about stack exchange it doesn't preclude me from having done it differently at a prior employer.
Excellent points! You're quite right that there are a lot more things we could do to improve the high availability in the Stack Exchange environment. Unfortunately, I was hired well after the environment was designed so any suggested changes would need to not only pass the rigors of review by the team but also be able to handle the load that stackoverflow.com generates. Changing pieces at this point would be nontrivial and difficult to get approval on if it meant that we'd affect performance of our main property.
That being said, I'm 100% in agreement with you that the two options you supplied would be wonderful additions to our environment.
>Why do an audition project when you can fire candidates who do not work out within the first three months?
Because then good people won't come work for you.
I would not interview at a company that had a reputation of firing a significant portion of its employees within 3 months. Not just because of the obvious career and financial risk. But because a company that treats its employees as disposable is likely not to be a good place to work in general. And I doubt I'm the only one who feels this way.
Well it shouldn't be a high occurrence affair. I mean sure if they keep getting rid of people after 3 months I would avoid that company too. But keeping the option and testing the person over 3 months is pretty standard in every job I've taken. I've only seen it used once and everyone on the team agreed with the decision.
Well, if you end up firing a lot of people, give recruiting to someone who's a better judge of character.
Firing when things do not work out is an honest act. What does it have to do with disposability? Both parties will be better off moving in separate directions.
Also, I don't see how an audition will improve anything.
Life changes are the biggest risk to employees performance. No matter what you do, you are not going to predict life changes during the interview.
>Well, if you end up firing a lot of people, give recruiting to someone who's a better judge of character.
It's not just about judging character. It's about the amount of effort an employer puts into the interviewing and hiring process. Interviewing people well takes effort. But if you're willing to fire someone easily, well, why put in the effort?
In my experience, this feeds back on itself. The more comfortable the employer gets with firing, the sloppier the hiring process gets. Soon good people start avoiding the company, which means mediocre people get interviewed. So the interview standards need to drop further, otherwise no one would get hired at all (and besides, you can just fire them if it doesn't work out, so what's the harm?). Pretty soon you're one of those companies with constant churn, where no one seems to last longer than a year.
>Firing when things do not work out is an honest act. What does it have to do with disposability?
It's not about honesty, it's about empathy. A good employer empathizes enough with the employee enough so that they find firing to be painful, even if the firing is justified. But an employer who cannot, or will not, empathize with their employee basically treats their employee as a thing. And if they treat employees as things when it comes to firing, they'll treat them as things all the time. Which is an excellent way to create a terrible work environment.
But how an audition will improve anything? The marginal improvement in the new hire quality that you get from doing an audition is not worth the time and money spent on auditions plus the cost of lost candidates who took offers that did not require auditions.
Actually, I'm not advocating auditions. I'm also really not a fan of the StackOverflow/GitHub/you-shouldn't-have-a-life-outside-of-coding approach either. But just because that approach is overkill doesn't mean that interviews should be be treated lightly (and I think treating interviews lightly is unavoidable if an employer considers firing to be a routine tool).
This is often times the case. However, you loose several weeks doing the audition and you loose a few good candidates who took the offers that did not require the audition.
General Counsel gets a fat paycheck to take care of that.
Avoiding litigations is simple too - do not hire dicks; ever.
If you hired a decent person in the first place, and after two months things are clearly not working out, you can part ways in a civil fashion.
It's not always that simple. What if that person quit their last job to come work here? Quit and moved across the country? Gave up other promising opportunities?
I'm not saying you can't fire people, but unless a trial period is explicitly agreed upon beforehand, there's an expectation that a job will last more than a couple of months if the new employee is putting in real effort. I don't know where to draw the line, but even an employee who isn't a dick might sue if they rearranged their life only to be let go two months later; I'd argue that they also deserve to win.
This question says a lot about the interviewer too.
To me, the interviewer who asks the biggest weakness question is either clueless or a dick. Nice HR ladies who have this question on their checklist for "leadership assessment" are an exception - the checklist is sacred to them.
You are saying that you ask this question to gauge the attitude, creativity and interest. Yet, you ask the most uninteresting and unimaginative question to assess creativity and interest. What does it say about you?
You are saying that you ask this question to gauge the attitude, creativity and interest.
Actually I ask this question specifically because it is such a rallying point of angry, offended developers (specifically those who interview a lot, unsuccessfully, thus having a serious chip on their shoulder about the interview process). If someone is going to be a prima donna, unable to communicate with peers without a dismissive attitude, I desperately want to weed them out at the beginning. This question serves that purpose brilliantly.
What does it say about you?
Is this one of those "we're equals" things? I think the interviewees I adore the most are those that try to "turn the table" and interview me. Throw some hardballs to determine if we're worth their trouble.
We pay far above the norm. We have flexible hours and telecommuting. We work on fantastic technologies that are driven by our development staff. Meaning we are in the driver's seat. I will engage every filter I can conceive to cull the herd, and I've found that asinine question to be a perfect tool for that.
Again, you say that you want to weed out prima donnas. Yet, you act like a prima donna yourself with "we're not equal". Do everyone a favor - don't even invite people to the interviews when you don't think they are your equals - you are wasting their time.
You whole argument tells me you never actually hired people to work for you. Sitting on interviews and writing feedbacks is very different from hiring people to implement your ideas i.e. when your job depends on the work people you hired produce. Making talented people work for you when they don't have to is not an easy thing. Sitting on a high horse, like you are, it is pretty impossible.
The relationship between a candidate and an employer is seldom an equal one, and it's ridiculous to claim otherwise -- we already made the case why candidates should want to work for us, and now it's up to them to prove that we want to work with them.
There are exceptional employees who we'll tolerate the bullshit for, but they are the exception.
Making talented people work for you when they don't have to is not an easy thing. Sitting on a high horse, like you are, it is pretty impossible.
If this helps you sleep better at night, you go nuts.
Whenever discussions about interviews or interviewers come up, the vast majority of comments are naturally going to come from people with a chip on their shoulder about the process -- the bottom dregs who churn from interview to interview. If you think the sorts of comments that discussions like this yield represents the actual talent that employers are seeking, you are sadly misinformed in the internet echo chamber.
If you decided to do programming - do programming. Consider yourself lucky to have it figured out while you are still in school.