Hacker Newsnew | past | comments | ask | show | jobs | submit | unshift's commentslogin

many employers request that employees provide a disclosure when discussing their products on social media


We don't, but generally do it out of an abundance of caution.

(disclosure: I work with the above two)


I think it's a pretty good policy.

Fake reviews/astroturfing comments can hurt a brand quite severely. The riskiest situation of course is talking about a competitor's product (which we kind of are here).

It doesn't have to sound like a legal disclaimer, but its nice to identify your relationship to the product may have (even subconscious) bias.


Successful spammers are absolutely targeting their emails. It's similar to when you search for something on Amazon and then see ads for it on Facebook -- the goal is to put an ad in your inbox (essentially for free) instead of paying for ad impressions.


That’s programmatic advertising. It’s a different beast while very relevant to the context of being continually monitored/profiled. If there's such a thing as targeted spam I've yet to witness it.


Google runs display ads, which are bid on by third parties who can use that data to target emails.


So your hypothesis is that Google took the knowledge of the search query and attached some sort of indicator that the user was interested in AA onto the user's personal data (in violation of its own policies for interest-based advertising on sensitive topics). Then, it mapped that user to a cookie (in violation of its own policy towards cookie-user matching). Then it gave a list of cookies associated with alcohol rehab to a 3rd party (also not how any Google systems work, this would be in violation of many internal policies). Then, someone was able to match cookies to email addresses (available, unfortunately, in the shadier black markets of the marketing world, but totally in violation of Google remarketing standards such that the 3rd party would be likely barred, if caught, from all Google systems). Then, the spammer bought the email addresses and sent the emails.

Alternate theory: someone at AA sold an email list to a shady marketer.


You're misremembering the article. The spam emails were claimed to be because of a Google Maps search. The AA link was because an app on the phone (probably Facebook) was mining the address book.


> (in violation of its own policies for interest-based advertising on sensitive topics).

Art galleries are not typically considered sensitive topics.


You'll have to explain how that's supposed to work. Are you saying that google is selling email addresses, that they are allowing people to supply content that they then send, or that the people running the ads are selling the email addresses? The first two I find extremely unlikely, and the third should not be possible, since running an ad does not give you info on who it was delivered to.


How does a display ad allow you to target emails without asking anyone for an email address?


It gets elaborate but you can essentially buy email address -> cookie mappings or make your own. You then sync those cookies with the ad exchange and then they're returned to you with every ad auction for that user.


Please elaborate. What can I read or search for to find out how this works? Is there anywhere I can go buy such data to see it myself?


I used to work for an ad retargeting company. Our advertisers gave us a ton of data that we didn't necessarily want along with pixel data that we did, including email addresses. So if you're logged in to some retailers website and they were retargeting with us, they might either accidentally or deliberately passing us your email address, which would allow us (if we wanted to) to map your email address to your cookie. We see your cookie look at galleries, bam.

Or, more legally, the advertisers could be part of a specific email retargeting campaign where they give us your email addresses, and then we can establish the mapping in a more direct way.

Obviously there must have been more shading goings on in this case, but the principle is the same.


Right, but how did the cookie get associated with a Google search query and then get to the 3rd party who did the shady mapping? That's what wouldn't have happened.


If they clicked through to the art gallery website (from maps/search) and the art gallery was running an ad/tracker network that already knew the user's email from elsewhere, they could put two and two together.


Cookie onboarding services are nothing new. To start, look at a company like LiveRamp. They ask sites that get users to authenticate to login, then you provide them with an anonymous hashed email address of the user which they match with they then use to match against a larger cookie pool. If there's a match, they set another cookie.

This helps solve the issue for advertisers using retargeting where cookies don't have a long shelf life. So they leverage 2nd party data sources to basically set those cookies again for them so they can continue retargeting.

They can also work with vendors to upload their hashed email lists from their CRMs and gain access to the relevant cookies in the pool to market to them.

Onboarding vendors like this tend to pay a CPM rate based on the number of matches they can make with their cookie pool, so really all that matters is that you have a massive number of people authenticating with email addresses.


Here's the other piece of the puzzle. http://marketingland.com/google-email-address-audiences-cust...

Once you have the email addresses(see unshift's comment above) you upload them to Google and then target the addresses with specific ads.


While unsettling, that still doesn't explain the data flow out of Google. Google wants your customized list of email targeting, sure. But they don't want to leak anything proprietary to others to use, such as search history.


Malware/spyware can easily explain that. That's all I can think of.


Yeah, but if you've got that on your computer, you have much more to worry about then your search history being used for marketing, and they've got much more lucrative ways of making money from you. It's a "It rather involved being on the other side of this airtight hatchway"[1] type situation.

1: http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...


Oh I don't disagree with you at all. I was just thinking of a case where google maps search leads to email spam related to your google maps search and that's all I could think of.


gunicorn + meinheld is even better than gevent in my experience. meinheld is written in C and offers a monkey patch option, and is a little bit faster than gevent. i'm using it with flask + sqlalchemy + redis with great success.


forget about the $3k you have left, what about the money you've already put in? it doesn't look like I can sign up anywhere to get any sort of service, so you have no way to generate a return on your investment so far -- so why would you want to put any more in?

my suggestion is to set up yourself a prgmr-like website, do the administration yourself (by hand), and spend a few hundred dollars trying to get some traffic and signups. if that starts to work out then take it from there. realize that more SSDs aren't going to generate any money; signups will.

a new website would be nice, but you don't have the money for one, and it's not clear it's worth trying to get one at this point. the pure ASCII look could actually instill some sort of confidence that your current website does not.

good luck!


your library has no tests! it's a good effort but I honestly wouldn't use it yet.

a few nit picks: i can't imagine a scenario where i'd want my logger to close stdout (or any other file descriptor) for me.

there is a lot of missing error handling, which is really important for something critical like a logger. what happens when disk space runs out? no timeouts on network operations?

also your SMTP and Gmail loggers don't form valid MIME messages (I can't log non-ascii?). you also seem to just swallow exceptions which is totally not what I would want or expect from a logging library.

keep at it though, the logging module's API (inspired by log4j) is fairly painful.


    > your library has no tests! it's a good effort but I
    > honestly wouldn't use it yet.
You're right, and I'd love to have you help me add them!

    > i can't imagine a scenario where i'd want my logger to
    > close stdout (or any other file descriptor) for me.
By default it won't -- see https://github.com/peterldowns/lggr/blob/master/lggr/__init_....

    > there is a lot of missing error handling, which is really
    > important for something critical like a logger. what
    > happens when disk space runs out? no timeouts on
    > network operations?
    > [...]
    > you also seem to just swallow exceptions which is totally
    > not what I would want or expect from a logging library.
Lggr will fail silently by default, because your logging library shouldn't cause your code to crash. If you'd like, it's quite easy to stop it from suppressing errors. For more complex error handling, I think users should write their own coroutines for handling log messages -- the default file printing and network sending coroutines are merely the most basic case.

    > also your SMTP and Gmail loggers don't form valid MIME messages
    > (I can't log non-ascii?).
Please help me and add loggers that do format valid MIME message! The included loggers/coroutines are just a few examples I came up with, but I'd love if other people were to contribute more :)

    > keep at it though, the logging module's API (inspired by log4j)
    > is fairly painful.
Thank you, and thanks for your feedback :)


please don't do that. part of what makes using jquery plugins so horrific is that every new version is a "total rewrite" and/or drastically changes the API.

the API might use hungarian notation, and you might have fallen out of love with it, but so what? it's a pretty decent API and there's no real benefit to users in changing it. they'll all to have to update/rewrite their JS to stay up to date with the library for effectively no reason.


Thanks for the feedback - I really appreciate it. I'm currently in the middle of developing v1.9 of DataTables and backwards compatibility is key for me here. v2 is a good way off, and I'm certainly not committed to removing the hungarian notation (actually I find it quite useful personally). 1.x and the current API have been going since 2007 and is going to be supported for as long as I can see at the moment. If there are any breaking changes in v2, will be supported in parallel.

I know I don't want to update my own code for a new API on every release! Going back to the point of the OP there are certainly cases when writing custom code is beneficial for that reason, and equally (I believe) there are times when a tried and tested library such as DataTables is suitable.


why? college is not a job training facility and shouldn't be treated like one. high school's goal is to provide a broad education so a graduate can have the basic knowledge necessary to function in society. not everyone goes to college.


In the US, people are encouraged to go to college so that they can get higher-paying jobs. It's seen as a job training facility.


This discussion reveals one of the problems with our system of higher education: for some people it's one thing, for others it's something else.

Colleges are like companies that are trying to do two very different things at once: broad education and job training.

In the world of startups we know what to do when that happens: Choose one direction and go with it, stop trying to be all things to all people. Blended business models rarely work.

My guess is that something similar will eventually happen in education. Some institutions will specialize in getting you a paycheck and others will specialize in broader education.

I view purely academic coursework in the same category as other luxury goods: it's something some people find fun and exciting and if they want to pay for it, so be it, but society should not foot the bill.

Whereas practical "get a job" coursework I view as something that just about everybody needs and maybe there's a good argument for public subsidies or other policies that encourage it.


i've found scrum to be the worst possible "methodology" on the planet and can't stand pair programming. i've also been known to get things done on occasion.

nothing about making software is one size fits all. forcing scrum and pair programming sounds like a really good way to get an enthusiastic team, but guarantees little else.


couldn't agree more.

if i had to come up with a permutation algorithm as part of writing code, you'd better believe i'd look one up so that i'm sure i'm doing things optimally. i wouldn't trust myself to come up with the exactly right algorithm on the first try.

if i had to deal with some weird half-sorted array, i assume i'd be working in the same context as the problem and wouldn't have to make up a solution on the spot with limited details. why do you have a weird-ass data structure like that to begin with? that's the first question i'd ask.

personally i always ask a couple of simple questions (like FizzBuzz) and then talk experience. if you want to see a code sample, ask for one -- written on a computer, without someone hovering over the candidate's shoulder. coding solutions to weird questions on a whiteboard doesn't help anybody.


These questions aren't about "real world" situations, they are about problem solving and basic coding. Questions are good, as is a discussion on how and why these things should be implemented.

For the split array problem I rarely ask for code (only when I think it will actually help the candidate), it's just a discussion. It usually goes something like this:

    Candidate: Well I can sort it first, then do a binary search.
    Me: How would you sort it?
    C: I'd use quicksort.
    M: Can you do better than an nlogn algorithm?
    C: Well I suppose since it's two pieces that are both already sorted, I can just find where they are split and then rearrange them.
    M: How would you find the split?
    C: I can go through each number until they stop increasing.
And so forth. The "best" solution (that I've come up with, anyway) is to find the split using a modified binary search, and then use a regular binary search on the piece that might contain your query. Not everyone gets that and that's okay.

In addition to asking coding questions I always ask candidates about previous experience and projects they've worked on. Sometimes the answers to these questions are more important. Most of the people I have been interviewing, however, are recent graduates or students who are just finishing college and may not have much experience or many projects that really engaged them.

I spend a lot of time thinking about how I can improve interviews within the confines of how my company conducts them. I've stopped asking the permutations question as I feel that it has too much of the "aha!" factor in that either the programmer goes "aha!" and solves it or they don't.


You should highlight, recent college graduates. If someone does get hired to your firm, I hope the "real world" problems are just as interesting.

I actually like those type of algorithmic problems you highlighted. I am not sure, what it measures other than the recent graduate knew his/her data structures and read their MIT Algorithms books really well. Very few jobs do require knowing that fundamentals that in depth. Are we writing a Kernel, or a file system? Are we writing a new type of java collection.

The type of real world problems that in the class of the 2 problem solving problems you mentioned seem far in few, unless you writing something new, that really needs to be optimized in some way.

I think this is a real problem with computer science schools. It great to teach the absolute bare essentials. But I think schools should also teach some modern programming and not leave it on the kids to learn on there own.

College grads that know modern frameworks, Node, ROR, they know javascript and ruby really well. They have written some nice web apps. Those are the ones with the best job perspective. They have proven they can do the work.

I can understand if you were interviewing for the core google search team. Their optimization's make the company money.

Remember what Knuth said about optimization.


I think the best programmers are ones who can utilize abstractions while at the same time understand what they are abstractions of. For example, someone who knows Django and SQL is probably a better programmer than someone who knows Django but doesn't understand what a relational database is.

While people might not need to write searching and sorting algorithms much any more, understanding the difference between an ordered map and a hash table can be crucial in many common "real world" scenarios.

I also have tried to stress that the answers to my algorithm questions are only part of the criteria in determining whether we hire someone or not. I brought them up because the OP asked specifically about coding questions, not hiring questions.


You probably get a few false negatives out this, depending on how good you are at drawing people out. Some people would be thinking "this question seems easy enough that I should be able to solve it without asking dumb questions, but I'm so nervous I'm not thinking straight" and then just freeze up. You should be able to draw them out, though, as long as you're aware that the reason they're not answering is mostly because they're nervous. It sounds like you've done a lot more interviews than I have, so I'm sure you could handle it. It is harder when their facility with English is poor.


My first intuition was that you could somehow write a binary search with two pointers throwing about half of the array away each time. I ran into issues with this train of thought because there might be duplicates in the array or the array might be all the same number.

My second thought was just do a linear search and if you happen to find the pivot, store it, and make the array sorted. Subsequent calls therefore would result in a binary search.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: