In my experience, co-founders (technical or not) do a ton of work at all stages of the company. The work changes at different stages, but the load never does. I think what the above posters are referring to regarding the early technical workload is the technical cofounder often doing a lot of non-collaborative, independent work up front (not that it's "more" work at that stage - just that it's work that is less collaborative with teammates).
If that's the reason you are thinking of adding a "technical" co-founder to your team (i.e. you cannot do the first implementation of the product idea and you need someone to), I think you should stop and think for a moment... that very motivation is going to screen out your most qualified possibilities. I'm not trying to position myself as a great technical cofounder - honestly, I'm mediocre - but even I would head for the hills if that's what I thought was going on. Let me try to explain why:
I like that co-founder & cash flow can both be abbreviated as "CF," but even if there wasn't that symbolic equivalence, I'd still view those two ideas as one & the same. Here is part of my definition of a co-founder (technical or not): "A person who can create cash flow beyond the level of his or her incompetence."
If you already have a market, a product idea, and the belief you can probably hold down the sales and BD leadership elements of the company for at least several years, yet you cannot raise enough investment to hire an outstanding programmer as an employee, I don't want you as a co-founder. It's absolutely fine that you cannot code - you don't need to be competent at everything as a co-founder. However, if all you truly need is one absolutely outstanding engineer coding for one year, yet you cannot raise enough money to deal with that shortcoming on your team, you're also probably unlikely to come through with cash later. You don't sound like a good co-founder, to me at least.
Ok, that's a little harsh - the problem is not that you haven't raised money. The problem in my mind is that you are too myopically focused on the next 3-12 months of the technical challenge... which means you haven't seen a technical team being built before (or didn't notice how it was being built when it happened). You are selecting for the coding ability and hoping for the best when the MVP is delivered. Think of it like a technical co-founder trying to hire a CEO in order to make sales numbers for the next 3 months. I'm sure if there was a post like that, there would be a lot of objection.
A good technical cofounder can increase cash flow beyond the level of his or her incompetence. There are two sides to the equation - either they are increasing the money in or decreasing the money out. The two ways I know of to increase the money in are investment and revenue, with investment usually being more realistic. So, the first screening criteria you should apply is your first impression of the person and their resume as evaluated by title and company brand recognition. As shallow as this may sound, it can help raise money from investors. I don't think it's very correlated with coding ability (sometimes inversely so... the more impressive the resume, the further away from the coding the person often is), but it is likely correlated with raising money. Being able to position them as a "genius" or as an "experienced CTO" helps.
Second area is earnings, which on the technical side usually means a better product (more revenue) or cheaper product (better margins). This could come in the form of future product ideas, better product management or better technical leadership. I don't really know how you would evaluate this with someone you didn't know, but think of how you assess this with people you know well... then try to ask those questions of references that seem like the same type of person you are I guess.
On the cost side, here are broad strokes of what needs to happen for a web company's technical team. Anything the co-founder is good at is less money that has to be spent, identifying, recruiting, hiring, and employing someone else to do these parts (and don't just think of the employment cost - also think of the time spent recruiting the person and the likelihood that you'll have to fire a few of these people; if none of your team can do it, I expect you to mess up a couple hires... don't necessarily accept it, but do build it into the cash requirements of your business).
1) Actual programming (engineer responsibility). Yes, this is a real expense... but a lot of people can do it. A technical cofounder that can't bang out an MVP for you in 3 months is not necessarily incompetent or a bad choice. A person who can sure sounds like a good 1st technical hire, but not necessarily a cofounder. If you're making this a hard requirement to the role, you're likely just trying to save cash for 3 months. What is a hard requirement is the technical cofounder be able to implement an MVP with a reasonable amount of money... not the same thing.
2) System architecture (CTO responsibility). This is how things mesh up to each other. For most web companies, this usually has to do with how the databases interact with the server code and how either of those interact with the client or front-end code. For some reason, almost every engineer thinks that not only can they do this, but also that they are good at it, so you cannot evaluate this by asking them. Look for their experience with systems at multiple scales and get references for each of these scales. Also, you don't need this really early on - it's ok to throw that MVP away. However, there are only so many times you can throw away *all* of your code. At the point you can't afford to throw away 100% of your code (which happens faster than you think if you're on to something on the business side), you need someone like this employed at the company, and your cofounder needs to be ok following them even when he or she disagrees if they aren't it. This is not a design-by-committee type of task.
3) Technical recruiting (VP Eng responsibility). No substitute for having done this before - most engineers think they have recruited before because they participated in interviews and/or were given a veto on whether a new engineer was hired or not. The biggest challenge is the top and bottom of the recruiting funnel. You should ask how candidates are sourced and how candidates are closed. If you don't learn something by asking these two questions, then they don't know either - generic answers don't cut it here. They need to tell you a tactic you've never heard of (it can be minor), or else you're going to have to hire someone else to do this later. Also, have them full-on whiteboard interview a friend of yours who is technically competent. Get feedback from the friend on what they thought of the technical questions that were asked.
4) Engineering management (Director Engineering responsibility). Typical web company management encourages small teams (3-6), each with a leader and some kind of process to keep all the team leaders aligned with product goals. This is great to have in a technical cofounder in the first 3-12 months, but rapidly becomes irrelevant a skill for your cofounder as the team scales beyond 6 or so. Ask about their experience and opinions around this topic (again, specificity usually means competence; a 30 minute lecture on the general merits of Agile methodology over waterfall methodology does not), but don't get too sucked into thinking this is what you need. You'll be better off with someone who can easily hire this position for you.
5) QA (VP engineering & VP product responsibility). For some reason, this is an incredibly underrated area of expertise. You know what's more expensive than an incompetent engineering team? A competent one building the wrong thing. At least the incompetent one sometimes accepts your criticism. I don't know how to tell you to screen for this, other than be aggressive about asking questions. Find whatever product manager the person has worked with before and grill them on the QA procedures they used before.
6) Systems administration (sysadmin responsibility). Another wildly underrated, under-researched skill set. The ability to code in python has little to do with someone's competence at Linux. If someone has never coded in python before yet is a Java expert, there is 0 risk they are going to prove to be a "bad python programmer." If they've never really had to deal with Linux outside of launching the code they wrote however, this isn't a skill they are going to pick up easily. You avoid a ton of headaches and mistakes by having someone with this expertise in the company early on. You don't need a technical cofounder to have these skills (huge bonus though), but you do need them to be able to identify and recruit this ability (and want to) early on. Again, the sysadmins often get no respect and it hurts the company later on when you have a giant pile of crap you need to sort through.
Ok, well this post is way too long, but hopefully it helped someone... Personally, I don't think I'd ever cofound a company with someone I didn't already know painfully, painfully well (like, all their flaws); but if you're committed to doing that, here's my best closing advice (which I don't believe is illegal because finding a cofounder is not the same as hiring an employee): go for someone young.
It's incredibly unlikely you're going to get someone with the really important skills I've listed whom you don't already know: those people absolutely exist, but they like working with people they already trust - being able to hire them is already a questionable sign. Pressure makes diamonds though... find someone young with evidence for potential on the above skills and give them more responsibility than they've ever had before. Be positive with them, but be clear on what they need to do (and make sure they work like crazy): they've got a shot at becoming this person. As we get older, we lose that potential of becoming a new person. Make sure they don't have a crazy ego and think they are an equal partner in it though... not that you shouldn't treat them that way, but the only way they can learn fast enough is to be a little concerned they aren't actually qualified to be a technical cofounder yet. If they don't know that, they won't learn fast enough.
Also, use the above criteria to find an advisor - they will likely work with you; then use them to help pick the technical cofounder from your possibilities (you'll still likely have to find the possibilities though - don't count on them pulling a name out for you) . Be aggressive - former technical cofounders often don't market themselves as aggressively for advisor roles as former ceo cofounders. You might be able to get someone as an advisor that is well known (or whose company was well known). this can help you recruit.