The Facebook IPO was a _huge_ success.

When a stock goes up and stays up following an IPO that means the company screwed up pricing their shares, raising less cash than they could have for a given dilution and/or unnecessarily devaluing investors' shares.

Facebook did it right.

Nope. I can accept that things happen differently in non-technical mega corporations and/or places without a critical mass of software people, although companies where software is core in viable startup hubs don't do that with "core" defined in Moore's core vs context categorization. Context activities are things that businesses must do like E-mail but doing them better than their competitors like sending messages in 10ms not 100 doesn't impact the bottom line. Core activities are those which do - better scalability and WAN optimization lets a cloud backup company serve bigger customers which pay more.

All but one out of a dozen places I've worked over 19 years in Boulder, Seattle (plus the East Side), and Silicon Valley did not do things the way you describe. Every competent software engineer who's worked in industry for a while knows that programming aptitude can be sanity checked in an interview, that knowing trivia is orthogonal to being able to do the job, and that other competent engineers will quickly pickup a language or library they're not familiar with (which is the easy part) while not so good engineers who know a language will never gain aptitudes they lack. Decent managers leave technical hiring decisions to a potential employees' peers.

Microsoft hired me to write C# professionally although I'd never seen the language before. I worked on Amazon products written in Java although I'd seen it once professionally.

There seem to be several aptitudes

1. Thinking through problems logically, identifying their edge conditions, and expressing a solution

2. Indirection

3. Applying knowledge to engineering problems

4. Parallelism

5. Recursion

which people have or don't.

In theory all should be pre-requisites for a computer science degree although in practice that is is not the case. My favorite professor taught data structures, graded students based on how their code did compiled and linked against teaching assistant defined automated test suites, and allegedly failed 1/3 of the class. The department wasn't happy with the failure rate (presumably due to their share of tuition dollars when people were forced out of a CS major) and replaced her. Graduates I interviewed for positions in industry before the faculty change were usually worth hiring. After they had a 50% reject rate.

I ask all candidates simple questions out of the first four categories, two with code. No trick questions. Engineers which do well as employees tend to make it through the current first question in under 10 minutes and the rest under 5 after which we can talk about projects and process. When I was young and naive I caved to management and overlooked a few problems but have since learned my lesson. People you don't want to hire can spend 45 minutes on one and not get to an answer. Probably 99/100 contingency recruiter submitted candidates don't do well there (I like to think that's because the vast majority of people you want to work with already have jobs, as opposed to there being that few competent people).

When it comes to projects I don't care how relevant what candidates did is to what my group is currently doing because they'll pickup the domain specific knowledge on the job. I sanity check that knowledge of what their resume said they did is consistent with actually doing it. I look for projects which are significantly meaty for their time in industry - while some jobs don't give you the opportunity to do neat things, after enough job changes failing to do that suggests a lack of motivation or aptitude neither of which I want. I look for scope and depth surrounding their work - successful software people are curious and absorb facts (like new domain specific knowledge) and I need them solving business problems as opposed to implementing code snippets I decide on.

I look for an increasing emphasis on software process with employee experience. Some places do things poorly, although once a candidate has had a few jobs and read some literature they should have strong ideas on how to avoid things detrimental to fast and predicable development cycles.

I only ask language specific questions where I'm concerned that a candidate isn't being honest on their resume. Some one claiming to have used C++ for a decade should be familiar with STL containers although they may have paged out minutia like the iterator, bool ordering in the pair which comes back from a std::map insert.

Pretty much everyone I've worked with and would want to work with again interviews the same way.

_Starting_ compensation packages for new BS graduates at the big SF bay tech employers are north of $100K.

http://www.netpaths.net/blog/starting-salaries-of-top-technology-companies-apple-google-microsoft-facebook/

Compensation packages for senior staff / principal level engineering positions for guys 15+ years into their career with meaty projects under their belt (fifteen years of entry level work won't do it) and no management detour at profitable companies are over $200K

In spite of that positions go unfilled.

Right!

My Dell Studio 15 with Windows 7 doesn't blue screen

  Instead it becomes extremely sluggish, unresponsive to mouse clicks, and I can't successfully start a task manager to see what's going on or get it to shut down normally so I need to use the power button instead.

I only use it for running Google Sketchup, Taxcut, Firefox, and the Mcafee anti-virus software which seemed like a good idea at the time.

Your CS grads don't do so well because they're inexperienced at such things and most of their post-pubescent life was spent where distraction by the big picture and being a team player had negative effects. Assuming you've done a reasonable job filtering out defective personalities in the interview process with a little mentoring they'll outgrow those problems and get back to sharing and being team players like they were in pre-school.

Exams and projects revolved around a relatively small set of facts and shallow
generalizations (it doesn't take much to wax eloquent for an hour or so). Any attention to the "big picture" which isn't covered detracted from time spent on the things which get you grades, college credit in high school via AP exams, admission to good schools, and scholarships. This was especially true once they got to college where accrediting organizations credit hour allowance is way out of whack with the amount of work some professors expect.

The few joint projects through that time period generally involved two people doing about the same thing (like alternating cuts on a rat) at the same time for a day. Outside those projects collaboration would have negative effects on the grading curve.

My computer science program only required one group project (three people where expected to spend a year doing something real for a company in industry) and that was unusual.

If you don't need to beat recruiters off with a stick it's because you're not using linkedin, live in the wrong place, or have big resume problems.

If you're at a career point where you're not satisfied with the jobs within your social network you need a linkedin presence (I'm trying for a start-up home run so I can retire and bootstrap my own companies without giving up my middle class lifestyle. Connections at big companies, small companies unlikely to see exponential growth, and startups with bad business plans don't get me there).

If you're really into writing software you should probably live someplace where there are lots of businesses where doing that well is essential to the bottom line. There's the SF bay area and every place else (41% of 2011 venture capital spending went to Silicon Valley and San Francisco ranks high too). Austin, Boston, Boulder, Raleigh, and Seattle/the East Side are most of the rest. Those places have higher costs of living where the salaries don't quite compensate although you probably spend more time working than anything else and are likely to be happier with the better job and a smaller home where you spend less of your time.

List all of the key words you've worked with. Eliminate those you don't want to do again (for instance, I don't like dealing with the Microsoft tool chain or library issues so I don't admit to having worked with C# even though I did so as a Microsoft employee.). Now you have your bases covered for recruiters, big company HR, and their key-word matching software.

Sort into categories somewhere along the expert / experienced / other continuum so you are not mis-representing your skills to the technical staff that interviews people and makes hiring recommendations.

If you are answering recruiter's emails and phone calls but not getting interviews it's because you have resume problems. The meat of your resume is written for engineers and managers. Engineers want to see what you personally accomplished technically. Managers want to see what you did in terms of leadership to deliver products sooner / more predictably / with lower cost and how your technical and non-technical contributions improved the bottom line.

If you're interviewing but not getting job offers there are problems with you.

I need to see that senior candidates have built bigger and more complicated things than junior candidates. I accept that in many situations candidates were limited by what was on the table, although after enough positions if they're not doing big things it's because they're either not interested or not capable in which case I'm better off hiring a less experienced candidate that I can grow.

I expect senior candidates to have practical experience with process and the things surrounding writing code and value doing them well because it makes delivering products faster, more predictable, and more pleasant for everyone. I've seen some real stupidity from executives "test code doesn't ship to customers" "we'll add quality later" and accept that many people spend time working in such environments, although after enough positions if they're not doing things it's because they're not interested enough in their craft do do a little side reading and experimenting or they have attitude problems ("I'm too good for unit testing!") in which case I'm better off hiring a less experienced candidate that's more likely to be trainable.

I look for four aptitudes in all candidates

1. The ability to think logically, identify edge conditions, and express that

2. The ability to deal with indirection

3. The ability to apply knowledge to engineering problems.

4. The ability to grasp parallelism

with a set of questions covering them that changes some with time. There aren't any trick questions here - engineers which do well as employees tend to make it through the current first question in under 10 minutes and the rest under 5 after which we can talk about their work history and other things. When I was young and naive I caved to management and overlooked a few problems but have since learned my lesson. People you don't want to hire can spend 45 minutes on one and not get to an answer.

I've never run into that but would take it as a good indication that I don't want to work at the company. Broader experience should imply exposure to other ways of doing things some of which translate to faster / more robust / more maintainable code.

You don't need to list what tools (including language choice) you used for specific projects.

There is a class of software engineering jobs where what you're doing is a lot harder than learning tools and APIs. Any of the companies you'd like to work for (and some you wouldn't) care more about that.

Microsoft hired me as an employee to write code in C# which I'd never used before and Amazon did the same for a position with a lot of Java although I didn't mention it on my resume and had encountered the language in one consulting project.

I wouldn't hire an employee who did not have experience in non-garbage collected languages because I suspect cleaning up after yourself comes from a certain attention to detail that's an aptitude rather than a teachable skill although otherwise I don't worry about language use.

It depends on how you define "real money".

I know a handful of people who retired or could have in their 20s and 30s with their earnings as "employees" which is real enough for me.

Senior technical employees can retain 0.25 - 0.5% of a venture funded company at the time of a liquidity event which is taxed as long term capital gains (currently 15% Federally) which leaves them with about 85% of it in the Seattle area, 80% in Denver/Boulder, and 75% of it in Silicon Valley to enumerate a few hotbeds of tech startup activity.

2B * 0.0025 * .75 = 3.75M * .04 = $150K/year for life

OTOH, if you define "real money" as private jets and celebrity parties there are more opportunities to get there as a founder than working your way into a CEO position at a big enough company.

Test driven development dictates when you write test cases (before the next increment of product code which can be validated) not what they test or the abstraction level at which they operate. When you're applying the methodology for it's benefits (other than getting you consulting income or giving you a religion to follow) that can be one method, a stack of programs, a class, or whatever point of the spectrum makes the most sense in terms of coverage provided and difficulty reproducing and fixing any bugs that are uncovered.

For reliable non-trivial systems with state (real world examples I've done include replicated NOSQL and block storage appliances using shared nothing clusters) this can take even take the form of a software model describing correct operation, mock environment providing deterministic execution order, and event/timing (including faults) combinations which vary according to a state search strategy and/or pseudo-random approach so you cover situations that you do not anticipate.

As a tangent that sort of testing is uncommon although neglecting to do it leads to huge problems. Google replaced a commercial replicated light weight database because it did not work and mentions the issue in passing in _Paxos made live_. In _MODIST: Transparent model checking of unmodified distributed systems_ Microsoft research applies model checking to three production systems with one running commercially on 100,000 machines and finds protocol errors in all three. I once found a five year old data loss bug in a shipping storage product when I did that and had a new guy fix it in his first week on the job.

The advantage is when you write the test in relation to the product code. Developed up front it's more likely to influence product code encapsulations and APIs to make test easier so you get better coverage and spend less time tracking down root causes. Since testing the code you just wrote doesn't block on writing the test the context switch overhead to fix the bugs you introduce the total cost to fix them is lower.

When misguided managers think "we'll add quality later" and try to cut corners on test development (they often get demoted and replaced after ship dates slip too much, but that can take a long time whilst your life is made unpleasant) it's not possible for them to ship a product prematurely (the product code is not done) and harder for them to damage the release.

As your software becomes more trivial the importance of doing this is less; although such simple work is easier to outsource or delegate to lower paid junior employees so more senior engineers might not have to deal with such situations for too long.

You need a better job. You may be able to change what's going on there (after a CEO change I got a 2 hour scrum reduced to a brief meeting every-other day with most updates happening electronically via Agilo for trac) to make it tolerable. That may be impossible or exceed your patience in which case you need a different employer.

Agile is awesome especially test driven development.

It's like when you where metaphorically young, made some trivial program not many orders of magnitude more complex than "hello world," ran it, saw everything worked, and were happy except it applies to non-trivial problems like replicated storage that still smells like a single copy of data.

Writing a test, making a change (which can be entirely non-trivial), knowing whether it works within 30 seconds, and being able to iterate until it does over minutes or an afternoon is far more pleasant than making months worth of changes which cursory experiments suggest work, dumping the pile on your QA organization, getting feedback that something's broken, making a change, getting feedback that something else is broken a day or two later, making a change, etc. as the release date slips.

Agile is great for business especially in startup environments where you need to get customers before running out of money and release cycles measured in hours are more conducive to that than ones taking six months.

Burn-down lists and velocity measurement are great for engineering and business. While engineers are good at estimating the size of things they're bad at mapping that to wall clock time in real world environments where tactical (customer support issues) and environmental (your open floorplan is too noisy for people to think 9am - 5pm) issues exist beyond their control. With feeedback on velocity you can come up with more realistic numbers for release dates so there's less stress for everyone involved and a better idea of what you can fit into releases on some periodic schedule so customers don't suffer as the release date and/or quality slip.

Micro-managing and calling it "agile" is bad for both engineers and profits.

Scrum is bad because you loose productivity when you force human context switches for daily meetings. Where you make the meeting early to avoid that engineers stop working exactly eight hours after the meeting start so they're not too tired the next day even though that may mean hours to get back to where they were instead of minutes to finish. If they do stay late to get something done they come to the mandatory meeting tired and the quality of their work is as bad as if they were drunk.

Scrum is even worse when mis-applied. People can and do turn the daily meetings into 1-2 hour affairs totaling 50-100 man-hours a week for a team of 10 people which can be $200 - $500K/year in fully burdened costs when you have senior people in high-wage areas.

Some managers like to use one burn-down list for the entire organization where
engineers are fungible commodities that do whatever is the highest priority regardless of scope and how far along they are in their career. That's a huge waste of money (in large technology companies some one with 15-20 years of experience doing meaty things can have a compensation package twice the size of some one with 1/10th that experience), reduces quality, and robs people of their self-actualization.

That sounds intriguing to me.

How do I apply auto-reformating to JIRA, gmail, bugzilla, Coverity, enscript, and the plethora of other tools which get used in the software development process?

I have.

A pre-commit hook in your revision control software to bounce changes which won't confirm does the job nicely with a

make style

target making achieving pre-checkin compliance painless.

Occasionally you need something which technically violates the style checker, although the need for a manual override via something embedded in comments like /* BEGIN CSTYLED */ /* END CSTYLED */

limits that to rare intentional occurrences.

That's a horrible idea if you can't get into the top 7 or so law schools.

About half of law school graduates can't get jobs as lawyers and many end up shuffling papers for $15 an hour. That might not be so bad in the grand scheme of things, although the average law graduate finishes their education with $150,000 on which student loan interest can run $1000/month so you'd need to live off $8.50 an hour to keep the principle from increasing which is poverty level.

"Like some Slashdot users, I began attending university last month for computer science.

Conversing with my college computer science peers (many of whom are quite nerdy), I have noticed that many of them are extremely arrogant. Upon introspection, I have come to the realization that I am also very similar to them and am very curious, but worried."

While a few of you are assholes for whom there's no hope, most of you are that way because you're young and not done growing up.

Your situation may be exacerbated by the college admissions process, where kids compete amongst each other to be in the top x% or 0.xx% to get in. Appearing to be better than the remaining xx.x% seems critical to your life.

Most of the real world doesn't work that way - you just need to get your work done well enough on time whatever that means.

"I have noticed similar personality characteristics on Slashdot. Where does this nerd arrogance come from?"

Many people are more obnoxious on-line where it's entertaining for them than in real life where it'd be a problem that gets in the way of relationships and promotions.

Having done software professionally for 20 years, delivered five non-trivial products built from scratch to customers for business critical applications (things like block storage on a shared nothing cluster of x86 boxes and a highly available cellular base station billing interface), and worked on at least a dozen other products I disagree (three big company re-orgs in 18 months and some consulting exposed me to a lot).

Fast or good is a false dichotomy. You can have both or neither and as an added bonus choosing "fast and good" also nets "less expensive" which is the mythical holy trinity.

Do things right and you'll make your initial profits sooner - either because customers start buying that product sooner or you pivot and get your next try out there in less time.

Software (whether packaged that way, as a service, or as a hardware appliance) products are about nested feedback loops within the larger business cycle of market needs leading to customers paying you repeating as you flesh out a complete product, build a surrounding ecosystem ecosystem, go vertical, etc.

Within that are the loops surrounding things engineers identify with like writing software, writing tests, fixing bugs, and making releases.

The things you do to make maintainable code reduce the time it takes to deliver a viable product to customers on the first AND following cycles.

Unit and regression tests reduce the time to fix the bugs you inevitably introduce. There's much less wasted effort when you write code, the relevant tests find a problem immediately (as opposed to waiting for a release to drop to QA or going through multiple release candidate - QA cycles followed by shipping to a customer that finds the problem), you have more information which leads to a quicker fix, and you have no context switch overhead. They also give you more latitude in what the people you have work on because there's little risk added by people working on unfamiliar code when there's enough pre-checkin coverage to make getting bugs to QA or customers unlike.y

Meaningful comments surrounding what you're doing facilitate neural pathway formation leading to a deeper understanding, more "aha!" moments, and fewer bugs. They get you back on track sooner after the inevitable context switch for tactical issues.

Refactoring reduces your bug count and time spent on problems because non-existing lines of code can't have bugs.

Things continue to improve as you get nuttier:

I was turned on to simulation (link your shipping product code to mock objects at a low level gaining control over scheduling (make it deterministic and get atypical timings via pseudo random or state search methods)) and model checking by a Digital Systems Research Center alumni I was working with on another clustered block storage appliance. It seemed neat and useful until I spent an afternoon moving a lower piece of the stack into the simulated environment and found the buffer reuse problem which had been holding up our release for a month. "Neat" became "you'd be dumb not to" for some class of software. In a subsequent commercial life I did the right things again and solved memory corruption problems which showed up under certain event orderings in hours where co-workers did not and took weeks for the same sorts of issues.

Tool building can pays huge dividends too:

A good logging system is not core to your business and something which people usually skip. However in practice it takes much less time to build a system which logs 300,000,000 (on a four year old pre-production dual socket Nehalem box) entries a second via a printf API into a circular shared memory buffer which survives process termination and allows development trace level logging in a production real time system (at only 300,000 user IOPs per second you could have 50 entries per operation before you got to a 5% performance degration and at just 10 you're pushing the measurement noise floor) and fix your first bug depending on the order of events (those take longest) than to fix a similar bug without the system. Hierarchical log categories (like protocol/replication/recovery, protocol/replication/meta_storage, etc) allowing inclusive or exclusive level based filtering (trace level for protocol except protocol/replication/messages which would be too noisy) get you there faster at effectively zero cost.

>Any other ways to find out code quality beforehand?

Absolutely.

That's what code and test/process reviews are for (there's a lot of latitude in how people have done or attempted to do what they talk about in general terms during your interview).

When I'm thinking about working for a company with existing code I ask for a code walk through, test over view, and demonstration of how the build + test process works.

You do not want to work for anyone who refuses because either they have something to hide or have an ego about how much of their product is "special sauce" that might get bruised if you need to change things once working there.

One of the companies I did this with didn't believe in unit tests and I figured that they'd crater because they couldn't make releases on a fast and predictable schedule with acceptable quality for their customer base. The VCs rescinded their funding for that reason plus the long and unpredictable sales cycle that goes with enterprise appliances which also had me running away.

This isn't fool proof - one company I worked for had good process but abandoned it in a panic when they realized they'd picked the wrong market and needed to pivot. Discussing the false dichotomy of quality and delivery speed (you can have both or neither) with anecdotal stories, delivering much more reliable features with out bugs leading to multiple release candidates built with good process, and having people read things like _The Clean Coder_ didn't help.

In many cases "buy" where buy can mean leveraging free software is the right answer not "build" for things that are not core to product value. You may still find yourself changing and cursing open source.

I also try to avoid that by joining new projects (not fool proof - projects get cancelled when companies pivot, companies often re-organize people to deal with tactical issues, some companies declare your product "finished" and ship it over seas for maintenance after which you join a new in-progress project, etc.) and/or new companies between series A and product design (surprisingly not fool proof - some smart people do bad things when direct to by bad managers. Two of my favorite CEO quotes are "Test code doesn't ship to customers" and "we'll add quality later." That had a lot to do with the resulting crater.)