MalcolmDiggs

I'd recommend Stripe. Braintree is also popular.

First, I'd really ask yourself if you need an office.

* San Francisco Public Library has fast wifi, private meeting rooms, etc. I worked there for months after I got sick of giving Regus all my money.

* WorkShop Cafe (http://www.workshopcafe.com/) is awesome, and charges you 2 - 3 bucks an hour to work from their space.

* There are lots of free cafes, hotel lobbies, bookstores, parks with free-wifi, and other places to work.

If none of those work for you, check out WeWork, RocketSpace, NextSpace, Sandbox Suites, etc. There are so many co-working spaces available, that I'm sure you'll be able to find one. They typically have a waiting list for private offices, but there's enough turnover on the open-desk areas that you can normally squeeze in.

In no particular order, I'd recommend reading:

* Introduction to Algorithms, by Cormen et al (aka "CLRS")

* Any of Robert Sedgewick's books on Algorithms ("Algorithms is C++", "Algorithms in Java", etc)

* The Art of Computer Programming by Knuth.

* If you want a more math-focused approach, Knuth has another book called "Concrete Mathematics" which might be worth your time.

* If you want something fun and accessible check out "9 Algorithms that Changed the Future" by MacCormick

The more you do it, the less nervous you'll feel. I'd suggest lining up a series of low-stakes 'practice' interviews (10 or more of them). Real jobs at real companies, but the kind of jobs you don't particularly want, and the kind of companies you wouldn't normally apply to. That way you won't feel any pressure to perform well; and you'll get practice interviewing. And who knows, you might luck into the perfect position just by chance.

A list of things that DONT annoy developers will probably be shorter.

1. Twitter for Dolphins

2. Square for Triangles

3. Tinder for Forests

4. Uber for Poop

If you need time, take time; there's really nothing wrong with that. That being said, you could always line-up your next gig, and push the start-date out 2 months; just to cover your bases.

Ad-tech is such an odd-space. Every glimpse I get of it is fascinating: huge scale at minuscule latency, hard engineering problems, super-high valuations and exits: and yet, if you told me the top 10 names in ad-tech, I probably wouldn't recognize any of them. And I think most people are the same way. It's just a weird black-box sector of tech that almost nobody talks about. Not sure why though...

How about both? I worked full-time through most of my college years, as did many of my classmates. It's rough, but not impossible. Night classes, early morning classes, online classes, etc.

I did the first half of my career in the Bay Area (>10 years) and am finishing it in NYC. Been in startups in both places. Here are the biggest differences I've noticed since moving to NY:

1. Old money. In California, the VCs and Angels I met were mostly self-made; they had cashed-out of the dotcom boom, or recently been apart of an IPO. They were all 20 - 40 somethings. NY is very different. I had never been exposed to the "country club" / "summer house in Nantucket" / "trust fund" scene before. It definitely feels like a different planet sometimes. So if you're raising money, be prepared to have conversations with the type of people you might have thought didn't exist anymore.

2. No echo-chamber. For the best and brightest in NYC, tech is often NOT the obvious choice. In many circles, going to the tech scene, (let alone the startup scene), is seen as odd. ("Why didn't you go into finance?" "Why didn't you go into law?" "Why aren't you a doctor yet?"). The greatest minds of the generation are becoming MOTUs (Masters of the Universe) at hedge funds and big banks. They're making a ridiculous amount of money, and really have no interest in this little tech thing we're doing. Talking about your startup in NYC feels odd sometimes. You're not praised or catered-to like you are in SF. Nobody really cares what you're doing, and nobody takes you that seriously until your run-rate is the hundreds of millions per year. It's a nice change in context actually. The SV echo chamber is gone.

Besides that (and NYC's insane weather), things are pretty much the same. Lots of talent, but it's expensive to hire. Lots of businesses, some good, some bad. Lots of VCs and Angels. Terrible rent, good food, etc.

Is it worth the move? Yes. Simply because when you move to NYC you may be seated at a cramped restaurant shoulder-to-shoulder with your next investor; and in SF you might see @sama walking down Market street. That kind of "right place at the right time" moments are more rare outside of those cities. Which coast you choose is entirely up to you; either way you're making a good move.

I think you'd be hard-pressed to find any single-provider that allays all concerns. Redundancy is the name of game. Any single-point-of-failure (in this case, a hosting company) is a bad idea.

Pick 2 hosting solutions you like (I'd recommend checking out AWS, Linode, Rackspace, and GCP), and build your systems redundantly on both. If they don't share infrastructure/datacenters, the odds of them both failing at the same time are small enough that it's not worth worrying about.

Sure, I get that. But even at 25 hours, you're grossing over 10k per month, no?

If it's an issue of finding clients, that, in my experience, has little to do with the technology choice. I freelanced in PHP for over 5 years, and I rarely (if ever) talked "tech" with clients. I kept discussions much more high-level than that. They didn't care how exactly I was building their projects.

Definitely check out RFP's (requests for proposals). Government agencies, universities, etc put them out. Start replying to them, and you should find plenty of work.

I'm a little confused. If you're working 40+ hours a week at $100/hour, you should be making > $200k per year gross. If you're only grossing $80k, then you're only working like 2 days a week. If that's the case, I think you're doing great! Just keep doing what you're doing, and add on a few more days a week (maybe take on another client).

Again, you're wrong. And yes, you clearly have every intention of starting an argument.

1. If you'd simply read the link (which you clearly have not done), you'd understand that a k-value of 2.0 means that each customer referred an average of 2 new customers. I never said "probability". You did. Yes, probability above 1 is impossible, which is why I never used that word. You clearly conflated the two, which is your error, not mine.

Here's why I said "likelyhood" (likelihood) instead of "probability": http://stats.stackexchange.com/a/2645

"...the likelihood function does not obey the laws of probability (for example, it's not bound to the [0, 1] interval). "

2. Reading-comprehension. It's not that hard.

1. Read the link in my original comment. There's no reason values above 1 would be "too good", many people achieve it. If you're going to be pedantic, you should get your facts straight.

2. Nobody said it "has to be" paid. The OP asked how "you" market your startups, and I told him what the companies I've worked with have done, in my experience.

This is a "voting philosophy" thread the day after the conventions end, and there isn't a single Trump or Hillary joke in here.

I'm disappointed guys...

People don't need a reason to not do something.

They'd need a reason to do it. So clearly the pitch above failed to give them a reason.

In my experience, there's usually two parts to this:

1. Initial external paid marketing (in the form of Adwords campaigns, email blasts, facebook ads, affiliate programs, etc).

2. Reworking the product until the "viral coefficient" is higher than 1.0. The viral coefficient(aka "k-factor" or "k value"), is basically just the likelyhood that one existing customer will refer another customer. So if your k-factor is above 1.1 for a given period, your initial userbase will grow over each period with no additional marketing needed.

In practice however, few startups ever reach a k-value of 1, so many rely on a combination of virality and traditional paid marketing in perpetuity.

[1] https://en.wikipedia.org/wiki/K-factor_(marketing)

I totally see what you're saying; and when I started freelancing I thought the same way. But the longer I played the game, the more I noticed an inverse correlation between the success of freelancers, and their perceived accessibility. It' much like hedge-fund managers, or attorneys, or personal trainers, any other bespoke service provider. The folks with very little information, who are hard to reach, and who will only take a meeting if you're referred by someone in their circle, those are the ones who (in my experience) are making the most money.

It's a bit like perceived scarcity. Building a flashy portfolio website really only says two things: "I have free time on my hands", and "My demand is so low I have to put effort into advertising". Sure, if you're just getting started, that might be the brand you wanna build. But as you gain momentum, having less of a public brand is often better for business than having more.

It's counter-intuitive, I know; and maybe my experience was colored by the freelancers I happened to know at the time. But it convinced me enough that I took down my website while I was freelancing full time, I only put it back up after I quit, (to use as a resume to get full time job.) Removing my online presence did wonders for my business, and that's why I recommend it.

Yes, and no.

Yes they can really help you organize larger projects easily. With variables, you only have to write things once. If you change your "black" from #000 to #1a1a1a, for example, that's one change instead of dozens. Nesting is another useful feature that helps you separate one page/module from another, and keep everything contained. Mixins and functions are super-useful if you find yourself re-writing the same stuff over and over. Also, the preprocesing itself is a great way to "lint" your styles (in a surface-level way). If there's a syntax error, the preprocessor will just fail, exposing an issue that might have gone unnoticed if you were using plain css.

But no, they don't help you write the most efficient CSS. So if performance is your goal, you can probably write better/faster CSS if you target each element manually, rather than letting the preprocessor target based on your nesting.

And no, they don't help you alleviate cross-browser issues; that's what auto-prefixers and shims are for. Those are different tools, also useful.

And no, they don't help you keep your css tiny, that's what a concatenators, minifiers, and utilities like "UnCss" are for. Also great tools, but separate ones.

If you want to get all the benefits you can, your CSS build tool will need to include many different phases. Preprocessing is only one phase; but may be an important one, depending on what you're looking for.

Also,if you want to get started, just rename your .css to .less or .scss instead, and preprocess it. Both less and scss are supersets of css, (so all valid css is also valid less and scss). You can write vanilla css inside a less file with no issues. That way, if the urge strikes you to experiment with the features of the preprocessor, you can do so immediately.

I freelanced for about 5 years, and honestly almost nobody EVER went to my website. It's a referral driven business; you shine through the projects you build for other people. If clients are satisfied with your work, they'll spread the news about you. I can't think of anyone I know who has ever gotten business from some random person who landed on their website. That's why many freelancer sites just contain contact-info and that's it.

"It's my understanding that the number of shares are a worthless number without knowing how many shares have been issued in total. Is this correct?"

Yes, this is correct.

"Is it reasonable to expect the company to give me access to the full cap table?"

No.

But, it IS reasonable for your contract to state what percentage of the fully-diluted capitalization of the company your stock options are granting you the right to purchase (at the time of the writing, or at a predetermined time in the future, like at the end of an round).

All that being said: All early employees are going to get diluted eventually (in most cases), and nobody has any way to predict how much dilution you're going to experience over time.

So, while it may make you feel better to know exactly what your options would be worth today, it's kind of irrelevant to what they'll be worth once you pass your vesting cliff.

The best protection, in that regard, is to only work with people you trust. If you're worried about being screwed-over by these people, and you haven't even started working there yet, that might be a bad sign.

It's a real problem, but so is promise-chain hell, and bound-event hell, and coroutine hell, and multithread hell, etc etc.

It's not black and white, and no library is going to solve all the issues. A pragmatic JS engineer is going to have to use many different tools in their toolbelt on a routine basis, it's just a matter of choosing the right tool for the job (which includes taking into account the environment you're working in and the code that already exists).

But in general, in my experience, callback hell is often a sign of an upstream design-pattern issue. If the procedure you're writing needs to call a series of 20 functions, in sequence, (and wait for them all to callback one after the other) you can probably implement it in a clean way that doesn't require your code to move evermore to the right. Frameworks like Express (which passes around "next"), and Mocha (which passes around "done") set great precedent of alternative ways to conceptualize those kind of issues. Achieving this in practice often means writing a combination of promises, callbacks, and other things.

I don't think there's a good reason to have only one resume. Tailor your resume/cv to the position (or type of position) you're applying for. For certain jobs (for your dream job, for example), it may be worth writing a special resume just for them.

Each hiring manager should be able to quickly scan through your CV and check the mental boxes in their head, so that they can move your candidacy on to the next phase. That's really all the resume needs to do. So streamline each resume you submit to make that process as quick and painless for the hiring manager as possible.

Later on, when you're getting to know the company (and they're getting to know you), that's when you can bring in your multitude of experiences that aren't directly related to the job. But there's no reason for that initial submission to be an exhaustive list of all your great qualities.

Both great.

AWS is great to the tune of $15,000 https://aws.amazon.com/activate/

GCE is great to the tune of $100,000 https://cloud.google.com/developers/startups/

I'd recommend doing both options. Burn through your credits on both platforms first, then make a decision about which one you like best... or choose none of the above!

Regex: ruining your life since 1956.

When a friend wants to start a business with me, I just tell them my rule:

I don't work with friends, and I don't make friends at work. I keep those two areas of my life completely separate.

The benefits are: you can make whatever business-decisions are prudent without worrying about upsetting a friendship, and you can make whatever friendship decisions you want without worrying about how it effects your business.

I have a similar mantra for business & family, never mixing the two.

In a single database, I don't think I've ever exceeded 50 tables. If a project of mine grew beyond that amount of complexity, it would likely make sense to refactor it into several/many databases.

In my experience: C++ is a rarified language in much of the startup world. Mobile devs can't use it in an app (with a few notable exceptions), front-end web devs can't use it in the browser, and backend devs are rarely working on problems of such scale, complexity or performance that C++ would be of benefit more than hindrance. (This changes as the company grows, but since you said "startup" I'm assuming you're talking about very early stage ventures)

That being said, there certainly are startups that use it, but they're often working in the world of embedded devices, IOT, etc; contexts where development on a traditional server isn't practical or even possible. Much of finance and HPC also use languages like C and C++ (not to mention FORTRAN and others).

So if I were in your shoes, I'd look up some startups where you'd like to work, and find out exactly what they're doing with C++. (You can often glean that kind of information from hiring posts, Angellist, etc.) Once you have that, build something as relevant to their business as possible.

Sorry for the vague advice, but here are a few examples: If you want to work in embedded devices or IOT, grab yourself an Arduino, and use C or C++ to program it to do something cool. Any complex behavior will demonstrate at least a working-proficiency with the languages. If you want to work in finance, maybe building some black-box trading software would be a fun experiment. Get creative, I'm sure you'll think of something.

I understand the manager's frustration. But, I think taking that kind of action sets a dangerous precedent.

IMHO, no matter how hard criticism may be to hear, (especially when it is entitled and baseless), you still want to encourage and reward employees and interns any time they go out of their way to try and make the company better, stronger, or a more enjoyable place to work. Not because you agree with what they're proposing, but because you want to encourage the free flow of ideas, and the voicing of concerns.

Moreover: When you take on interns, you take on the role of mentor and teacher, for better or worse. I seriously doubt that firing them was the best way to teach them anything.