End the Office? Students Want Right to Work From Home  - <AUTHOR> http://itechtalks.blogspot.com/2011/11/end-office-students-want-right-to-work.html

<comment><USER2> The problem is these people are only thinking about themselves, and not considering the affects of their actions on coworkers. They need to understand how to be a member of the team first, and after that they'll understand how much flexibility in terms of devices, working hours, and location is appropriate.

My office lets people have too much flexibility when choosing their work hours and location. --It's not that people don't work hard, but when you have inexperienced people coming in at noon, that ends up being several hours of time that they're working in the evening without being able to get help from more experienced people. If I had a dollar for every time I found out a coworker struggled for hours on an issue only to have me or another more experienced person provide an answer in 5 minutes, well, I'd have a much healthier retirement account.

Working remotely is also difficult as it can be much harder to properly explain things when you're not able to sit next to each other, point things out, and even grab a piece of paper to sketch stuff out in order to clarify things.

<comment><USER3> Excellent point.

I am near the start of my career (3 years in or so) as a programmer, and I spent much of the first part of that working remotely. Though I enjoyed not having to get dressed and drive in traffic to be at the office by 8am, this severely stunted the development of my work skills. Now, when I was working for a startup, I would spend hours and hours at home on projects and remained fairly disciplined, but that was due to the passion I felt for my work. When that startup folded I had to enter the regular workforce for financial reasons, and I found it much harder to be motivated about what I was doing. When working remotely, I found myself constantly distracted and unfocused, and even though I felt I had fairly strong communications skills, my ability to communicate with co-workers did not develop.

There are numerous problems with younger employees working remotely, but the way it stunts one's development as a professional is probably the worst. Now that I'm in an office, I am constantly exposed not only to people more knowledgeable than I, but also people who have learned how to be a professional and how to work in a team.

One thing in particular that struck me is that I didn't really know how to behave in an office. True, there are a lot of ways that the modern office is kind of depressing, but developing decent working relationships based on mutual respect with your co-workers does a lot to make a workplace tolerable and even enjoyable. This respect is not developed in most cases unless you actually observe and learn some office behavioral norms.

Working remotely can be awesome, and stodgy companies should learn that flexibility has its advantages. But these advantages are often strongest for experienced employees who know how to organize themselves and motivate themselves to get a job done wherever they are for little reason other than professional pride and a paycheck.

</comment></comment><comment><USER4> Why are we linked to some blog instead of the original source, especially when it's just copied verbatim and with an annoyingly low-res graphic.

Original source with high-res info-graphic: <http://mashable.com/2011/11/08/work-from-home-2/>

<comment><USER4> Looks like the OP is just trying to plug his "blog." Very lame.

<http://news.ycombinator.com/submitted?id=rajeshvaya>

<comment><USER5> Wow, those posts are just scraping content from other sites.

</comment></comment></comment><comment><USER6> Working from home isn't a right. I've done both (worked from home and an office) and it takes a certain kind of person to actually be able to get work done at home. The same sort of discipline that you need to run your own company. Most people just don't have this discipline.

<comment><USER7> There are ways around this. You can do pair programming with screen sharing and VOIP, for example. As a company/manager/lead you might have to enforce good practice, but that's also true in the office.

(The less your team needs to worry about this stuff, the more likely they are to be successful no matter where you put them.)

<comment><USER8> I did pair programming with screen sharing and VOIP at my last job: we had one guy who was remote (he moved to the east coast because his wife got a snazzy job in animation, and we didn't feel like letting him go). We tried all the tricks. It works, but it's not like the real thing, and it's a lot more obnoxious and stressful for both parties, even when there aren't technical difficulties. I'd say: don't do it regularly unless you have to.

<comment><USER9> Better yet, don't do pair programming it all. People still do that?

<comment><USER8> Pair programming is the only reason that team's still going, after what management's done to it, with the employee turnover it's gone through amidst idiotic hiring constraints. But even before that, it was doing pretty well.

How about you run your team the way that works for you, and if someone else does pair programming and it works for them, maybe it's okay? :)

</comment></comment></comment></comment></comment><comment><USER10> I work in a huge multi-national corporation. Some of the people I interact with are co-located with me, however, most are not. I've even worked with people who are 100% remote. What does it matter to them where I'm sitting? Now, I agree there is something to be said about team building & sheer convenience, depending on the nature of your work, but as long as you are getting the job done, who cares if you are sitting behind your desk 40 hrs/wk?

This should also be a no-brainer for employers. Flex schedules/working from home is an excellent perk, and is low hanging fruit in terms of a company "going green", since there are less people driving to work and offices supporting fewer people produce a smaller carbon footprint.

<comment><USER8> The occasional work-from-home won't hurt most offices, and is really great for the occasional appointment and the like. But there's a lot to be said for having everybody in the same room as the norm.

I've worked with 100% remote people, and have seen the difference.

</comment></comment><comment><USER11> I'm less interested in what college students think about office work than I would be to see what changes they may have (or not) after 3 years of experience.

I'm not disputing the results... I've just noticed that a few years of experience tends to temper attitude a bit, once people learn the reasons behind various policies.

<comment><USER12> The market for top talent remains competitive - particularly for top engineering and consulting roles. Companies that pay attention to shifts in workforce values and evolve accordingly will always have a competitive advantage.

</comment></comment><comment><USER13> What is the mobile direct link? iPad safari is unsupported:

"Dynamic Views in Blogger require the use of a modern browser, and are not currently supported on mobile devices."

</comment><comment><USER14> Can people list what they use for screen sharing when doing remote work? This is my first job where I am having to work with people remotely and I am noticing that iteration times are much higher because its inefficient to describe concepts remotely. Online whiteboards would be appreciated too.

<comment><USER15> What kind of things are you doing that you need to share a screen? If it's mostly document based can using Google Docs be used? Skype also has some screen sharing abilities I think.

</comment></comment><comment><USER16> What a bunch of spoiled brats. Next they'll want us to pay their student loans for them. Oh wait...</comment>


Drones Are Now Appearing on Afghan Rugs – The Atlantic - <AUTHOR> http://www.theatlantic.com/technology/archive/2015/01/drones-are-appearing-on-afghan-rugs/385025/?utm_source=nextdraft&utm_medium=email&single_page=true <comment><USER2> Whoa. That's amazing. Future collector items?</comment>


G.M. Strike: 50k Union Workers Walk Out Over Wages and Idled Plants - <AUTHOR> https://www.nytimes.com/2019/09/15/business/autoworkers-union-general-motors.html <comment><USER2> Unfortunately, what people need to judge this is information about where the negotiations are really at, and what the issues are, and what the differences are - not just PR releases from GM and UAW. Both institutions have proven corrupt over and over during the last fifty years, and it's hard to take either at face value.

There is also a consistent pattern. Companies do great, leading to expansive contracts with workers, then are mismanaged, or not sustainable during down- cycles. Then a down-cycle happens, and the company declares bankruptcy (which more often then not involves a government, a hard core negotiation or a bank bailing them out), and moving to a starvation contract, which they keep in place to far to long, then they get a expansive contract, and the whole thing continues.

Alternatively, Unions don't agree to the starvation contract, which then destroys the company - see Eastern Airlines, Pan Am, and all the carriers that didn't survive deregulation in the 1980s.

<comment><USER3> Profit sharing and equity grants align employees and shareholders in cyclical industries. I never understood why base pay + shareholder-aligned compensation never shows in these negotiations.

Yes, the lavish packages and guarantees are better in the short run, but they _will_ need to be re-negotiated in the next downturn.

<comment><USER4> I agree they align incentives, but there's a large degree of cynicism/skepticism and lack of understanding of how profit sharing is calculated among the workforce. I've worked places where the message that makes it to the represented employees is a far cry from what was presented in the union negotiations. E.g. The end employee thinks they're losing their pension when in reality, they're not, new employees wouldn't be getting a pension.

I talked with a guy who worked 42 years for the same company and was on the bargaining committee when a work stoppage occurred. He said they always thought the company kept two sets of books - the ones they showed the union and the actual books. Nevermind that he worked for a F500 company which was publicly traded _at least_ half the time he worked there, and he worked for the largest facility in the company, driving much of the revenue for the company.

You also hear things about "the company going after tax write-off so they don't have to pay workers as much" when that write-off they're mad about is a standard cost of doing business deduction in the same way payroll is...the company is making a donation to a community organization or buying supplies, but they'd reduce their tax bill by just as much if they paid the money out to employees in the form of profit sharing, bonuses, or higher wages.

<comment><USER5> He is alleging that his own company is run like Enron? It isn't impossible.

Non-profits are a way to buy political influence while getting a tax write- off.

</comment></comment></comment></comment><comment><USER6> In 2008 GM nearly went under. Part of what saved them was the union working quite a bit of reduced compensation mostly for less senior employees. Now that GM is very healthy and profitable the union workers want thier share. Sees reasonable to me.

<comment><USER7> The workers never take a share of the losses.

In 2005 when the company lost $10 billion or in 2007 when they lost $38 billion the union workers didn't get bills in the mail instead of checks. On a personal level, the workers are still making profit regardless of whether or not the company is as well.

In 2008 GM was a $100 billion in debt. The union workers didn't pay that, they didn't take responsibility for that, the taxpayers did.

<comment><USER8> By this logic, management doesn't share in the losses, either. But they are for damned sure collecting bonuses when times are good. Sounds to me like the union wants a piece of that same "times are good" action.

<comment><USER9> I assume management gets both annual bonus and equity as a part of their compensation, so I would argue that yes, management is sharing in the loss, in particular with the equity.

<comment><USER8> IOW, management made less profit. They did not share in the loss. From parent:

 _when they lost $38 billion the union workers didn 't get bills in the mail instead of checks._

If management got bills in the mail, they shared in the loss. AFAIK, they did not.

<comment><USER7> Yeah. Management work for the owners just like everybody else. They're workers who happen to not be represented by the union.

Management only takes losses so far as they have equity stakes in the company, which is to say the extent to which they _are_ owners. When GM lost $38 billion in a year the people who _own_ the company took that hit.

That's why employees usually don't value ownership in a company, because it cuts both ways. A salary only deposits into your account.

</comment></comment></comment></comment></comment></comment><comment><USER10> This is not a great time for the UAW to be staging any kind of strike. Why? Because a bunch of UAW top officials from the president on down are facing federal charges for embezzling from their workers.

[https://www.reuters.com/article/us-autos-corruption-labor- fa...](https://www.reuters.com/article/us-autos-corruption-labor- factbox/factbox-highlights-from-criminal-complaint-in-widening-uaw-corruption- probe-idUSKCN1VX2XD)

The UAW shouldn't be striking when under under indictment as they are weak. It's also at a time when auto sales are weakening.

<comment><USER11> This is a great time to strike if you want to distract people from the fact that your top officials and president are under investigation :-)

</comment></comment><comment><USER12> Most of their demands seem reasonable but I don't understand their request that plants be reopened.

If there aren't customers to buy the products why would the UAW demand that GM keep making cars at those plants?

<comment><USER13> I think their solution would be to reduce the number of cars made in foreign plants and move that work to the US.

</comment></comment><comment><USER14> > The U.A.W. is pushing G.M. to improve wages, reopen idled plants, add jobs > at others and close or narrow the difference between pay rates for new hires > and veteran workers.

Can someone help me understand this? I mean, I guess I have to think about this as "factory workers are doing algorithmic tasks" so there's less benefit to being a veteran worker than there would be as a "knowledge worker?"

I don't want that to sound demeaning - it just seems odd to me that you'd be in a union to improve things for workers, but you wouldn't want the most senior people to be making solid money in comparison to new employees. Wouldn't you then lose some of the motivation for those experienced workers to stick around?

<comment><USER15> My union shop has two pay schedules. It's a grid of classification x seniority. If you're level 1, you make $8/hr. If you're level 6, you make $24/hr. There are yearly pay increases until you hit the end of the grid, then it's just COL increases.

There's a cutoff date where everyone before is on one schedule, and everyone after is on a different, lower-paying one. It's a concession the union made when the employer was less profitable that it had been. It's always been a dealbreaker that the two-tier system goes away, even though they could afford it.

Of course, management is doing their damnedest to make sure they don't hire anyone who could possibly join the union.

<comment><USER16> How do you prevent someone from joining a union?

<comment><USER15> non-full-time employees. Or being in a state with a Right To Work law.

Which is actually worse, because non-union employees are required to be ~represented by the union without paying for that representation~ treated as though they are represented by the union when in fact they are not. So the employee reaps the reward of the union without contributing.

dammit I want to strikeout something and I can't find the correct markup for HN. I know I've done it before.

</comment></comment></comment></comment><comment><USER17> I was kind of looking forward to the new C8 Corvette because it's only one of two interesting cars GM has produced recently (the other being the Bolt). But of course those people are on strike too.

[https://www.bgdailynews.com/news/local-uaw-strike-puts- corve...](https://www.bgdailynews.com/news/local-uaw-strike-puts-corvette- production-in-doubt/article_f05e2f10-0625-56f0-9345-1f3850025483.html)

</comment><comment><USER18> I've heard, but have not confirmed, that GM now makes and sells more cars in China than the USA.

"The Truth About GM's Huge Layoffs and Why You Should Be Mad About It"

Scott Kilmer 2018/12/06

[https://www.youtube.com/watch?v=FEyppHyeSWQ](https://www.youtube.com/watch?v=FEyppHyeSWQ)

Even if this is only partially true, I don't think labor (striking UAW workers) are going to win this round.

<comment><USER11> GMs profit comes almost completely from large SUVs and Pickup trucks, which gives the union a lot of power.

Essentially, they are selling pickup trucks and Escalades to Americans with fantastic margins to prop-up their car business (which is unprofitable in the US and only occasionally profitable elsewhere) and to fuel global expansion.

Basically if the UAW stops making pickup trucks and Escalades, GMs cashflow will turn ugly fast. Doesn't matter where the growth is.

</comment></comment><comment><USER19> Success for labor will truly come when they can do what management did: globalize.

If labor is cheaper elsewhere, can they get them to strike together? Are they trying to connect with them?

<comment><USER20> I think you're subtracting quite a bit of historical context from your equation. The United States military and intelligence services through their weight behind making this globalization happen, policing trade routes and deposing economically unfriendly regimes. I don't see them doing the same for labor any time in the near future...</comment></comment>


All the jobs I failed to get - <AUTHOR> https://shkspr.mobi/blog/2020/09/all-the-jobs-i-didnt-get/ <comment><USER4> When I got a job at one of the FAANG companies I told a friend how many rejections I got. The friend said: "it's easier to narrate your failures once you've emerged victorious".

She was right, I realized.

Now I'm looking for job again, have been rejected by 4 companies, no offer in hand yet and I'm open about it.

<comment><USER5> Thank you for this. I recently graduated in May with a bachelors in CS and looking at LinkedIn has been very discouraging. I know it's unhealthy to compare yourself to others but it's hard, especially when you see a lot of other people having success. Before the pandemic I was banking on going to EYEO and SIGGRAPH to network with people in the creative technology space to break into it (my goal is to be a creative technologist like the Google Creative Lab), now I'm just trying to finish a personal project to showcase my skills (can't wait to share it with Hacker News), find a job, and apply for grad school in a program like NYU ITP, or a Human Computer Interaction program.

<comment><USER6> On a larger note: I find looking into LinkedIn quite depressing. Everyone is happy and excited and successful. There is no real value in most posts. Rather, they're usually a variation of this:

 _"#supergrateful and #blessed for meeting super inspiring %SomeoneImportant today #growth #entrepreneurship %hipsterstartup #nopause"_

I try to stay away from it as much as I can.

<comment><USER7> Those people are showing their "highlights reel," of course. I see people who've been laid off saying how #blessed they are to start their own business, people getting promoted or pumping the release of their latest project but are very stressed and unhappy, etc.

I also stay away from LinkedIn, though. #worthless #selfpromotion

</comment></comment></comment></comment><comment><USER8> GoDaddy rejected me a year after I applied and only realized it when a recruiter was trying to input me into their system. I took great pride in informing her that a) I made more than their proposed offer and b) I'd never work for a company who couldn't operate with basic human decency in their recruiting process.

Because of that experience, I make it a point that every single candidate deserves a yes or no response and the company I work for has kept that up.

<comment><USER9> > I took great pride in informing her that a) I made more than their proposed > offer and b) I'd never work for a company who couldn't operate with basic > human decency in their recruiting process.

I used to work in tech recruiting. I guarantee you 100%, no one cares.

As a candidate your only option is to move on or write a bad glassdoor if you are so inclined and move on.

<comment><USER10> Attitudes like yours are why tech recruiters are notoriously inconsiderate and difficult to work with. It's not a good look and not something to be proud of.

<comment><USER9> > Attitudes like yours

Why the personal attacks?

I am merely telling you what goes on. Its not my personal policy or my personal preference. I hated being a recruiter and pivoted out of it.

Do you think FB engineers personally set the policy to ignore rumours against muslims in India from spreading on their platform.

<comment><USER11> It wasn't an attack. They're just stating a fact from their own experience.

 _I hated being a recruiter and pivoted out of it._

That's definitely helpful to know. Thanks for clarifying.

</comment></comment></comment></comment></comment><comment><USER12> I'm currently working at a very well known international company where I got hired after getting rejected from a significant number (+50) of big international companies and a good number of local ones (by local I mean from my small EU country). Strangely or perhaps completely understandable, getting rejected from the local companies 'hurt' more as I was aware that the pool of candidates was significantly smaller, there was no culture issue and it felt personal when rejection email was extremely late or non existent. I pull my hat down for the people who can be completely transparent in their 'failures'. I do wonder though, if the motivation behind the 'failures-cv' is to send a sort of a message to the companies and grant boards mentioned in it, when it's done after the person writing it has had significant success. By message I mean sort of 'look guys, I'm doing relatively ok and you didn't even call me for an interview'. Also, the article sparked an idea. Perhaps a good 'heuristic' for judging companies hiring processes and especially governmental ones would be to look at not only CVs of people getting hired but also those that get rejected. Part of that thinking comes from a conversation with one of my managers who said that sometimes he has a look at CV-s classified as 'C' (he get's only A & B from HR) and he wonders why some of them were not in the A and B group.

<comment><USER13> The sorting of resumes into A B and C piles is incredibly noisy. I could look at the same resume on two different days and reach a different conclusion, especially for an A<->B or B<->C transition, so it's easy for me to see how someone else could reach a different bucketing.

</comment></comment><comment><USER14> My list of recent jobs I failed to get is about 200 unglamorous mid-level roles in small unknown companies that I applied through the last 2 months. 90% of them I was rejected on the resume filter. About 5 rejections after an intro interview. About more 5 or more rejections after a technical interview/coding challenge. Only 2 places on a final interview with chances of offers as of now (luckily in companies that I believe I would enjoy working).

If I were to publish such a blog post it would be more depressing and probably make me look like a bad developer (at least a bad candidate), not like someone who is "open about failure".

<comment><USER15> When I started out I worked at a call center(A tech support center). When I interviewed there, I went in through a hiring consultant. I met a girl there who had failed in interviews in like some 40 companies and then finally got hired in our batch. From what I know she went on to do some amazing things. This always brings me some perspective on the merits or acceptance or rejection in any process.

Getting rejected any number times means nothing at all. People interviewing candidates are no better than the candidate, and in many cases not even as good as the candidate. Even if they were better it wouldn't matter, 1 hour is barely any time to judge any one and any decision you are likely to make even a 'yes' decision will never be 100% right. Even a hire decision doesn't mean you are awesome.

Plus a person measuring their worth based on job interviews is totally wrong. We like to think that people wish to hire people at least as good as them, if not better. In reality no one likes people better than them, and they'd rather not have some one better than them at work. They will be hiring competition responsible for them not getting raises, bonuses, promotions or RSU's. You are more likely to get rejected being good than bad.

If I've learned anything at all its the Clinton principle _How many chances does one get? As much as one is willing to take_

Pretty much any rejection any where means nothing. I'm not saying one must not take them seriously enough to improve oneself. But there is not need to get depressed or under evaluating yourself.

Just be chipping away at a good system of improving yourself in never ending cycles.

<comment><USER16> >Getting rejected any number times means nothing at all. People interviewing candidates are no better than the candidate, and in many cases not even as good as the candidate. Even if they were better it wouldn't matter, 1 hour is barely any time to judge any one and any decision you are likely to make even a 'yes' decision will never be 100% right. Even a hire decision doesn't mean you are awesome.

>Plus a person measuring their worth based on job interviews is totally wrong. We like to think that people wish to hire people at least as good as them, if not better. In reality no one likes people better than them, and they'd rather not have some one better than them at work. They will be hiring competition responsible for them not getting raises, bonuses, promotions or RSU's. You are more likely to get rejected being good than bad.

I am sure this happens, but it hasn't matched my general experience. I've been on both sides of the interviewing process, and have met people with better skills on the other side.

I also haven't worked any place so dysfunctional that skilled candidates' applications were torpedoed because they were potential competition.

</comment></comment></comment><comment><USER17> It's amusing looking back at the failed ones, at the time it feels terrible, but as time passes it becomes an footnote of your own personal history.

My favourite one was sitting in a conference room in a hotel basement being interviewed by a FAANG for 5 hours. Completely bombed the interview but it makes me laugh looking back at it

</comment><comment><USER18> OP is clearly trying to get a job in government. I hate to say it, and I mean this with the least amount of offence possible, but typically UK government jobs require you to look the part more than having sufficient technical knowledge. OP is applying for deputy head of governmental departments without the required background experience and to my untrained eye, the gravitas required. Perhaps a trip to the barber is warranted. Otherwise, great post! :)

</comment><comment><USER19> It takes courage to share your failures publicly so kudos. Though the part about "CTO of a large government department" seems like a role that depends more on length of tenure and knowing the right people. Something that a headhunter would reach out for serious candidates.

</comment><comment><USER20> Its fascinating because you see people get new jobs all the time but you never really know how many they applied for. I'm still not sure if my colleagues just apply for a few jobs they want and get them or apply for 100 and get just one or two.

<comment><USER21> New grad who spent 6 months applying for jobs everyday checking in. I got rejected/never heard from 120+ companies. Of those probably 25 I spent time actually writing a cover letter and tailoring my resume to. Finally got a job at an amazing company for good compensation and I love my job!

</comment></comment><comment><USER22> The opportunity even to fail at achieving the positions and distinctions listed is a privilege itself. Granted, it isn't the duty of one particular demographic or class to police how another responds to these sort of things because we're all human and have the right to express how we feel about rejection and not meeting the expectations set by ourselves or others.

I can understand and appreciate how this can be a boon to the esteem of their peers. But let's take it a step further.

Is there a way that the authors of these "CV of failures" can bridge the gap between themselves and those who may not even have a "curriculum" to ascribe to their life?

</comment><comment><USER23> It's a lot easier to accept rejection when you give up on the idea that you're a rock star. I think I do good work and so do my coworkers. Knowing that is enough for me. It's OK if I get rejected by the big boys.

</comment><comment><USER24> Lots of comments about how people are only transparent about their failures after they're successful.

There are plenty of reasons to conceal the failures in real time, but the two that jump to mind for me are:

1) not wanting your current employer to know you're looking, and

2) not wanting to advertise that you've been rejected to other future job prospects. (Could prime people into wondering "What's wrong with this candidate?" if you don't make it somewhere else.)

</comment><comment><USER25> humblebrag, they're all high status positions

<comment><USER26> Deputy Director jobs in the UK Civil Service aren't actually that senior. They tend to pay around £75k, or $100k US, which is a pretty decent wage for the general population but not quite at levels.fyi rates.

<comment><USER27> Sorry since when is over double the median wage 'decent'. Some people on this forum have their head in their arses when it comes to money.

<comment><USER28> If you're in a certain industry, you're typically looking at the median in that industry and not the national median. USD $100k is ~4 year experience software engineer salary.

<comment><USER29> Is it? Most of the new-grads I know, many with no prior full-time experience, make around $120k, and of the 9 I regularly keep up with only 1 works at a FAANG (and makes a decent amount more than $120k). The others range from startups to BigCo fintech to backhouse software role in legacy Fortune 500s. Granted, most of these jobs are on the coasts, though (but not SF)

<comment><USER30> > Most of the new-grads I know

Only about 1/4 of US adults have an accredited 4-year degree. Just being a new grad is already a huge credential. Still, that credential doesn't generally generate $120k, for any major.

Where did these new grads get their degrees? My guess is that your personal social circle has a certain pedigree that isn't the norm.

<comment><USER29> A small liberal arts college (<1600 people) in California. While it's very well regarded in academic circles, within the general public you'd be hard pressed to find anyone who recognizes it unless they're affiliated in some way.

I only bring this up to push back against the common idea on this forum that you need to be Ivy/Stanford/MIT/Caltech to get into a top FAANG or consulting job or law/medical program -- first careers like these were the rule at my school, not the exception. And many were hired with one of those "useless" liberal arts degrees rather than a degree in the specific field they went in to.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> My final interview with AWS for a Sr PdM role went so poorly that they told me I had to wait 12 months to apply again. I feel like that's some sort of accomplishment on its own.

<comment><USER32> They probably have a standard period to wait. Is this significantly longer than what other people have encountered?

<comment><USER33> All the FAANGs do, though it sometimes varies. A year is typical though (and I think at different times in their hiring cycle it varies, too).

For one FAANG, I had 3/5s my interview panel all clearly very positive about me, and 2/5s who clearly did not care from the very first minute of the interview, and the internal recruiter was like "Let's talk again in a year". Like, the implication clearly being he expected a pass, it was just luck of the draw on the panel. But even with that, year 'cooling off' period.

</comment></comment></comment><comment><USER34> Reminded me of a friend who had applied to over 1,000 job openings in LinkedIn in 2019 and got zero response from them.

Then he decided to take the risk and run his own business, which is starting to gain some traction right now after the covid crisis.

<comment><USER32> Zero responses or zero offers? I find it hard to imagine not one of the 1000 positions he applied to wouldn't even bother to respond provided he is qualified (or even in the ballpark) for the the job.

</comment></comment><comment><USER35> I once applied for a position building digital kiosks for American Airlines - I did not get it and in retrospect that is probably better because the company is always on the edge on bankruptcy, doing furloughs and layoffs, etc. I would have had a hard time during numerous financial downturns and world events like mortgage bubble, 9/11, and COVID. I would never have worked for Tumblr which was double plus awesome. But just the same, every time I check in at a kiosk in the airport I think to myself - I could have done this much better - <USER2> lament the missed opportunity.

<comment><USER36> It's only a missed opportunity if you think you'd get approval to improve the screens! I've indirectly worked with American on their screens, and I'm not so sure improving UX is their top priority.

</comment></comment><comment><USER37> I have a folder with over 30 screenshots of job listings for all the positions I applied for last year.

Took me almost two months to find employment and in hindsight my greatest mistake was to bother with all that in November - companies started replying only in December when apparently they were finished with planning for the next quarter.

I'm seeing the same phenomenon now that again I'm looking to get hired - <USER3> currently have one offer on the table and at least three other interviews even though a month ago the best what I could hope for was a canned response rejecting my application.

</comment><comment><USER38> I remember getting rejected by Google because I completely blanked on a binary search question. All my other rounds were great, but you can't miss the search question at the search company.

<comment><USER39> I mean, you can't miss any question at the big companies. There are endless candidates who have done 1000+ problems on leetcode in the waiting.

<comment><USER40> Its less an interview more an exam where the only acceptable mark is about 95% to 100%

</comment></comment></comment><comment><USER41> > I think that people need to be more open about failure. None of us are > perfect – despite what our social media presence says – and all of us suffer > rejection. But, by being open and honest about it, we make it easier for > others to realise that they're not alone.

Yes BUT...

I haven't been in _too many_ situations where I've been actively looking for employment/engagements, but some of the times I've been in those situations, everything was bad. It's difficult to go back and 'share' those with people - publicly - as it brings back a lot of bad memories of those time periods. Low funds or debt, downsizing, loss of friends/community, home/life issues, family issues, whatever. Scenarios where someone is looking for a job are often stressful, and that often can spread out for months, and affect the family and friends around you.

I'm happy to share extreme details of my situations with people in person, offer up support and give advice and insight about someone's situation by drawing on my own experiences, but... typically only in person. Publicly... generally not.

There's not just 'shame' issues for yourself; when you have a family, posting information about your failures can have an impact on your family as well, which they may not want.

</comment><comment><USER42> I can't even remember the 80-85 jobs I've applied for in the last 7 months.

<comment><USER43> When I got out of college, I applied to about 250 jobs and only got 3 calls. Luckily one of those did pan out.

I keep hearing how there's a war for technical talent. I guess I don't have any.

<comment><USER44> Out of hundreds of applicants I screen, very few even have the skill to implement a standard algorithm with recursion in a language of their choice that I explain meticulously.

<comment><USER45> But is that a skill that is required for lots of positions?

<comment><USER46> Recursion is a fundemntal part of programming, beyond the self-taught junior yes I would absolutely expect every programmer to be able to do it.

You learn it in highschool level programming classes & first semester intro to CS college courses.

Even if they won't specifically need to use recursion in their next job it marks them as someone not serious or about programming.

<comment><USER47> Honestly I think recursion is overrated. Does anyone here really write recursive functions in production? I mean it takes up stack space (which on some systems is a systemparameter), creates functioncall overhead and has rarely advantages. Trees have more natural recursive structures, but then you basically always have cache misses making your program orders of magnitude slower than if you can fit the data in a linear structure.

I mean, I would be worried if a candidate is not shy to use recursion that this will blow up software perfomance. (But then probably after hire the senior will tell: dont use recursion here)

<comment><USER48> I think I've used it twice in production code over the last 20 years. The first was to traverse a directory tree. I wouldn't write it that way now since there is now a standard library to do what I was doing then. The second was to traverse an object's children logging certain pieces of data from the sub- objects. I didn't design that one, I just wrote it so I don't know if there was a library that would have done it for me. Fun to write though.

Generally, developer interviews are just stand-ins for IQ tests since it is illegal to give a candidate an IQ test. Seeing if someone can easily write a recursive function is a pretty good IQ test.

<comment><USER43> I guess it also weeds out the smart-asses like me who would question why I need to reinvent the wheel.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER49> I like this quoted response:

 _You have reached the required standard, but we are unable to offer you a job immediately. We have placed you on a reserve list from which future appointments may be made._

When I was leaving academia it took a number of rejections before I realized that I wasn't being rejected because I wasn't qualified, but because the company only had one spot and I wasn't their top choice.

</comment><comment> 100-xyz I had a first interview for Product Manager for Google about a week ago and got the reject couple of days back. The recruiter said it was close. I played back the interview in my head and realized I could have been more methodical in my answers. Finally, just decided to let go.

In the end its just a footnote.

<comment><USER50> > The recruiter said it was close.

Is this something a recruiter might ever not say?

<comment><USER32> For an in-house recruiter, yes. They generally say that because they want you to interview again in the future. I don't think they would waste their time if it wasn't close.

Head hunters on the other hand will generally say anything to get you to keep interviewing.

</comment></comment></comment><comment><USER51> If you find this interesting you may also appreciate:

Susan Tan Rants and Ruminations From A Job Applicant After 100 CS Job Interviews in Silicon Valley [https://www.youtube.com/watch?v=uzz5AaCWMps](https://www.youtube.com/watch?v=uzz5AaCWMps)

My recent job search adventures [https://medium.com/@arctansusan/my- adventures-in-job-searchi...](https://medium.com/@arctansusan/my-adventures- in-job-searching-for-senior-engineer-roles-7050e1c2b1a5)

I really liked the airtable at the end of that post: [https://airtable.com/shrL4aSSKldQHTtM3](https://airtable.com/shrL4aSSKldQHTtM3)

</comment><comment><USER52> If you been at more than a few jobs, almost certainly you have had failures/ disasterous interviews. I certainly have.

Once I've gotten a job, a question coworker asked: how did some of these other people around me get through the interview process.

</comment><comment><USER53> The last time I got rejected was after the final interview. The recruiter scheduled a call to talk with me without letting me know they had an offer. I could only have imagined they'd be making an offer. He thanked me for the time and told me why they decided to reject me, and that they'd likely reconsider me in six months. I'd rather receive an email telling upfront I was rejected instead (still would be happy to schedule a call).

<comment><USER32> I've gotten three of these calls in the last 6 months. I learned after the first one not to get too excited and grown to appreciate actually getting feedback.

I can't stand the interviews where you invest a significant amount of time and get zero feedback. I realize they often don't want to share everything but give me something so I have some direction for improvement.

</comment></comment><comment><USER54> All of my jobs: My first job was at Jewel as a bagger. My mom got me the job. The place was next to microcenter so I spent my paycheck there after work.

I quit this job because of stress.

Next job was at Michael's a crafts store. It was seasonal and I didn't get hired.

After that I did contract jobs on upwork doing web design and development.

I got fired from Subway because I was too slow at making sandwiches.

In college I got burned out and eventually found my career as a programmer for an insurance company.

</comment><comment><USER55> I've never been rejected in a job I interviewed for, but I tend to stay a long time once I find one I like. Is that so unusual?

I'm really picky about jobs. I hardly never interview unless I think we're going to be a good match (me and the job) and that there's something I can bring to the table.

</comment><comment><USER56> A serious and urgent question, when did "data" a collective noun warrant a plural verb ex. "the data are ambiguous"

"Data" was not treated this way in the past and now it is everywhere. Where did it come from and why did it change?

<comment><USER57> Data has always been plural! Datum is the singular. But actually treating it as plural is mostly a question of where the person speaking/writing is based. Americans treat it as singular, Brits plural. See also, corporations

<comment><USER58> Note that in the English language, there is a rule in regard to forming compound nouns, which is that only the head of the compound can carry the plural marker.

So for instance, whereas the compound noun phrase "law school entrance exams" is perfectly fine, "law schools entrance exam" is not. It has a plural on "schools", where it is not allowed to be, because that is not the head of the noun phrase.

According to this rule, we should not have words like "data processing", unless we treat "data" as plural. If we treat "data" as the plural of "datum", we must make it "datum processing".

Is that how it is in British English, or do they still make it "data processing"?

In any case, one cannot be a proper pedant about "data" and "datum", while continuing to use terms like "data storage".

</comment></comment></comment><comment><USER59> Seeing posts like these, I feel incredibly grateful to have a personal network that I've never really had to go beyond in search of a job.

Networking in the early years as a young founder paid off big time.

</comment><comment><USER60> Rejection is a fact of life, be it in relationships or in a job hunting.

Just give yourself some time to go through the sad period, and then power through the next one.

Luck is a high factor in getting a job anyway.

</comment><comment><USER61> "So, what have you failed at this week?"

<comment><USER62> I failed my real analysis II exam, I failed to make progress at the gym, I failed a quiz on agile software development, I guess you could even say I failed to go on a date since I got stood up.

<comment><USER63> You can check out [https://mirtitles.org](https://mirtitles.org) for books from MIR Publishers. These are amazing books.

For analysis, you can check out:

\- "Problems in Mathematical Analysis" \- Demidovich

\- "Differential and Integral Calculus" \- Piskunov

\- "A Course of Higher Mathematics" \- Smirnov

Excellent books.

[Link edited as I posted in a hurry. Thank you, sedeki]

<comment><USER64> Soviet era math problem books? Buy a few reams of paper too!

<comment><USER63> Exactly. I actually did buy reams of paper and quantified my revisions days with how many sheets I had written.

I made booklets folding A4 paper longitudinally in half. Easy to put in my back pocket. Solve problems everywhere. It's more economical, too, a lot of paper is not filled with ink if you leave it in A4, and folding it to make A5 doesn't sole the problem (short lines) an is impractical to carry (can't put in back pocket).

</comment></comment></comment></comment></comment><comment><USER65> I got a good laugh out of the Meta-Failures section.

</comment><comment><USER66> _I think that people need to be more open about failure._

Rejection isn't necessarily failure. I appreciate that the article is about objective self-evaluation and self-improvement, but that requires a good understanding of why you really didn't get the job. And it's possible the feedback you are getting is not the whole story.

Back in 2003 I was a young C++/C/Java developer with a couple of years of experience looking for a new job in a new town. I felt like I was talented and capable and was hungry to prove myself. It was a tougher market in those days so I was applying anywhere that posted a job that seemed like a fit. I got rejected time and time again and most of the time I didn't even get a rejection. I never even heard back at all. I was ignored. It was demoralizing.

I knew if I could just get an interview, I'd have a great shot at a good job. But I couldn't even get an interview. I felt like a failure.

I finally landed a C++ gig at a company I accidentally applied to twice (they gave me an interview because they thought I was resilient). It turned out to be a great experience. I got to tackle hard problems, learned a lot, and was promoted quickly. I was soon managing the team I was originally hired to write code for.

After a few years of that I was headhunted to work for a consulting firm that specialized in what later became DevOps (we were pushing CI/CD back in 2006 and automated virtualization for build and test in 2007). As part of that job, I ended up with a few gigs at companies that had rejected me only a few years before. Here I was telling them how to make software at 4 times the rate they could have hired me for full time just a few years earlier. I'd won!

But really, I learned most of these companies hadn't hired me for reasons that had nothing to do with me. I didn't know who I was competing with. I didn't know what specific traits they valued. I didn't understand the stresses and risk and pressure those hiring managers were under when they compared the PDF I submitted to the PDF someone else submitted.

For example, the company that hired me after I applied twice rejected me first because I was from out of town. They had so many bad experiences with hiring and firing that they didn't want to hire someone that had to move to take the job. _They were actually being considerate of my risk, not just their own._ They thought they were doing me a favor!

And in a few of companies I was now consulting for, I saw poor culture, poor talent, poor processes, and poor hiring practices. I saw HR people filtering out prospects because that person's resume didn't have everything on some magic, unadvertised checklist. I saw politics. I saw bias. I saw incompetence. Some of these places wouldn't have been able to spot talent if their lives depended on it.

Really, I wasn't the one that failed when I was rejected. They had failed by rejecting the wrong people. And I was fortunate they'd rejected me because it would have been an awful place to work. _Rejection is God 's protection_, I've heard it said.

So rejection wasn't failure. It usually had nothing at all to do with what I really could do or couldn't do. If I failed, it was in allowing rejection to affect my self-worth.

After running my own business for almost a decade, I'm back in the software industry. I'm fortunate to have a good job thanks to people I worked with previously, but I'm hungry for bigger challenges and believe I have the skills and capability to meet them. Except now I have a 9-year "hole" in my resume that doesn't say Google/Microsoft/Facebook or AWS/Azure/Cloud or whatever else the cool kids are doing. From a hiring manager's perspective at those great jobs that attract lots of talented candidates, that means I'm a risk. But having been that hiring manager, having owned my own business, and having spent time in the trenches, I understand and sympathize. Rejection isn't personal and it's not always about me.

</comment><comment><USER67> App</comment>


Why Not to Build a Time-Series Database - <AUTHOR> https://www.outlyer.com/blog/why-not-to-build-a-time-series-database/ <comment><USER2> TLDR: "Why Not to Build a Time-Series Database? Because we're building one and you should pay us."

> _Hopefully our story will make you think twice before trying to build your > own TSDB in house using open-source solutions, or if you're really crazy, > building a TSDB from scratch. Building and maintaining a TSDB is a full time > job, and we have dedicated expert engineers who are constantly improving and > maintaing our TSDB, and no doubt will iterate the architecture again over > time as we hit an even higher magnitude of scale down the line._

> _Given our experience in this complex space, I would sincerely recommend you > don't try and do this at home, and if you have the money you should > definitely outsource this to the experts who do this as a full time job, > whether its Outlyer or another managed TSDB solution out there. As so many > things turn out in computing, it's harder than it looks!_

<comment><USER3> Hmmm. I used to be part of a team that handled market data at crazy rates and we took exactly the opposite approach to these guys.

When I see:

"You Can Lose a Few Datapoints Here and There"

I see that these guys are barking the wrong tree.

1\. We used single thread per network card. (Yes, we architected clusters/failovers, etc... but not once was it required because of data rates)

2\. The server could handle a fully saturated Gibit network at <50% CPU (per core)

3\. Data was NEVER thrown away (but we had allowances in our API to let the client reading the data to drop updates and get sub-second aggregates instead -- eg OHLC or summation)

4\. Data was stored in basically flat file systems.

5\. Our calculation engine was run 'downstream' toward the client ends, or on the client end, away from data collection. If needed (ie. the calcs were expensive to run), these could feed back into the server for long term storage.

This was mid 2000. I'm sure this is not rocket science for modern day timeseries guys.

<comment><USER4> Right. For those interested OpenHFT has created a really nice set of open source solutions to do this.

[https://github.com/OpenHFT/Chronicle- Queue#design](https://github.com/OpenHFT/Chronicle-Queue#design)

<comment><USER5> Do you know any article or book outlining the architecture of a full HFT system, I.e. from market data consumption to pricing to trading? Thanks in advance!

</comment></comment></comment></comment><comment><USER6> As I was reading through the post I kept wondering why they weren't using some warehousing technique for older data - either dump it to S3 or better yet, Google BigQuery, which is amazingly fast at that scale. They only did it after doing lots of fire-fighting and per-tenant clusters.

Clickhouse would also be a good option for doing aggregating queries that TSDBs are mostly used for.

One of my wishlist items in the data space is a Managed Clickhouse offering. :-)

</comment><comment> bra-ket We used a combination of Kafka + Hbase+ Phoenix ([http://phoenix.apache.org/](http://phoenix.apache.org/)) for similar purpose. It takes some effort to setup initial Hbase cluster but once you do it manually once and automate with Ansible /systemd it's pretty robust in operation.

All our development was around query engine using plain JDBC/SQL to talk to Hbase via Phoenix. Scaling is as simple as adding a node in the cluster.

<comment><USER7> Does Kafka have timestamps? I didn't see any when I looked, but I was working with an older client version & didn't get far into it.

<comment> bra-ket we didnt rely on it, or on the ordering of messages received from kafka, timestamps and transaction IDs were generated by the client app/kafka publisher and were part of the message put into kafka topic, when we consume that message with one of the parallel kafka consumers and save a row in hbase table that original timestamp + transactionId becomes part of the rowkey string, other parts being attributes that we wanted to index (secondary indices are supported in hbase/phoenix but we didnt use them too much, basically the composite rowkey is the index). Then when querying hbase it works as a parallel scanning machine and can do a time range scan + filtering +aggregation very fast.

On a separate note we didn't use joins even though they are supported in Phoenix, data was completely denormalized into one big table.

</comment></comment></comment><comment><USER8> In case anyone is interested in a video on this, here's the talk presented at the local San Francisco monitoring group, monitorSF ([https://www.meetup.com/MonitorSF/](https://www.meetup.com/MonitorSF/))

[https://youtu.be/lA85vs6e3UA](https://youtu.be/lA85vs6e3UA)

</comment><comment><USER9> Time-series data handling/storage seems a mostly solved problem in the mining, oil, and manufacturing industries. Deployed in the field since the 80's,

[https://www.osisoft.com/about-osisoft/#more-about-pi- system](https://www.osisoft.com/about-osisoft/#more-about-pi-system)

Discourse: Industry user now OSIsoft employee

<comment><USER10> A solved problem at what scale? A kid with pencil and paper can solve the problem when it's small enough.

<comment><USER11> I don't have personal knowledge, but my understanding is that timeseries data in the oil industry is insane scale. Think 10s or 100s of wells in a field, sensors at regular distances in every well each taking multiple readings (temperature, flow etc) on a sub-second cadence. And a big oil company will of course have many fields.

It's in the same league as timeseries data in financial markets, which I have more direct experience of. Financial timeseries data probably has more metadata (trade/order flags etc) but in terms of raw data it's similar.

<comment><USER10> What the article is talking about is an order of magnitude larger. Think millions of data points per minute coming out of a medium sized data center. It gets harder when you look at the cardinality of the data (explained better by the article), which corresponds to the sized of the indexes.

</comment></comment></comment></comment><comment><USER12> Nice article.

>its not uncommon for some of our customers to send us millions of metrics every minute

What kind of customers/services generate millions of points a minute?

<comment><USER13> I use to work at a Fortune 50 retailer on the cloud platform (a lot of tooling around CI/CD for the teams that manage the website). We had a large problem with keeping the metrics pipeline current. A major issue is that be default, Spring Boot publishes about 500 different metrics on a 10 second slice. Allowing every application to pump out that many default metrics, most of which are never used, means that it takes only 334 instances to get one million metrics per minute (1,000,000 / 6 / 500 = 333 1/3). I would guess we had a couple thousand instances in production on a normal day. In a couple weeks, they have Black Friday. Any team that hasn't been able to fix performance problems are given the go ahead to just throw money at it and scale horizontally in obscene ways.

Of course, our metrics were all handled in house. From talking to the teams that handled the metrics pipeline, the vendors were great for smaller companies, but there was no off the shelf solution for a companies that large with that volume. But I did very little with that myself, other than look into the fact that Spring Boot published way too many default metrics. Who needs P50, P70, P75, P80, P85, P90 - P99 on all web requests?! Just set a default that is small and worthwhile and let the developers adjust as needed.

<comment><USER14> Folks need to resist the inclination to just gather maximum data for the hell of it.

If you're pumping out a million metrics per minute, almost none of those are ever going to actually be used to generate meaningful insight.

<comment><USER15> I used to work at a startup that made physical robots. The robot generated several GBs of data every time it turned on. You're correct, most of that data wasn't looked at most of the time. But every now and then, someone would say "Hey, I saw a robot do something funny the other day, what the hell happened?" And having all that data usually made it possible to figure out what happened. To me, "maximum data for the hell of it" isn't about generating insight by looking at trends, it's about generating insight during incident analysis.

<comment><USER14> That is a very particular use case, where very high res data is critical. I note that even here, you're interested in data from "the other day", not years ago.

In most cases, time spent maintaining terabytes of rapidly aging time series data would be better spent elsewhere.

<comment><USER16> I think that really depends on the case.

A particularly good high-frequency trader might be interested in Terabytes of minutia when they're trying to sort out what caused yesterday's spike and crash of ticker XYZ.

Systems and sales analysts that are looking at web store front ends (and back ends, if there are issues) would be interested in large volumes of data, specifically corner cases (users who don't follow a statistically significant path), when trying to sort out a UI/UX redesign.

Traffic and transit analysts might want terabytes of data (especially with date and weather indicators) when considering what kind of freeway interchange to add to a growing area.

I suppose I could go on...

</comment></comment></comment></comment></comment></comment><comment><USER17> "time-series database" is some of the most overhyped nonsense since noSQL.

Time-series is just data with time as a primary component. It comes in all shapes and volume, but if you have a lot of data and are running heavy OLAP queries than we already have an entire class of capable databases.

Use any modern distributed relational column-oriented database, set primary key to metric id + timestamp, and you'll be able to scale easily with full SQL and joins. You can keep your other business data there too, along with JSON, geospatial, window functions, and all the other rich analytical queries available with relational databases.

We have trillion row tables that work great. No special "TSDB" needed.

<comment><USER18> While I understand your point, you are quite mistaken if you think that time is just another key. Dealing with time properly requires a concept of point distance, similar to GIS systems requiring 2d distance understanding. You cannot do joins on time with SQL databases unless you want to throw away important data.

As an example, in the industry I work in, you may have no readings for days or weeks, and then hundreds of readings from the same sensor. Why? Many systems in industrial environments send new readings only "on-change", and assume the underlying data storage architecture will forward fill to in-between times. This is why the practically ancient time series architecture of data historians still dominates in these use cases.

In fact, for many time series functions you actually have to throw away the notion of relational joins to be able to efficiently perform time-preserving joins. Window functions only work in basic use cases with relatively small amounts of data where you're aggregating.

<comment><USER17> I'm not sure where the complexity is that you claim, nor what it has to do with data historians?

So what if there are missing rows? This doesn't affect the database and any aggregations will work fine. Databases don't "fill-in" data, but you can definitely write whatever SQL you need to create averages and buckets to smooth out results.

From reading your website, it seems you're talking about the "last value recorded" as of a certain time, which doesn't seem to be a common query but is totally possible. KDB+ has "asof" joins and others can handle it with window functions using last_value().

We run queries on a table containing 2.7+ trillion rows of data that has no set pattern and infinite cardinality, and results return within seconds. Window functions and joins work without issue. Have you actually tried using a columnstore?

<comment><USER18> Relational databases represent a column/row-oriented architecture. Data historians are a specialized, non-relational, _time_ -oriented architecture. Using time as a key in a relational index implies that only ordering is important, but that is not the case. Distance between points in time is extremely important because time operates on a continuous 1d line and data points are represented at varying distances between each other on that line. Data historians are architected to both preserve this temporal relationship and take advantage of this by eliminating duplicate data, employing temporal compression techniques to be able to store millions of readings per second for years worth or data.

> From reading your website

My website doesn't have much to do with this because Sentenai isn't a time series database system. I did, however, spend most of my time in research working on temporal data systems, and have been fortunate to collaborate with or learn from researchers who have spent decades solving the unique problems that temporal data presents. What you might consider uncommon for your use cases is extremely common in manufacturing, defense and other areas.

There's a decades-old industry around database systems that handle time natively. And while many support SQL as a lingua franca, and some are column stores, they're not relational by any means as they either extend SQL to support time, or limit non-temporal joins to ensure performance. StreamBase, Kdb, Aurora and many other specialized architectures exist because one size does not fit all. Michael Stonebraker, whose work has included StreamBase, Vertica, Tamr, Postgres, Aurora, and many others, famously published this paper about the very problem: [https://cs.brown.edu/~ugur/fits_all.pdf](https://cs.brown.edu/~ugur/fits_all.pdf) .

Further reading that might be illuminating:

      1. http://cs.brown.edu/research/aurora/vldb03_journal.pdf
      2. http://www.cs.rochester.edu/u/james/Papers/AllenFerguson-events-actions.pdf
      3. https://books.google.com/books?id=BK6oCAAAQBAJ&pg=PA9&source=gbs_toc_r&cad=4#v=onepage&q&f=false (excerpt)

<comment><USER19> I appreciate your links to further reading, and I'm trying to read the Aurora paper right now but after reading the abstract and the intro (I'm in progress right now), I can't find a case that is uniquely fit/perfect for data historians... I know this is already asking a lot, but would you mind giving me _one_ go-to- use case that really made you think "this is what purpose- built data historian-style databases are good for?".

Every issue mentioned in the abstract/intro (which are meant to motivate the paper) seems like it can be solved as an add-on to existing application databases (albeit with their most recent developments/capabilities in mind). The very description of HADP vs DAHP systems seems silly, because it's just a question of write load, and that's fundamentally only solved with batching and efficient IO, or if you give up durability, it doesn't seem inherent to the data model. There's also assertions like:

> Moreover, performance is typically poor because middleware must poll for > data values that triggers and alerters depend on

But like, postgres though, you're free to define a better/more efficient LISTEN/SUBSCRIBE based trigger mechanism, for example, you can highly optimized code right in the DB... Thinking of some of the cases called out in the paper here's what I think in my head:

\- Change tracking vs only-current-value -> just record changes/events, as far as tables getting super big, partitioning helps this (timescaledb does this)

\- Backfilling @ request time -> an postgres extension could do this

\- Alerting -> postgres does have customizable functions/procedures as well as LISTEN/SUBSCRIBE. The paper is right (?) about TRIGGERs not scaling then this might be the most reasonable point.

\- Approximate query answering is possible with postgres with stuff like HyperLogLog, but the paper is certainly right in that it is not implemented by default.

Maybe I'm mistaking the extensibility of postgres for the redundancy of the paradigm, akin to thinking something like "lisp is multi-paradigm so why would I use Haskell for it's enhanced inference/safety".

I'm still reading the paper so maybe by the end of it it will dawn on me.

<comment><USER18> So Aurora isn't a historian, but is a complex event processing system. It's an entirely different beast that solves very specific problems around high-speed queries that could theoretically require scanning through all data stored historically for queries.

I'm not a huge fan of historians (I've spent too much of my career working with them), but I can definitely tell you where they make sense. The scenario is this:

Imagine you have a large facility with thousands of machines, each with a programmable logic chip for controls and monitoring. These machines create lots of data and so often employ data reduction semantics by reducing data to on-change rather than sampling sensors at thousands of hertz. A single machine may have dozens or hundreds of variables to track. These tags might be hierarchical: Machine 1, subsystem 5, variable b. If you say there's 100,000 total tags to track in the facility, and they're on average sampled at 10hz, you need a system capable of writing a million durable timestamped values per second. Now that's child's play for, say, google, but if you're a manufacturer, you can't afford to spend massive amounts of money on cloud systems, and usually want to do this all on a single server on the factory floor because you need realtime monitoring that can display the current value in time for every single tag. ( [https://www.ws- corp.com/LiveEditor/images/SLIDES/10/3.jpg](https://www.ws- corp.com/LiveEditor/images/SLIDES/10/3.jpg) ). Ideally, in a single node scenario, you want compression. It's not uncommon to store 100 billion timestamped values per day and keep them for a year or more for audit purposes is something goes wrong. Today, for the sake of predictive maintenance, data retention policies of up to 10 years are becoming more common.

So what would you sacrifice to be able to do efficient realtime monitoring and ingestion of millions of data points per second? You can't use queueing semantics to protect an RDBMS because logging can't take more than a 10th of a second per point. If you think about the use case, what you'd sacrifice is transactional queries and row-level joins, because you just don't need them. At the same time, this data is really sparse when you look at it from a table's perspective, so you'll want something like a column store to underly the data storage.

So what we do is throw out transactional guarantees, choose a storage system that is good at compression (roll-ups in some historians will store a formula approximating the data instead of raw data itself over a window), and prioritize speed of point retrieval for most recent "hot data" by caching it in-memory.

You can of course extend Postgres to achieve many of these things, but having done it myself, in practice it's sub-optimal in the exact same way that using bubble sort for all your programmatic sorting needs is sub-optimal.

One thing you might want to keep in mind is that many of the people involved in Aurora are the authors of Postgres. They're not arguing you can't do things in Postgres, they're arguing that in practice the RDBMS's guarantees are theoretically incompatible with high performance in the area of Complex Event Processing, because alignment between different simple events (recorded as rows in a database) can drift so far that memory requirements become prohibitive if you don't use a stream-processing architecture.

Also keep in mind that Aurora is from 2002 and many of the ideas have been implemented elsewhere over time. The great thing about Postgres is that it's perfect scaffolding on which you can build other stuff.

<comment><USER19> Thanks for taking the time to give such a detailed answer and explanation on historian systems.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I'm surprised no one has brought up Splunk in here (that I could see at a cursory glance).

They manage to do time-series storage on a pretty large scale (over 5PB/day for their largest customer).

<comment><USER21> I wouldn't really say that splunk is time-series in the same way they wanted. It's mainly logs indexing, but not the kind of aggregation you'd want from numeric, labelled metrics.

<comment><USER22> > aggregation you'd want from numeric, labelled metrics.

We use it exactly for this, works great.

<comment><USER21> Do you use the new metrics store? I just learned they have one now in the new versions.

<comment><USER22> No we don't use metrics store.

<comment><USER21> That doesn't really sound like a cost effective way of doing metrics... The amount of data you license from splunk is likely quite expensive compared to a dedicated metrics system, right?

</comment></comment></comment></comment></comment></comment><comment><USER23> Not very knowledgable in the area but can someone please explain how does kdb fit within this class of time series dbs and whether there are any alternatives available to kdb.

<comment><USER24> Kdb is a priprietary db that runs using the processor level 2 cache as memory. Therefore it is crazy fast. Also therefore, it does not handle large datasets.

<comment><USER24> At least in the past.

</comment></comment></comment><comment><AUTHOR> As the blog author, great to see the discussion and feedback, so appreciate it!

Without going through comments one by one, the main ones about this being a solved problem or there's already solutions out there that do this, I would just say those comments remind me exactly of the type of conversations I had years ago with my team. We all thought it would be much easier or thought there would be something off the shelf that could do everything, and after several years of fire fighting, the reality was the problem looks much simpler than it really is, by a long mile.

Now that we've been doing this for a few years, and spoken directly with creators of many other TSDBs, we take a very skeptical view of all claims made about any database. They all sound amazing when you first read about them, maybe even work great in testing, till you hit scale and then you find all the limitations. If there was a perfect TSDB out there, everyone would be using it and there wouldn't be a new one announced on a weekly basis!

I think the one comment on query loads being different sums things up - I've no doubt all the other options thrown out there work well for data historians, but for monitoring tools with loads of concurrent users, loading dashboards with 10's or 100's of queries each, and alerting systems polling every few seconds in parallel, the query load can get very high quickly, and making those fast while still writing metrics in at scale, is a hard problem and I don't think any individual TSDB has really solved that properly, which is why we ended up building our own distributed architecture ourselves.

</comment><comment><USER25> It's pretty ridiculous that "Time-Series Database" has come to mean ingesting massive amounts of streaming data. They've been around a long time and have many use cases.

They're a great way to store data efficiently, accessing specific data if you know the time range you are looking for is very fast and simple, and you can roll your own in a few dozen lines of C if that's what you want to do. If that's all you need, why not?

<comment><USER26> That may be a perfectly good solution if you have a very static infrastructure and narrow use case.

As a thought exercise, for the most trivial solution, you could create a single append only flat file. This may work well for writes, but what happens when you want to read the datapoints for only a single series in time order? This would result in an expensive scan over the whole file. An improvement could be to create a file per series, but this becomes problematic when writing many small datapoints across each different file. The problem worsens in the case of a dynamic containerised infrastructure which produce a unique number of timeseries over very short intervals, which was the catalyst for the development of Prometheus TSDB v2, as the prior version stored a file per timeseries.

As the post states, there is a balance between the read and write pattern - achieving that with a few lines of C for a general purpose case is a difficult task, if not impossible.

<comment><USER25> To be clear, my post was to state that there are many use cases for time- series databases and bemoan the fact that most current development centers around a specific use case. That is in fact what I wrote.

I have a hard time believing that "a dynamic containerised infrastructure which produce a unique number of timeseries over very short intervals" is the superset of all time-series use cases, but perhaps it is so.</comment></comment></comment>


Job interviews go both ways (2011) - <AUTHOR> http://diegobasch.com/job-interviews-go-both-ways-my-story-with-netscape-in-98 <comment><USER2> The author advocates questioning the interviewer directly, but he doesn't mention questioning anyone in his Netscape interview, only making mental notes of various red flags.

In practice, I think that's the way 'both way' interviews generally have to go - you don't interview your interviewer, but you do evaluate and judge your potential employer critically.

Personally, my attempts at interviewing an interviewer have served to inform my decision, but not at all due to the face-value of the responses as they're generally going to be hard if not impossible to validate.

 _> 'Very rarely someone probes me to see if they would like to have me as their boss.'_

I'd like to try that someday...

Who's the weakest person on your team? What do you mean to do about that? When's the last time you lied to someone here? How did you rationalize it? Are you on any medications? Do you cheat on your spouse? What are you most insecure about?

The type of questions I'd _really_ like to know the answers to - the sort that you learn the answers to within the first few months of any new job aren't the sort that I'm likely to get answers to much less completely honest ones.

<comment><USER3> Here are some that I've asked:

1\. "During your most recent budget period, what influence did politics rather than the merits of budget requests have in distributing resources, and in what ways?"

2\. "How heavily influenced by politics (or upper management) is the performance review process?"

3\. "Has anybody recently been let go as the result of being ranked lowest on a performance review?"

4\. "Are managers subject to performance improvement plans?"

5\. "When was the last time your HR department found in favor of an employee over management or upper management when a dispute arose?"

There's a bias to these (if it isn't obvious). But experience informs me that answers to these questions offer a good insight into how the company really operates. If they are honest answers (they won't be, most of the time, if they're answered at all).

<comment><USER4> Existential question of the day: If the answers are almost all lies or omissions, what's the point of asking the questions? To get good at spotting the rare honest answer among the PR? And how do you know what's a lie and what isn't? There's no way to verify anything they're telling you unless you know somebody working there.

<comment><USER3> That's a good summary of my view of the entire interview process, actually, from both sides. The exception would be technical questions, of course--but even those are only marginally more useful at determining anything more than whether the candidate can answer specific questions under specific circumstances, neither of which may actually ever arise during the course of employment.

</comment></comment></comment></comment><comment><USER5> Sometimes. The potential employee is not always in a privileged position. I think with most new grads this is the case (some with significant relevant experience are excepted).

If I were interviewing a new grad or someone that didn't have a recommendation (basically someone I didn't have any context for) and they asked me to solve a technical problem, I don't think I would do it. I would not want to waste what little time we had allotted trying to solve that.

If we did want to make a good technical match I think it would be great to sit down and work on a low hanging fruit bug together.

</comment><comment><USER6> This is why I hate those services that have an automated pre-screen process. The ones where you visit a specific URL and after reading the questions you record a 30 second video with your answer.

The massive hole there is that I don't get to interview anyone the company to see if I feel like its a good fit. I'm sure its saves them time but it wastes mine.

<comment><USER7> Well to be fair, they likely get many more applicants than you have interviews scheduled.

And it's just a pre-screen, right? It's not like you have to make your decision right there and then if you do well in it.

<comment><USER6> I don't disagree but it seems impersonal at best, rude at worst.

<comment><USER8> Even worse (for the hiring team) - it's probably not that effective a filter. You might as well use the "I only hire lucky people" filter [1].

Interviewing needs to be interactive because any decent job requires interaction.

[1] [http://cream.hr/blog/why-the-hiring-system-is- failing/](http://cream.hr/blog/why-the-hiring-system-is-failing/)

</comment></comment></comment></comment><comment><USER9> Did I ever mention that interview with a whizzo East Coast startup where the interviewer couldn't answer where the company was planning to be in five years time? It's one of those questions where they will squirm like eels, but you have to know, because you are committing your time and future earnings to them. Squirming is fine, but being struck dumb is not acceptable. The experience was epic, it ended with a greybeard apologizing for the HR lady.

<comment><USER10> I always ask "Do you enjoy working here?" Their instant response is usually telling.

<comment><USER11> I always ask this. Doesn't even require an honest answer, the length of pause is sufficient.

(although now it's been on HN interviewers will probably be better prepared)

<comment><USER10> At a guess, I'd put the chance that the person interviewing you has seen this at about 0.1%

</comment></comment></comment></comment><comment><USER12> This is a really relevant piece, if I'm interviewing you I'm going to wonder if you're not asking any questions about the company. I get that its hard to ask challenging questions in a situation where you want to get hired, but you will need to ask challenging questions when you don't want to get fired too, and if you can do that you are more valuable than someone who can't.

That bit about everyone focused on the stock price also really resonated. Back in the late 90's "everyone" was a millionaire, at least after all their stock vested be that in 1, 4, and sometimes 5 years. Way more people than I expected couldn't really handle that. The most common failure mode I saw was that suddenly the person would do no productive work at all, and instead start shopping airplane or yacht catalogs, or talking about where the best islands to buy were with their co-workers. I once pointed out to a person that if they did no more work, then the company's value would go to zero and knowing the best islands would be a useless fact to know. But I had grown up in Las Vegas (well spent my teen years there) and that was a town that taught people that money is fleeting in a very brutal and efficient way.

<comment><USER7> I've never interviewed anyone, but also, if they don't ask me any questions about the company then I'm gonna think they simply don't care and they applied for the role "just for a job".

I don't want to work with people who don't care.

<comment><USER13> Eh, I have two rebuttals against that:

\- Is your job worth caring about? Let's be honest, not everyone is working on putting people on Mars or pushing the boundaries of machine learning, etc. A lot of programming jobs are just spitting out code for a paycheck.

When I was a tad younger, with less experience under my belt, and fewer choices in employers, I interviewed at many a job where I was expected to act like I'm deeply enthusiastic about jobs of little import to anyone and technically amounted to not much more than flailing my arms at a keyboard for 8 hours a day. That expectation is ridiculous.

The mudane, boring jobs need to be done. Hire people who are capable and willing.

This is a job, not a church.

\- One thing I've experienced are the grueling full-day interview process that certain companies are a fan of (one such company rhymes with Blamazon). Literally 7-8 hours straight of interviewing, even your lunch hour is yet another interview. I don't think I've ever had intelligent questions by the end of those. The questions I did have were answered by interviewers before you, and at this point I've been thinking about manhole cover sizes, jelly bean estimations, families crossing bridges, and regurgitating CLRS algorithms solutions for so long I can't possibly come up with anything more.

Full-day cycles are grueling, and to expect candidates to be chipper and operating at 100% (or even 80%) is unrealistic.

<comment><USER14> What I do is write down ahead of time 10ish questions, then ask each one of 2-3 interviewers. That will usually lead to one or two follow up questions, and that's about enough. Yes, all-day interviews are grueling, but with preparation I view the question-asking phase as a break.

</comment></comment></comment></comment><comment><USER15> I always do this, but I play it subtle. My primary test of your ability as a manager is your hiring process, because if you get hiring right then all other problems are solvable. The question I am always asking myself is: do I want to work with the worst person who can pass this interview?

</comment><comment><USER16> I interviewed for a dev job a good many years ago. I hadn't heard of the company at the time (they were pretty small so there was no reason that I should have) so I did a lot of research. I remember that their financials were looking decidedly bumpy, but almost always in the black.

I asked about this at the interview. The lady interviewing me looked offended that I would ask about their financial situation as it was "not really something [I] should be worrying about".

I didn't get the job, and their feedback was that they wanted a dev, not an accountant.

<comment><USER17> Bullet dodged.

Not assessing the financial situation of small employers pretty much has always lead to them going bankrupt in my limited experience. And employers unwilling to give any indications are the ones that leave paychecks un-funded when they do (that was an SOs employer).

</comment></comment><comment><USER18> I think one reason for this (not asking enough questions) is that usually early on your career, you don't really have that many options or you are in a situation where you need to get your bills paid with any means necessary.

I have really never (yet) been in a situation where I would have really had enough options to say no to any company offering a job after an interview. In those cases, your full focus is getting them interested - not really about knowing what kind of extra activities they do or what they are planning to be in say 5 or 10 years.

</comment><comment><USER19> > It turns out, the majority of the people don't do this. They simply put on > their best face, answer every question and try to sell themselves. Some ask > questions everyone should ask, such as the financial situation of the > company. Very rarely someone probes me to see if they would like to have me > as their boss.

It's funny. Lots of companies are going to increasingly great lengths to filter candidates based on inane tests that _supposedly_ measure technical competence, but many if not most of them do little to filter candidates based on their apparent interest in the job opportunity as a whole.

Obviously, there are reasons candidates shy away from asking "tough" questions other than "I don't really care", but startups in particular should be wary of candidates who don't demonstrate a certain level of curiosity beyond the day- to-day technical rigmarole.

Put simply, look to hire people who understand that interviews go both ways.

</comment><comment><USER20> One question I always ask my interviewers is "What is the best thing about working here?". You can tell a lot by their immediate response and whether their face lights up with excitement. One answer I will never forget is a developer responding with "We have a Dyson hand dryer".

<comment><USER21> An equally interesting, and perhaps more useful, question I always follow that with is "What's the worst thing about workign here"... The cop out answer is usually 'it's a big company so you get some politics and inefficiencies'.. I suppose a good follow up would be; "how does the company intend to change this going forward?" or even "how does it compare to other places you've worked"

<comment><USER22> As an interviewer I loath that question.

Why would I invest my time interviewing you only to turn around and tell you something that might make you decide not to work here.

<comment><USER23> It depends on your priorities. Do you just need someone to come and fill a spot or would you prefer someone that's actually a good mutual fit for the role?

</comment></comment></comment></comment><comment><USER24> Huh I remember 2 interviews that I was sure I am never ever going to work at the company :-) At one well-known-company interviewer literally treated me like garbage from the very first minute (including waiting for the scheduled meeting in the building corridor), I didn't even try to do say anything then. Another one started pretty well, but then I saw the team (super demotivated) and they asked me to do some shady test-stuff (HTTP referer header spoofing), but the nail to the coffin was the manager telling me that I have to disregard notice time and instantly jump ships for them, because they won't wait for me ;-) So yeah, the interview works both ways, there were jobs (like my current one) that I felt that the fit is strong and the final negotiation effects are not so important.

</comment><comment><USER25> One aspect of "selling the candidates" that can be overlooked is the tech interview. There's a big opportunity to demonstrate your own/your team's technical excellence as a selling point.

What this is _not_ , is skewering someone on "j=j++ in a loop" trick questions, or dryly sacrificing them on the algorithmic altar. Programming is supposed to be interesting, so it should be interesting to dive into fundamentals, language issues, library specifics or whatever, and keep drilling to the edge of the candidate's knowledge, and beyond.

The hope is, the good candidates get grilled a little, and walk out thinking "I could learn something here."

<comment><USER26> Yeah, 'cause language issues and library specifics are far more interesting than dry algorithms.

This seems bass-ackwards. Library specifics, and to a certain degree language issues, are exceedingly amenable to recourse to documentation. An understanding of algorithms, less so.

<comment><USER25> I don't mean to knock algo questions, especially not complexity and data structures.

I do think language and library fundamentals get overlooked, for the very reasons you mention: yes you can google pass-by-value and consult docs about a TreeSet ... but the good programmers don't, they already know when/how/why and don't forget it after a year of doing something else.

<comment><USER26> For sufficiently fundamental fundamentals, I'd agree. I'd certainly include pass-by-value vs. -reference vs. -name in that. I strongly dispute the notion that good programmers don't consult library docs. Library surface area is _huge_ , particularly in batteries-included languages. One should know well the areas they use, but there will be plenty outside that, especially if they're moving between many languages.

</comment></comment></comment></comment><comment><USER27> I guess I've interviewed over a hundred candidates over the years. I always end with: is there anything you'd like to ask me? I can't recall a single meaningful conversation that ensued as a result.

<comment><USER28> During my noob days my questions were always about 1\. Work times 2\. Dress code 3\. Questions of growth in company

As I got exposure it moved on to 1\. Specific question on potential growth 2\. Companies market position risks/challenges and their actions/plans

But I have not asked hard questions that a few have outlined here. Hopefully I don't have to :)

</comment></comment><comment><USER29> I always interview the company interviewing me. The closer I've mimicked Peter Gibbons from Office Space the quicker the job offer arrived, provided I passed their tech tests.

</comment><comment><USER30> The way interviews are conducted, mostly, you are left with a little time at the end. Interviewer will ask you to solve a problem, write code for it. Either the time is just enough for you to solve it, or if you finish too fast, there will be a next question thrown at you.In either case, not enough to have a meaningful short conversation followed by a question, which is sad.

</comment><comment><USER31> It's funny that this article states that it originally came from the IndexTank blog, and the creator of IndexTank just responded to an AskHN questions a few hours ago.

[https://news.ycombinator.com/item?id=7977188](https://news.ycombinator.com/item?id=7977188)

</comment><comment><USER32> Huh, I was asked that very same tree traversal question at an interview recently.

<comment><USER33> Can anyone outline a solution? The only ones I can come up with off the top of my head involve using a stack.

<comment><USER34> In my opinion, it's a somewhat misleading question (or the answer is creative to the point of stretching definitions).

In-order traversal is pretty easy without a stack, if every node keeps track of its parent. 1\. go down left branches until you get to a leaf. 2\. visit leaf, and go up. 3a. if, in going up, you were at a left child, visit this node, then go right. loop to 1. 3b. if, in going up, you were at a right child, go up again. loop to 3. 3c. if you can't go up, you're done.

The trick comes from not really storing the parent pointer at each node, but instead doing trickery with xor-ing various addresses together so that you can store 3 pointers in the space of 2 (plus possibly an extra bit).

Of course, if you do so, you've constructed something that's not exactly a binary tree, and can only be traversed in certain fashions where you'll always have the necessary information to xor.

</comment></comment></comment><comment><USER35> I like this idea but usually interviewers leave me with such little time that it would be unreasonable or impossible to do such a dive with the interviewer.

</comment><comment><USER36> So why is EOF in C defined as -1 (when it is)?

<comment><USER37> If I had to guess:

prematurely ending a stream is a problem for the current stream, and for the next stream as well, and thus is more desiderable to avoid corruption in bytes signaling an EOF than other bytes.

corrupting an EOF in something else is probably not as bad, and/or maybe a corruption 1->0 is more likely than a bit flip 0->1 (maybe when stored/transmitted as 1==higher voltage) and thus

01111111 10111111 11011111 11101111 11110111 11111011 11111101 11111110

are less likely to be corrupted into a EOF, if 11111111 is the least likely state for a byte to be in.

Also, not one of these bytes is a printable ASCII character, which might thus possibly be/have been much less frequent in data streams, and thus further reducing the likelihood the probability of such a corruption happening.

<comment><USER38> While a nifty idea, corruption of this sort is so rare and so unbounded (that is, there's no reason to believe it'll strike in your incoming data, it could well strike at the CPU instructions itself or whoknows) that there's not much you can do about it from inside the code. It's all but impossible to deal with corruption rates on the order of 1 in 10^18 (or better! properly functioning hardware is obscenely reliable at doing what it was designed to do [1]) instructions on properly functioning hardware, and all but impossible to deal with failing instructions at a much higher rate on nonfunctioning hardware, except to replace it with functioning hardware.

[1]: If anyone wants to pop up with complaints about that statement, remember that properly functioning hardware is also doing a lot of things very quickly, so it has a lot of chances to fail. ECC RAM is important, for instance, because something that only happens every few billion accesses may still happen several times a day. But this is still an absolutely obscene degree of reliability. Most disciplines would laugh at worrying about something at that rate of occurrence... they wouldn't even be able to detect it.</comment></comment></comment>


Show HN: Daptin: full-fledged API first server building platform - <AUTHOR> https://medium.com/@012parth/daptin-walk-through-oauth2-google-drive-subsites-and-grapejs-a6de27d9658a <comment><AUTHOR> Daptin is a "self hosted", "API first", headless CMS. Or what we would otherwise call a "Backend as a service".

Daptin works with JSONs and converts JSONs to live websites. Docs are here [2]

[1] [https://github.com/daptin/daptin](https://github.com/daptin/daptin) [2] [http://docs.dapt.in](http://docs.dapt.in)</comment>


Playlist.com files for Chapter 11 - <AUTHOR> http://news.cnet.com/8301-31001_3-20012973-261.html

<comment><USER2> Ok wow, this site is awesome. Simple and clean interface to easily create a playlist and share it. I found all the song I wanted and also found other users playlist featuring my fav. artist.

I know thesixtyone and grooveshark. They both have their uses..

For ts1, I use it to discover brand new artist but the playlist part is so damn hard to use with this sucky interface. I'm always lost in it.. I click on a user playlist, then cannot come back, etc etc.

For grooveshark, it's just terribly slow with a huge flash engine that take all screen.

* edit * : I feel I was really harsh on grooveshark and I feel bad about it. It's a great website that I use pretty often.

Could someone enlighten me about the use of flash for audio.. Is it the only way to play songs?! I think I was playing midi file before even flash existed. :-/

</comment><comment><USER3> Using RIAA/MPAA content is a sure-fire to get traction, as the whole Internet craves/dies for their content. Ironcially, content they dont want to pay for.

Overall the majority of businesses who utilize & market to users come get RIAA/MPAA content never seem to have long lasting businesses.

</comment><comment><USER4> Well Cnet, you seemed to have forgotten about Grooveshark as a point of comparison, for they are doing fairly well. Or how about anywhere.fm (YC S07), which was so damn good before imeem (now myspace music) ruined it. But, I guess TechCrunch saw this coming ([http://techcrunch.com/2008/01/28/imeem- gobbles-up-a-young-st...](http://techcrunch.com/2008/01/28/imeem-gobbles-up-a- young-startup-anywherefm/)).

I really wish Apple gobbled up Anywhere.fm and slap it as cloud iTunes. It's really all a sad story.

</comment><comment><USER5> Good article... short, informative, and fills you in on a whole history in the space of a few paragraphs.</comment>