Find a job with better management and more interesting technical challenges, quit your current job, and re-discover your love for programming.

I screen resumes for signs that a candidate has done non-trivial things which may have required original thought and application of data structures, although I don't care whether that was at a day job, in a free software project, or in an interesting project class at school like compiler construction. I figure that people 10 years into their career who haven't managed to do that either lack the aptitude (and aren't going to learn it) or interest (in which case I don't want them either).

Once I bring them in we ask a simple programming question (about as hard as reversing a C string, doable in a single for loop although the most obvious solution uses a pair of inner loops inside a while loop, nearly all candidates worth hiring manage a linear time solution in not much over five minutes), a simple data structures question, a simple design question, another data structure/multi-threaded question design question, for some thoughts on software process, and the usual background questions.

As a competent programmer you'd have no problem getting through that (it's surprising how bad nearly all job candidates are).

I do systems software.

My last encounter with trees, threads, priority queues, condition variables, and mutexes was this afternoon and any one I hired could be doing the same thing on their first day of work.

I don't risk giving guys their first job, although I include free software and interesting project classes the equivalent.

I ask every candidate regardless of seniority (you can get surprisingly far in industry without much skill beyond high-level hand waving)

1) A simple programming question with a couple of edge conditions. It can be solved in one loop although I'm very happy with candidates who use an obviously correct solution with a pair of inner loops which totals 17 lines including braces where not technically needed added in the K&R style. I don't mind pointing out an edge condition that's been missed, just that they address it in the end (in the real world a test would find it).

2) A simple data structure question. I give an API with three functions, ask what data structures the candidate would use, and what the operational complexity on the three functions would be. I don't want an optimal answer, just something workable, and don't mind answers like "some sort of" that would lead to a book or web lookup. I'd be happy enough with an STL container answer; although pretty much everyone without the basics doesn't do well at that abstraction level either.

Candidates worth hiring in my opinion and the majority who've passed hours of less hands-on interviews take about five minutes for each (maybe ten minutes for the first problem if they've been withering away as a project manager which is fine) after which I ask a five minute thread question and spend the remainder of the time talking about what they've done and assessing whether they have attitudes about software test and process commensurate with time in industry.

Ones not worth hiring can spend an hour on the first problem and still fail to get it when I explain how it would work in English with diagrams.

I ask all of those questions and then quantify the quality of code, build system, and test effort by getting a code+test walk through plus demonstration of a build+test cycle.

It still fails
1) Following re-organizations into other groups with less lax standards

2) Following organizational pivots where upper management decides they don't have time for reasonable development processes (even though they make schedules both shorter and more predictable!) and spineless engineers go along with it.

>Alternatively, if he likes the place, it's an opportunity to step up and say "here's how we can do things better." If it's well-received, it's an opportunity to show both expertise and leadership.

Nope.

1. In some cases the decision to eschew good test automation comes from the top in an effort to reduce time to market by reducing total lines of code. To quote one CEO I worked with, "We'll add quality later" followed by mumblings about how engineering would rewrite the code a bunch of times and would to save time by getting to the final product and then testing." No number of personal anecdotes, quotes from papers and books, reasoned arguments, supporting arguments from executive staff, etc. showing that a smarter and more thorough test effort makes time to market shorter and more predictable will change things. The best you can do is take care of your own corner of the product, point out the places where you fixed certain types of bugs in X hours versus X weeks by group members not doing that, hope your co-workers join you, and hope for a leadership change that will be more receptive to your input before the company tanks.

2. Most developers can make it a decade into their career without both grasping the utility (fewer bugs reaching users that become irate, less effort to fix the bugs you do find, more predicable schedules so that death marches are less likely, less integration pain with fewer errors) of and choosing to apply good test automation and continuous integration. They can be impervious to talk, management buying people copies of relevant books (The Clean Coder, XP: Extreme Programming Explained, etc.) in their choice of print or Kindle edition and telling them to read it at work whenever they want, a rubber chicken or toilet plunger for whoever last broke things, etc. You need to get management buy in with leadership willing to hire and fire if people won't get in line.

In both cases you may be better off finding a more sensible job.

While at most half on home-row, Control-[ is a much smaller stretch than Escape which is so far up the left side you probably can't hit it without moving your entire left hand.

While languages are easy, transitioning from language controlled resource management (as in languages with garbage collected language memory management) to programmer controlled (as in languages with garbage collected memory management that do nothing with other resources like file descriptors) is harder.

I've seen situations where "java programmer" graduates meet the real world with file descriptor leaks that bring down "enterprise" systems resulting in customer outages with pagers going off, and would much rather have ones used to dealing with their own resource management.

In an ideal world the language people would have used reference counting, but we don't live in an ideal world.

Programmers without passion often follow the specs to keep their jobs but don't exert effort to correct incorrect specs.

Private offices are far less expensive than the cost to productivity from open office environments.

1. IBM Research studied the problem, and found that engineers are 40% more productive in quiet private offices than open environments. At a fully burdened annual cost of $100-$200K per engineer open seating could cost you $120,000-$240,000 a year.

2. It can take fifteen minutes to enter a mental 'flow' state. Once you get a high enough interrupt rate it's difficult to get anything done until people go home for the day.

3. Open offices encourage unnecessary communication. Where people might find answers themselves they ask their co-workers because it's easy thus saving minutes for themselves at the cost of up to fifteen minutes from their co-workers.

>Clearly, very few people here have any enterprise-level Solaris experience. In terms of stability and performance I compare Linux to Solaris like you compare Windows to Linux.

I used Solaris in a cellular base station billing interface appliance.

Moderate thread use crashed it out to the ROM monitor (we gained usable stability and a 100X performance improvement by switching to an event driven scheme) and sequential performance through the file system was half that of Linux (it was good enough for our use).

You can pick anecdotal stories to support any hypothesis regarding operating system stability you want.

1. Contribute to a free software project which interests you.

This will allow potential employers to verify that you can program before bringing you in for an interview, and hopefully you'll learn something about writing maintainable code so your first paying employer doesn't bear the burden of getting you over those hurdles.

2. Network.

Maybe a local group of geeks gather weekly for beer. Maybe there's an interesting user's group. Meeting people at such groups make access to un-advertised positions or to some one in engineering (not HR) that can be intelligent about who to bring in for interviews.

I get around that by not using an IDE except to debug Java I've written. In vim each source file, build error log, or document is separated by one character whether they're arranged side by side or vertically and there's no scroll bar or mouse needed. For compiled languages the debugger gets one window with a couple pixels around it plus a scroll bar with watch expression display together with source.

If an emacs user taunted me about running my debuggers in a separate window I might be tempted to get the Conque plugin.

While an arbitrary limit is bad, there's a point at which running into a limit generally means that indentation levels are getting too deep because function granularity is too coarse. You months or years later, your co-workers, and successors will all be happier if you fix the problem instead of trying to squeeze things into the 'letter of the law'. With name spaces and APIs having POSIX-length identifiers 80 characters is appropriate. 120 characters works for longer things.

A one-page function length limit with occasional exceptions is also a fine idea.

1. Professional organizations can offer affordable group plans to their members. One example is the Microsoft Alumni Network open to all former Microsoft employees. IIRC, their small business group plan was open to companies with 2 or more total employees which could be you and your spouse (paid to file your taxes or whatever).

2. Your single employee business can outsource its benefits to a PEO (Professional Employer Organization), some of which have no minimum company size.

Both options get you into large groups which therefore have relatively good rates for group plans, which is to say very expensive for young healthy people but relatively affordable for the rest of us.

Break everything down into approximately 3 ideal day pieces including unit + system test and adjust to real days using the velocity observed doing similar things in the same environment and you're likely to get close (within a factor of two).

You might get within an order of magnitude (days, weeks, months, years) without the low level design.

A lesser multiplier than order of magnitude generally applies when you haven't done similar things before.

And an even smaller multiplier (2-4) is likely where the environment changed (more customer support overhead, move from offices to cubicles etc.)

Having all the necessary conditions satisfied for accurate estimates can be unlikely in early stage startups.

An experienced unix user would use man -k

drew@l-drew% man -k burn
k3b (rpm) - CD/DVD burning application for KDE
nautilus-cd-burner (rpm) - Easy to use CD burning for Gnome

Unfortunately, the yutzes putting together Linux distributions (this is Centos) don't always include the man pages:

drew@l-drew% which k3b /usr/bin/k3b
drew@l-drew% man k3b
No manual entry for k3b
drew@l-drew% /usr/bin/nautilus-cd-burner
drew@l-drew% man nautilus-cd-burner
No manual entry for nautilus-cd-burner

Most "software engineers" can't solve simple problems in a reasonable time frame, don't check corner cases, and failed to retain computer science
basics from school.

        Mediocre ones fail to solve problems until some one steps in and does most of their job for them. Average ones are an order of magnitude less productive in terms of lines of code (which is a bad metric) than exceptional ones. Exceptional ones produce more maintainable solutions, make more efficient software, have lower defect rates, defects more likely to be caught by internal diagnostics, and shorter mean times to repair their bugs.

        Unfortunately, those things don't show up on resumes so you need to test.

        Many technical people fill their resumes with buzz-words but don't actually know what's on there. You need to validate that too.

        I ask all interview candidates a few simple coding problems regardless of years of experience. I ask simple data structure questions. I ask for technical details surrounding things they've done. People with surprisingly good back grounds (high GPA at a good school for newer graduates; lots of projects) fail.

        One was too offended to continue talking to us; although I'd rather find out that some one is too good and experienced to follow process (bug reporting, coding standards, design cycle) before joining the company.

        I worry when I interview at companies which don't check.