jlees

Atom Shell is a neat way of getting the desktop feel while using web tech. Is there an equivalent for mobile?

Usually some kind of finders fee, e.g. $10-20k for a software engineer placement in the SF Bay Area. Often paid after a specific period of work has elapsed (e.g. 3 months). Sometimes a percentage bonus based on the first year's salary.

(I am not a recruiter; I'm on the other side of the same spam, sadly. However, my partner has worked closely with recruiters and gave me a massive braindump of the space just a few days ago. Would love to hear from some actual recruiters.)

Left Google about a year and a half ago; leaving at 4pm is pretty unusual from the folks I worked with, though I had a couple of team members who would have 'pick up kids from school' blocked out on their calendar, and taking a longish break midday or in the afternoon was totally fine if you didn't have any meetings. Most people I know tended to come in to get the tail end of breakfast, so 9/9:30, and often stay for dinner (6:30). I had a colleague who did 6am-4pm or so to avoid traffic, though, and another who wouldn't come in until about 4pm for the same reason.

It's difficult to work with folks with 'unconventional' schedules if they are involved in cross-functional or managerial stuff. Fine if you're an individual contributor, but if you need to get a few folks in a room together frequently (project leads, etc) and their working hours have zero overlap, someone's going to get grumpy. I appreciate flexibility in schedule, don't get me wrong, but I also appreciate a bit of self-awareness :)

Varies a lot between teams, even between individual teams in the same organization. Though the teams I was on were pretty good about cutting things if it was clear work wasn't going to all get done.

Most of the Lyft drivers I've spoken to recently lived in Walnut Creek or further out. I only occasionally seem to get someone from Oakland, let alone SF.

If you love math but are not so keen on software engineering, maybe data science could be an interesting alternative.

Maybe traditional work just isn't the answer. Or maybe a task you kind of like doing but can't find the will to finish on your own becomes a really awesome job, and your 'just because I want to' stuff remains a passionate hobby.

Coding gives you a lot of literacy beyond simply writing code to build systems; perhaps those skills could be applied in a slightly different direction, from SRE to teaching to writing a book (personally, writing's one of the things that turns into a chore when it's for money, but you might be different!).

> "we're looking for people who are passionate about [thing that literally no-one has ever been passionate about]"

I heard this framed pretty well last night by someone who worked for a video ads company. "We don't look for people who are bursting with passion to work on mobile video advertising. If someone came to us and said that we'd think they were pretty crazy. What we do want is people who are interested in solving interesting technical problems, and mobile video advertising just happens to have a lot of those."

It's mentioned in "Yes! 50 Scientifically Proven Ways to be Persuasive"[1], which despite the title, is a really interesting book. The Freakonomics blog quotes it here:

http://freakonomics.com/2009/04/24/yes-part-ii/

referencing this paper "Why Susie Sells Seashells by the Seashore: Implicit Egotism and Life Decisions" http://www.stat.columbia.edu/~gelman/stuff_for_blog/susie.pd...

[1]http://www.amazon.com/Yes-Scientifically-Proven-Ways-Persuas...

It's probably not so much news though since the Shoreline "tech campuses" shuttle up to Google, Intuit, LinkedIn etc was already a thing[1]; this replaces it.

[1] http://webcache.googleusercontent.com/search?q=cache:UZmmOAb...

I specifically meant the prohibited criteria, though I suppose as not drinking could be due to health or religion, it's also in a grey area... Could you sue someone for not hiring you because you don't fit in at the frat house?

"Not a fit" can get dangerously close to "You're not the same gender/race/orientation/age-range as our core team" (especially if that happens to be true).

Several programs get a commission _and_ charge tuition.

Definitely agree with this. I do see more folks out there (like myself) with one foot in both the data science and production engineering worlds, and my personal approach to the problem of black boxes would be to have more of us! Rather than some 'sucker dev' implementing a statistician's hack, a full-stack mindset means the data science is done with engineering considerations all along.

But even then, half the joy of data science is not really knowing what you're doing at first as you research and experiment, just as your first attempt at a production system for something complex will also not necessarily be the final thing. If you have both of these at once, you can end up with a 'production' system that looks pretty well-designed and, indeed, works well enough at first -- until the product outgrows it, leading to a somewhat uncomfortable transition later on.

My personal anecdote starts with my PhD research which initially used a combination of Perl scripts, WEKA and god-knows-what-else, on fixed pre-formatted corpora, and became a Python engine powering a Django web-app using the Twitter API - not exactly rocket surgery at Google scale, but I found the whole shift in mindset from research to execution extremely useful and totally recommend to any data scientists who have focused solely on research that you try the other side of the fence, at least a little.

Stripping things down and simplifying, getting that 80/20 balance right, that's also some of the investigative fun of data science and we shouldn't get carried away with our own cleverness to ignore the poor sods who have to use the models we build years from now. I was consulting on a project which had very complex visions of a layered AI system using machine learning to make key decisions, but given the stage of the project and the depth of ML knowledge of the team, it was way easier for the initial stages to use what was effectively a switch statement on pre-defined values instead. You can always add complexity!

Good training data's partly hard to come by because there's often reasonably poor inter-annotator agreement on sentiment datasets -- that is to say, humans disagree a lot in how we interpret a phrase. What reads like sarcasm to you might read like genuine enthusiasm to another.

It's pretty easy to load up a set of data into a crowdsourcing tool and use microtasks to rate it, but my experiences doing so weren't superb (even restricting to native English speakers alone).

A better source of data is starred reviews where you have the star rating and the review itself -- these come free with a sentiment rating, although plenty of caveats around normalization. There are lots of places with review systems like this and some (like Yelp) even make the data available: https://www.yelp.com/academic_dataset

Well, junior developers are just that: junior. That definition can range from 'just finished a coding bootcamp' to '4 years of CS with a bunch of practical internships'. Depending where a developer is on that spectrum, they may behave very differently when given a problem and a bunch of time to solve it.

For example, they might not realise that they should be looking into the framework. They may be scared to ask stupid questions because they don't think they deserve the job in the first place. They got a bit of harsh feedback from someone who didn't take their level into account, and mentioned a whole bunch of things they'd never heard of before, and now they're running around in circles panicking. But not saying anything about it.

Obviously a lot of this boils down to "it depends on the person" and none of this may be true. But here are a few thoughts:

Take a step back and think about what the expectations are and whether those are communicated at all. Assign a specific senior developer as an active mentor, and coach them on how to give constructive feedback if they aren't very good at it (it's a growth opportunity for them). Suggest reading lists, talks, and examples of best practices - including stuff that makes working on a team smoother, like source control, etc. Pair program for the first week or two. Code reviews (as small as possible), design reviews, and even giving them less freedom at first so they get confident rather than overwhelmed. Check in frequently so you don't get a steaming pile that could hopefully have been avoided :)

Another coworker might well value having it to run errands. But yes, having a Lyft style driver use it for the day is less viable.

Is Heroku sufficient? It doesn't have the email aspect but there are plenty of standalone options there. It abstracts away a lot of the headache from custom VPSen, as long as the sort of thing you want to host is supported. AWS OpsWorks could be an alternative.

At a startup I consulted for, we had a developer who had come via toptal.com. He was heads and shoulders above anyone I've worked with via oDesk etc. Good screening could find diamonds in the rough, though.

You could also google around for people who have done what you want (built extensions you like) and ask them if they would consult on this project for you.

And for the management side, growing an engineering team from 1 to N will teach you more about people and (early-stage) organizational dynamics than any number of case studies. However, learning by doing -- and potentially failing -- doesn't appeal to everyone, and you can certainly balance the "on the job" learning with book-learning too.

I did an executive MBA, and plan to move into people management at some point. I enjoy it and I love the feeling of empowering a team to be excellent. At the same time I feel that you need a solid base as a respected individual contributor, especially if you are leading the team technically rather than playing bug-assignment Tetris -- which is what I'm focusing on for now. Management can seem like a dirty word in engineering, but some of us like doing it.

Yeah, I'd be interested in folks' thoughts on Portland/Seattle. Considering a move up the west coast from SF.

That's one heck of a writing prompt.

To qualify yes. You can teach a beginner enough in three (hardcore, dedicated) months to get on the ladder as a junior developer somewhere. To excel? No way. You need to be very prepared to offer that beginner a lot of support on the job.

I'd say the closest things would be actual honest-to-goodness academic courses online, e.g Coursera/MIT/etc computer science tracks.

People won't onboard a freelance developer for a short project unless they are desperate (and startups can often be desperate in different ways), but they will onboard advisors and consultant leaders to get them through tough periods. The difference in actual day-to-day can be minimal, but it's how you present yourself. "I'm a CTO", not "I'm a dev (also a CTO)".

You could become a consulting CTO for hire. Talk to some of the startups in your target group, and to non-technical founders, to understand more about what they would pay for, and what results they would want to see in order to pay the bill. For example, selling the product might not be the goal; raising investment is more likely.

For some, it may simply be coming in, assessing the state of things, making a list of recommendations, and hooking them up with full-time CTO candidates.

For others, having a technical advisor who can screen, interview and hire their future tech team is incredibly valuable.

For MVP building in the specific stage you refer to, as others have said, profit sharing isn't a particularly reliable model. The MVP may never take off, and by the time it does, they may have built a whole team and rewritten your code.

Other than content, here's one thought. What if you built up a set of talented developers who need your skills too - junior folks looking for exposure to portfolio projects, senior devs happy with a 9-5 but wanting some intellectual stimulation and to learn new techniques and technologies. Then effectively set up a MVP shop, where you manage the first stage of the 'idea to code' pipeline, but hand off the bulk of the implementation to others. Perhaps these others bill hourly and you get a cut. You can even be a broker for just introducing the two and still get a cut, though smaller.

One thought, I think that this pattern of work can be detrimental sometimes. An engineer joining a startup doesn't want to see a bunch of spaghetti code written by some consultant who is no longer around. It's often the case that she has to deal with it, but it can be a red flag of sorts. There's a whole second set of consulting needs around transforming a messy MVP which has started to show traction into a scalable, reliable product. It's uglier, harder, and therefore probably harder to find people who are truly good at it. But a lot of that may be relationship-based -- understanding what the startup leaders really want and what's working, translating that into new requirements, and keeping them happy if the work required to make it scalable is a lot more complex than it seems from the outside.

Close - San Francisco - Full-Time

We're a seed funded startup based in SoMA helping transform how business development is done. Our network intelligence platform aggregates data about businesses and people from a number of sources to understand the movers and shakers behind professional transactions. We're building a product that users are literally begging for and dreaming about, and we need a great team to execute on the vision.

Hiring:

Product Manager - Lead our product development team to new heights. Experience with product market fit, enterprise products, API platforms and Agile required.

Backend (data) engineer - Help us get, understand, and surface new data. Experience with API processing, web crawling, Python, and designing scalable architecture required. Graph databases and machine learning a plus.

You'll be joining a fast-moving, rapidly changing startup in a space ripe for disruption, with a small, nimble team. If you can hit the ground running and thrive in the midst of ambiguity and chaos (hey, we're a startup!) then we'd love to hear from you.

At this time we are only considering local candidates. No offshore firms or new grads please.

Email your resume/linkedin and github, with a note on why this space interests you, to our CEO Falon: jobs@close.co.

> We switched from Hipchat and we didn't really have a good reason - it just felt better.

Exactly the same here. The whole experience (especially the first run flow) was delightful and we immediately felt great about the decision.

Well, I thought this was awesome. And the way they are promoting it (social media, Google.com homepage) is neat too.

As everyone else has mentioned, ask your peers to introduce you directly to the manager. A couple of things:

Include a brief but enticing paragraph on why you are awesome. It makes it a lot easier for the "intro-er" to forward or reword it.

Be respectful of the other's time. Depending on the company and job, some people really welcome a break for coffee for a potential hire or an interesting person; others are swamped, and the triviality of a "coffee date" will be easy to turn down. Try to gauge which this is.

Coffee meetings can be take, take, take. Try to give back. Maybe you have something the other could learn?

I think just getting the data is the hardest part; there are several corpora available in academia, but not so much outside it. Although you wouldn't need the full text of the paper, just the bibliography entry, which could be much easier to get. (My PhD research was initially on scientific publication citations but the corpus we had was small, ~200 documents.)

Scientific papers are also interesting because you can use co-author relationships as a secondary graph. You could probably infer all kinds of things from that!