Tiny Social Icons – Miniscule SVG versions of social app logos - <AUTHOR> https://github.com/edent/SuperTinySocialIcons/ <comment><USER3> Hopefully saving someone a search...

SVG browser support: [http://caniuse.com/#search=svg](http://caniuse.com/#search=svg)

Pretty much everything of any significance supports it except IE 8 which has 0.3% market share and is no longer supported by Microsoft.

<comment><USER4> IE 10 (and to a lesser extent, 11) has really wonky support. In a self- contained SVG, it's fine. Once you need it to scale a certain way, you'll find things get weird.

IE 10 basically dropped off the face of the earth, but 11 is stubbornly hanging on. Still, if you're optimizing the size of SVG bytes for the benefit of these browsers, you're likely to add that weight right back in with all the IE-specific CSS you're likely to add in.

<comment><USER5> If you deploy a Remote Desktop or Citrix Server based environment - <USER2> Microsoft/Citrix continue to push heavily to enterprises - well Microsoft set Windows 2016 Server as the flagship server OS and then for some reason didn't include Edge. Just IE11.

This decision still makes IE11 Microsoft's recommended browser for those deployments, which sets a course for certain enterprises to prefer it over Edge for new deployments.

</comment></comment></comment><comment><USER6> The icon with the two white dots is far from optimal still: The grouping is unneccessary. style="fill:#FFFFFF" can be replaced by fill="#FFF". There are useless newlines. height="100%" width="100%" can be replaced by height="512" width="512"

<comment><AUTHOR> That's a good point! As I say in the readme, I left in the newlines to make them more readable - but I'd certainly take a PR for the colours and grouping.

As for the heights - will that make a difference if the image is scaled?

</comment></comment><comment><USER7> SVG is such a superior format for icons, it scales perfectly, is very efficient size-wise. The only annoyance is getting them inline so that they can be styled with CSS.

<comment><USER8> I love SVG in general... I am curious to hear, is there any reason not to use them? Maybe that it's not as well supported on older browsers?

<comment><USER9> _I am curious to hear, is there any reason not to use them?_

As an alternative image format to things like PNG? There aren't many, if it's an image that lends itself to a vector format in the first place. SVGs have been widely supported for some time, often have significant file size benefits as we see here, and scale cleanly to different screen resolutions. You have to go back to versions of IE that even the likes of Microsoft and Google won't support any more or to very old mobile devices to start running into general compatibility problems.

One thing to be aware of is that you are effectively programming your graphics if you're using SVG, not just recording the image itself. If you start playing with the more powerful features, particularly using non-trivial filters, you might occasionally run into issues in the rendering code that turns your program into an on-screen image. Depending on how much of that code is in the browser itself and how much is delegated to the underlying OS/graphics drivers for acceleration, that can cause problems including slow display of images, distortion so the rendered image doesn't look right, or in extreme cases even hanging the browser or graphics driver if you're unlucky enough to trigger some underlying bug (which is obviously a rare result, but I have personally seen it happen in my own development work). For the kinds of very simple SVGs we're looking at here, I can't imagine any of these potential problems being a serious risk, though.

</comment></comment></comment><comment><USER10> This is really great. As someone who has done quite a few size-sensitive projects/experiments, have you considered providing them in a small website? So _artists_ can contribute with more icons and developers who want to use them can modify them when downloading (border radius, background, etc). I could throw a quick prototype if that sounds good.

<comment><AUTHOR> Go for it :-)

</comment></comment><comment><USER11> whenever i need a figure, instead of opening paint I hand code a SVG. It takes a bit longer then painting. But is more acurate. its basically just xml and math. maybe a bit of css for styling. i would like to see less bitmaps and more SVG especially by web devs.

</comment><comment><USER12> Oh tiny in storage, not in dimensions.

<comment><USER13> SVG: Scalable Vector Graphics - can be rendered at any size.

<comment><USER12> Somehow unrelated, many people showed how at low resolution vector graphics rendering alter the perceptual nature of icons compared to bitmaps (crafted by human eyes for human eyes). So I believed the author made vector shapes, with the goal of very small "ascii art" flavor baked in.

</comment></comment></comment><comment><USER14> It's too bad that this site is even required.

When I was putting together a handout for work ([https://twitter.com/StanfordCompute/status/85047937335846502...](https://twitter.com/StanfordCompute/status/850479373358465024)), I wanted to get vectors of the four logos that appear on the bottom of the front side (of course I already had a vector of our logo).

Both SLAC and XSEDE had vectors available on their web site (IIRC, as EPS files). For the Open Science Grid, I had to reach out to someone, but that was easily done. Same for ICME.

I guess the corporate world is different: I'm sure they have vectors (likely as .ai files, which can be exported easily enough), but don't want to make them available. That's too bad.

</comment><comment><USER15> I might have to add my Instagram SVG to this collection. Mine is 4 lines of SVG with a def for the the gradients. I started with the 1.8 Mb file provided by the Instagram brand guidelines and set to work.

Inline SVG is the way to go, however, if you have a large SVG stylesheet then some hacks are needed to load it as a cached image and get the thing inline on the page. Greatest fun since LEGO though!

<comment><AUTHOR> Please do!

</comment></comment><comment><USER16> I wish I would have big enough site that this would matter in bandwidth cost.

<comment><USER3> Even at Amazon S3 prices and a million downloads the cost savings of using the SVG for the Github icon is only $1.60 per month. If it took an artist an hour to make at $30 an hour it would take a year and a half to break even.

<comment><USER17> keep in mind that making the size smaller also make your website more light and faster, same thing for android/ios app, where the fact that this icon are in svg format make them scalable at different resolution, screensize and dpi. Image are usualy the main reason to oversize app and webpage.

</comment></comment></comment><comment><USER18> I'm sure you have great intentions but sorry these don't look great. Can you have both size and quality?

<comment><USER19> You might be missing the point of vectors.

</comment></comment><comment><USER20> > Simplicity should be our goal in all endeavours.

Then maybe we shouldn't use complex vector graphics, and instead use nice and simple uncompressed raster graphics. /s

<comment><USER21> Especially since SVGs are not hinted for small sizes (AFAIK).

I'm not even sure if SVGs are rendered equally at the pixel level on all render engines. This is important for small images.

<comment><USER9> _Especially since SVGs are not hinted for small sizes (AFAIK)._

This is true, but the situation is no different with the main raster image formats either, and the solutions are the same either way.

 _I 'm not even sure if SVGs are rendered equally at the pixel level on all render engines._

They certainly aren't. You're programming a graphic and then whatever rendering stack is available on the user's device will render it as an on- screen image. The quality of that render, for example when it comes to gradients or anti-aliasing, is environment-dependent.</comment></comment></comment>


"I will be taking this to sequioa capital" Yea, good luck buddy. - <AUTHOR> http://miami.craigslist.org/pbc/cpg/923516045.html

<comment><USER2> Why is this so bad? The difference between what was said there and what is said behind closed doors is... closed doors. Many people in this community, or with similar goals to many in this community, talk that way. Perhaps many people are less abstract and more practical, but the end game is still the same.

Back when I was young and naive, a year or so ago, I'd talked with many about wanting to meet with Sequoia. Since then I've met with Sequoia and become a little less young.

<comment><USER3> Vagueness, name dropping, [cargo cult entrepreneurship], hubris, and absurd sentences like 'If you have nothing better to do, let's change the world.' All in the context of a world with enough information on starting web businesses online to read past this level of naivety. All things hackers intend to bristle at.

On the scale from savvy to clueless, this doesn't rate well. But the snarky tone of the headline isn't any better. Sequoia isn't even spelled properly...

<comment><USER2> I could more readily agree with what you're saying if a great resource like Hacker News didn't consistently get high-ranked items with headlines like "10 Ways To Get Motivated To Change The World By Starting A Startup"

For what it's worth: the CraigsList poster is light years ahead of midwestern Union workers are with their compulsions to invest in Quixtar and 'systems' from Carleton Sheets.

But really, who is to judge? I think it's cool that this person is, at the very least, pretending to try.

<comment><USER3> I think it's cool too. And I'd give them encouragement. And I'd try to resist the urge to pat them on the head.

But as for why it's getting voted up, that's my assessment.

Honestly, I really dislike the self-consciously self-focused articles we've been getting like our "10 Ways to Get Motivated..." articles. It's so... contentless. I come here for "Hacker News," not "'Hacker News,' News."

</comment></comment></comment></comment><comment><USER4> so the guy's a noob, big deal -- we've all been there.

he'll get a rude awakening soon enough, but i would imagine HN ought to encourage starting somewhere rather than not trying at all?

</preach> :)

<comment><USER5> "so the guy's a noob, big deal -- we've all been there."

Good to hear I'm not the only one dumb enough to have done stuff like this in the past.

</comment></comment><comment><USER6> Since when have the qualities of enthusiasm and naivety become so easily interchangeable?

I'm sure that some of what has been posted is simply brutal honesty, and the realities of this business are certain to mar what lofty expectations some may have about entering it. But, like a marriage, it isn't enough to deter and corral me.

I have come to form an honest opinion about life. You are one of two people in this world: The person who writes about others, and the person whom others write about.

I'll be honest, reading some of this did take me back a little, both because of the message and what appears to be a brooding opinion about such hopefulness that I displayed in my ad. In one sense, I am glad to see this at the onset, so that I know it exists. I've faced countless obstacles in my life, some seemingly insurmountable, but time and again I have overcome them.

Attached is my letter to my responders. Feel free to comment away.

All,

If you read about this posting on the Hacker's Web Site, feel free to continue reading, but I would prefer to work with people closer, for convenience issues, of course. If you are still very interested in the project, be sure to contact me with any questions.

Plenty of people have expressed an interest -- many more than I thought would, so we're off to a great start. Not everyone will be involved, though, but I have been impressed by much of the stuff I've seen already.

I put out the initial ad with very few details about the project, hoping that there would be people out there who still possess that entrepreneurial, heck- let's-do-this spirit. If I've gotten respondents who are looking for the next great business proposition, with a low disposition for patience and computer craftsmanship and those who are only searching for a complete by-the-books partnership, you can just move on, there's nothing for you here.

Like I told one respondent, I'm 28 years old and I've accomplished much more than most would in 58. I would like to take advantage of what is left of my youth to push the limits of my creativity and my ideas.

I have worked hard all my life. I got into Journalism -- and by extension marketing -- at the age of 18 and have been doing it for 10 years; going from submitting articles for free to publisher of a regional chain of newspapers. I'm the guy who exposes the scammer every week through my work and the work of my reporters.

But I am asked if I am perhaps just a little wide-eyed? Sure as hell I am. But has it paid off? Sure as hell it has.

There is a time and a place for material plans, for concrete designs and implementations -- that is the entire reason for meeting, and NDAs. So I look forward to it. No, I don't claim to know the ins and outs of the industry, but time and history have proven that convention limits you; let's create our own type of convention and not follow what has been done before us.

I have the detailed outlines of these plans ready, and, beyond that, am ready to tweak and chisel away at until they're perfect. But there are significant twists to these concepts that, in my mind, at least, guarantee success.

At least the initial terms will focus on a few key areas: careful implementation, a process outlined by frugality, and an experience that we will introduce, but not tie up precious resources and man hours having to maintain.

That is not a gate being closed to external ideas.

I began this search for 'mad men' and that is entirely what I am searching for. I'm looking for Lennon. I'm looking for Allen. I'm looking for Lincoln, for Gore. I'm looking for Gehrig, for Domingo, for my Whitman, my Thomas, my Dylan. This will not be an individualistic project, not at all.

But I'd rather have a close-knit group of guys, a handful or less, with like- minded ideals, than a squad full of geniuses with an elitist view of the world. I'd rather have a rock band than a science lab.

I'm looking to contribute and to gain equal parts of what we'll sow, and none will do less than anyone else, or dedicate themselves less than anyone else.

I strive for excellence. And, yes, while others may have more experience in the field of computers, what good is it without ambition and perseverance? What good is it that a person was born with the ability to cure a disease, or to pull readers to his site, if he simply unsure of where to start?

That is what I'm looking to bring here: an attention to detail and quality, an unrelenting desire to see a project through to its completion. We may end up on the cutting room floor, we may not. We may hit upon something truly great, we may not. No guarantees, except that we will do our best and give it our damnedest, are being made here.

You are entitled to your own interpretation of the world, and as such, this letter. You can choose to take it as your clarion call, or your death knell. But there is a reason you responded to my ad. Don't forget that.

Having said that, I understand how someone could view this as naive. Having the benefit of knowing the author's full intent, I can say that there is not an ounce of naivety in this letter.

But, if we could entertain naivety for just a second longer, I'd like to get back to my earlier comment, "Let's change the world."

Who's in?

\- J. Zaragoza

</comment><comment><USER7> The fact that he lives in Wellington or Boca Raton means he very well may know someone at Sequoia Capital, or his father may have founded Nextel, etc. etc. That wouldn't surprise me.

</comment><comment><USER8> Naive people on Craigslist. Film at 11.

<comment><USER9> sexy 21 year old college co-ed looking for an older man to "show me the ropes" if you know what I mean.

NSA.

</comment></comment><comment><USER10> Hey how'd you find my _other_ job posting?

<comment><USER11> Hahahah, it's good to see you've got a sense of humor, Auston. :)

</comment></comment><comment><USER9> On that note, what sort of compensation IS acceptable?

I'd join someone with a vision I believed in/thought would succeed for no salary and all equity.

I wouldnt give up any $ salary for equity to work for a concept I didn't believe in.

How much would it take for you to work for all salary and no equity? I feel like the general consensus in the community seems to be that people undervalue/underpay developers but despite all that I've never really had an idea of what the asking price really is, except that its probably somewhere between 50k and 150k

</comment><comment><USER12> <http://groups.google.com/group/mi.jobs/msg/d81b6c1fa8f361fc>

<comment><USER13> "Your compensation will include meaningful equity ownership."

</comment></comment><comment><USER14> I've never heard the term "from scratch to finish" before.

</comment><comment><USER15> This doesn't belong on HN. I don't really care to read stories about how other people are supposedly naive or foolish. That's what Digg is for.

</comment><comment><USER16> I still want to meet with Sequoia, haha

</comment><comment><USER17> isn't the computer gigs craigslist for stuff along the lines of geek squad etc? You know more to do with hardware than actual coding?</comment>


SkyFly - Vertical Takeoff & Landing Ultralight Aircraft - <AUTHOR> http://www.kickstarter.com/projects/1894175451/skyfly-vertical-takeoff-and-landing-ultralight-air?ref=category <comment><USER2> From: <http://en.wikipedia.org/wiki/Hiller_VZ-1_Pawnee>

"Due to aerodynamic effects in the duct within which the propellers rotated, the platform was dynamically stable, even though the pilot and center of gravity of the platform were fairly high up. In testing, the prototypes flew well enough, but the U.S. Army judged them to be impractical as combat vehicles as they were small, limited in speed and only barely flew out of the ground cushion effect."

Seems like it wouldn't be so great for going over mountains and such.

<comment><AUTHOR> Definitely have to agree with you there. It's not exactly practical, but could make for a better sport than segway polo. <http://www.youtube.com/watch?v=pld9t19WGSc>

</comment></comment><comment><USER3> People have tried to make flying cars since the 60's and yet there has never been a successful product in the niche.

What people seem to overlook is that making a flying car is easy. Making it so that the FCC will allow my mom to fly it and land it in her garage is next to impossible.

If only accredited pilots can buy one the production price won't come down, and if you can only land and take off from an airport as a pilot in an expensive flying device, well then you've invented.... a plane... Congratulations you're competing with Boeing, Gulfstream and Learjet on their own turf - a highly political arena where money and conections count more than anything else.

Here's a link to a company that's beeen claiming that their flying car will go into production next year for the last ten years: [http://moller.com/index.php?option=com_content&view=arti...](http://moller.com/index.php?option=com_content&view=article&id=49&Itemid=57)

<comment><USER4> Sans magical technology (nanotech perhaps) planes will always be significantly more expensive than automobiles.

Consider two scenarios. In scenario 1 I buy a beater car and don't maintain it. What's the worst common scenario that can happen? I end up broken down on the side of the road. In scenario 2 I buy a beater hover car and don't maintain it. What's the worst common scenario that can happen? It falls out of the sky killing all the passengers and possibly people on the ground.

This is why used planes keep their value so well, because every single one of them must be kept up quite well in order to be flight worthy.

</comment></comment><comment><USER5> For Christ's sake... live closer to where you work.

<comment><USER6> Work from home?

<comment><USER7> Sleep on a cot at work?

</comment></comment></comment><comment><USER8> "Why be stuck in two dimensions when you can fly in three!". I don't know about the rest of you, but given how awful people drive while constrained to two dimensions, I'd be truly terrified to see the state of things if travel like this became ubiquitous.

<comment><USER9> Personally, I still hold out hope for cars that can (and are required to) drive themselves, at least on major roads. Get that figured out, and then we can talk about flying.

</comment></comment><comment><USER10> I'm a little disappointed by the cynical comments. This is exactly the type of innovation we should be encouraging. Dismissing it by saying "It won't work," or "It's next to impossible," doesn't help anyone and doesn't move us forward.

</comment><comment><USER11> Can we please refrain from using reddit-like headlines?

</comment><comment><USER12> We have an impending energy crisis and we're dreaming about taking our lazy asses around in flying car?! Jesus, instead of solving grid lock with fantasy of everybody flying to work (I'm sure the sky will be cluttered if it's really affordable to fly, so there goes solving your problem) why don't we concentrate on creating an efficient public transit system, something that would save us fossil fuel and help with traffic.

</comment><comment><USER13> This video discusses a shortcoming of the Hiller Flying platform right at the end: <http://www.youtube.com/watch?v=C_UtPmb3Z-o>

"Ironically, it was the Hiller Platform's inherent stability that ultimately killed the project. The problem was that the platform had a tendency to right itself. Going forward depended on the machine's continued lean in the direction of flight, but it constantly wanted to straighten up and this made it almost impossible to maintain a consistent heading"

How do you plan to overcome that shortcoming? Gyroscopes or something?

Also, why does your platform use the slats instead of a cone duct to direct airflow like the original design?

Other videos:

<http://www.youtube.com/watch?v=cZmULlkOE3o> <http://www.youtube.com/watch?v=MwhBWxc0SSM>

</comment><comment><USER14> "SkyFly is infinitely more stable than any helicopter. Because it is so stable, SkyFly makes flying much easier for everyone!"

Says the designer about an unbuilt prototype.

You know the V-22 Osprey is "just" two helicopter motors mounted on pins on the end of a winged prop plane. Freaking simple.

And a rocket motor is just two tanks of propellant pumped through a big blast proof cone.

Dual counter rotating prop has lower efficiency than a single big prop, it just doesn't have a net torque on the overall vehicle. I just can't see a 6' diameter rotor being strong enough to get far off the ground cushion, much less 2x6' with all the turbulence that comes with it.

<comment><USER13> Actually if you look at my comment above you'll see that the video I posted discusses that the problem with the original platform was that it was too stable.

On the other hand the third video I posted shows a modern miniature version of the original craft. This modern version isn't nearly as stable looking as the original. I can only assume that this is either due to it's size or lack of a duct. My best is on the lack of a duct. That being said, the design for this kickstarter project uses louvres instead of a duct, so I'm wondering if he can achieve the stability of the original Hiller Flying Platform.

</comment></comment><comment><USER15> most people who commute by air don't feel like a boss :)

</comment><comment><USER16> Two issues I could see a problem with:

-As somebody mentioned, these things can't fly that high. Is it going to be dangerous to try to fly it over tall houses or buildings?

-Even if you can get above street level, is the thrust going to, say, ruin your neighbor's garden? You could have a problem with smaller communities banning these, even if it stays legal.

</comment><comment><USER17> Alternately for the $20,000 he could get an old cessna 172, learn how to maintain it and get his A&P mechanic license and have a safe and reliable way to fly during nice weather. Still would need an "airport car" to get to work from the airport though.

</comment><comment><USER18> Since this would be as exposed, and slower than a powered paraglider, why doesn't he just use that instead and find a field to land in for work.

</comment><comment><USER19> Recall how awful parking lots are in 2D.

Now add a dimension.

Scary, right?

</comment><comment><USER20> All money invested in this will be completely wasted. It's a nice dream. But flying cars the general public can use are at least 20 years away. There needs to be a completely automated pilot system that protects you from the 10 million things that can go wrong, windstorms, hailstorms, bird hits, maintenance checks, fuel levels. Pilots get formal educations on how to fly because one mistake and you die. It is no different with this device.</comment>


Potential Employer Cancels Return Flight - <AUTHOR> https://workplace.stackexchange.com/questions/126565/potential-employer-cancels-return-flight <comment><USER2> I don't buy a word of this. That fourth paragraph is an over the top perfect storm of woe-is-me.

> _I 'm completely broke due to poor financial decisions (that's a different > story), so I can't afford a last minute plane ticket. It doesn't help that > this is a small airport, so ticket prices are high. So basically I've been > stuck at the airport for the past 3 days. Yesterday, my credit card started > being declined, so I've had to eat scraps from other customers._

A mild troll, but SE still got trolled.

\---

I guess I should clarify. Responses below are right, it's not hard to believe that there are people without savings, I've also been in that boat.

But this portion has nothing to do with the point of the post; given the outrageous nature of the post in the first place, this smells to me like a sob element to hook more people in.

Every part of the post is hyperbolic. _" I blew every question and I could tell that they didn't like me personally."_ Really, every single one? Oh, and now they decide they don't like you even though you've gotten to the stage where _they flew you across the country_??

Laying everything on this thick just doesn't increase credibility for me. It makes me suspicious.

<comment><USER3> I can relate, because I have had situation where I blew every question and at the end of interview I felt that people were annoyed by me, or my lack of knowledge.

The thing was at that moment I just left shitty job, with 24h phone support for our systems switching with other person on weekly shifts, also I was quite under attack by one of better established guys. I had savings so no problem there. But still I had to find job in something like 3 months before going back to my town.

My self esteem was on the bottom. They got 4 people to question me and senior guy was math phd. After second question it went downhill. Logarithms were not my strong side and then SQL stuff that I was doing day in and out just 'PUFF' went away. (now I am senior, leading team of 5, delivering loads of value, but back then I would not believe I could do that)

I believe that environment and surroundings contribute a lot to what you thing about yourself. I picked wrong fight in wrong time. That guy probably also should work on his basics, or maybe it is just sob story.

<comment><USER4> This is the thing that really scares me about burnout. You get so mentally exhausted, that you are unable to think straight enough to pass an interview even if you would have enough skills to blow them away after a couple months of rest.

I was in a similar situation, basically not recognizing the signs of burnout until layoff time, and it took me 4 months to be able to properly interview (fortunately, the economy was down so it also took 4 months to be able to schedule any proper interviews anyway).

</comment></comment></comment><comment><USER5> I have been on the other side of this. I didn't cancel the return flight, but I was sorely tempted.

In my case it was the early days of a company, and I flew a potentially important applicant from Europe for an interview, paid for hotel, food etc. They performed terribly. When I sat down with them to figure out why, it quickly became apparent they had fundamentally misrepresented themselves. Partially through lies, even more through slippery worded deceit. They finally admitted to being basically a starting-out developer, skilled at attaching themselves to high-profile projects and claiming this work as their own.

I did talk to our lawyer about trying to recover the costs. They told me he wasn't worth the lawsuit.

It was a learning experience. I did things differently after that. In the same way one would change one's behaviour after being the victim of any con.

So I do wonder what the other side to this particular story is.

<comment><USER4> Is there anything that could have been different in the phone interview or skype video that would have exposed this earlier? Or is it too easy for such a candidate to cheat when remote?

Was also wondering what is in it for the candidate -- if they know that they are going to flunk the on-site interview, do they just want a free vacation out of it?

<comment><USER5> > Is there anything that could have been different

I certainly changed the questions I asked. And it never happened again. But I also think wilful deceit isn't that common (massaging the truth is, but this was a different league to that). So who knows if my changes were effective, or if it just felt good doing something.

> if they know that they are going to flunk the on-site interview

I really don't think he did. I think he thought he could charm his way to the job.

</comment></comment></comment><comment><USER6> Note the answer on law.stackexchange: this is breach of contract. The consideration provided by the candidate is the time and effort of traveling, so company employees wouldn't have to do it. A possible exception is if the candidate lied to get the interview.

[https://law.stackexchange.com/questions/36259/if-a- company-a...](https://law.stackexchange.com/questions/36259/if-a-company- agrees-to-pay-travel-cost-for-a-job-interview-is-the-promise-bindi)

</comment><comment><USER7> I agree this sounds pretty damning for the company. But life has taught me to _always_ get both sides of a story before reaching any conclusions.

<comment><USER8> I absolutely agree with you. But at the same time I'm really having a hard time coming up with a reasonable explanation for this from the company's point of view.

Unless the whole thing is an outright lie. It's a brand new Stack Exchange user. There's absolutely no legitimacy to any of the story at this point. People do this sort of thing all the time on the internet, after all.

But assuming it isn't totally fabricated -- even if the guy was completely unprofessional, rude, and/or vulgar (lets say, he stormed out and told everyone to go F themselves), I still can't see it being acceptable for them to cancel his return flight home if they flew him out in the first place.

But I don't think we'll ever get the other side of the story in this case because I don't think we'll ever get confirmation that this is even real.

<comment><USER9> They may have discovered in the interview that he had lied on his resume about his work experience/ education, etc. Getting a free trip by lying would be grounds to cancel any more of the free ride in my opinion.

<comment><USER10> > Getting a free trip by lying would be grounds to cancel any more of the free > ride in my opinion.

Why? How? On what grounds?

<comment><USER9> Fraud

</comment></comment></comment></comment></comment><comment> crooked-v This sounds like it should be a "name and shame" situation, as well as a small claims court case for the cost of return transportation and any additional expenses from the time stuck in the airport.

<comment><USER11> What's this broke person going to do, fly back to take them to small claims court?

<comment><USER12> This is where the press can be leveraged.

</comment></comment></comment><comment><USER13> The only situation I can justify this if there is an undeniable proof of FRAUD. That is a different person takes phone interview and from the one that shows up for in-person.

Its very likely that some one did not do due diligence and ended up with a wrong candidate and wanted to cover their budgeting ass.

<comment><USER14> Nope not even flat-out fraud could justify stranding someone in another city. Some folks are desperate to work and may resort to deception to get their foot in the door for an interview. On the scale of nefarious activity, I put that pretty far down on the list-- slightly worse than jay-walking.

I have my doubts about the veracity of the story, but if it is true then that company needs to be shamed.

<comment><USER15> I disagree -- fraud absolutely justifies this -- if an overweight dark haired guy did the initial video screen and the company flew him out for an interview, but then a skinny blonde guy shows up and can't answer any of their interview questions, I don't see why the company has any obligation to fly him back home -- they agreed to fly out the guy from the video call, not the guy that showed up.

<comment><USER16> Maybe, but it does open up the door to a lawsuit. What if the overweight guy was actually working for a recruiter who had a scam going on to get unqualified people hired. The skinny guy might not know that someone else took an interview for him because it was all a plan by the recruiter. In this instance you're punishing someone who was acting in good faith, but had the misfortune to find a corrupt recruiter.

Better would be to use the legal system to recoup your costs. This way you don't accidentally recoup your costs from an innocent individual with zero oversight.

<comment><USER17> >Better would be to use the legal system to recoup your costs. This way you don't accidentally recoup your costs from an innocent individual with zero oversight.

Or strand someone that fibbed about their experience, that then writes a suicide note (after throwing screenshots of the emails and cancellation up on their social media) claiming you stranding them in a city far from home with no money and no way home was the last straw and then commits suicide in front of your building

Or someone that comes back and sets the building on fire "with nothing left to lose".

Or waits for the person that interviewed them to walk out of the building and assaults them. Or follows them down the sidewalk and shoves them in front of a bus/trolley/train.

There's a bazillion reasons why this was a horrible idea for the company to do, if it is a true story.

<comment><USER15> Those also sound like reasons to hire everyone you interview regardless of how badly they performed, just in case they are mentally unstable enough to act out inappropriately after rejection.

</comment></comment></comment></comment></comment></comment><comment><USER18> Pretty sure, if nothing else, that you could sue them in small claims court.

Unfortunately, in my experience (IANAL), small claims courts only have the power to enforce ruling via liens or other local means. Which means that if you bring suit in your local small claims court, the only way to collect is if the company in question has real estate or other holdings in your local area. Alternatively you could bring a suit in the company's home district, but that means you actually have to show up in court there. Which means travel expenses. Usually it isn't worth it.

</comment><comment><USER19> My then-girlfriend had something similar happen to her years ago. She drove around 5 hours to interview at an engineering/architecture firm and was put up at a budget hotel for the night. Although she had to pay for the room in advance, the company said they'd reimburse her for it and the mileage. Of course they did neither and effectively ghosted her after the interview when she tried to recoup her losses.

<comment><USER20> I learned early on in my career to not bother interviewing with non-local companies that wouldn't pay for my interview expenses up-front (hotel, airfare if necessary). If they're that cheap, they're not going to be a good place to work for.

I've also found that smaller companies tend to be really bad about this stuff (not universally!). Big companies are almost always very fair and honorable about treating interviewees well.

<comment><USER21> Big companies have legal, HR, and compliance departments who know that it's not worth nickel-and-diming on petty shit.

<comment><USER20> Yep, exactly this. HR can be evil at times, but here their evilness is actually a good thing, because it's cold, hard rational logic: "nickel-and- diming on petty shit" is bad for the company's bottom line.

</comment></comment></comment></comment><comment><USER15> I agree with the others that are skeptical of this story.

The only justification I can think of for this is if the company felt they were defrauded.

Like if the guy had a great resume with years of experience in all the skills they want and he passed the phone screen with flying colors and then when brought on-site he couldn't answer a single question, maybe the company thought that he had someone else do the phone screen.

</comment><comment><USER10> I really can't fanthom the thought process that could bring anyone to the point where he wants to strand someone on an airport with a huge bill.

I get that you're angry... but this is vindictive beyond words.

Sue the guy on small claims court, blacklist him, shame him publicly. But cancel his plane ticket so he's stranded and broke on an airport? How inhuman has to be a person to do that? Over a single dumb interview?

</comment><comment><USER22> I really want to know the name of the company now

</comment><comment><USER21> There's another part of this story that doesn't quite add up. Airlines, in general, like to book round-trip flights rather than one-way flights. Not only is a round-trip flight generally less expensive than two otherwise equivalent one-way flights, but sometimes it's even less expensive than either one-way flight booked alone. So why would you ever get a refund for cancelling the return leg of a round-trip flight?

</comment><comment><USER23> I wish people would name the company, especially when it does something this awful. Why be coy? It's not like there is a chance that you'd get the job anyway. You could save lots of other candidates time and grief. Name the company and the first and last name of the recruiter who stonewalled you when you told them you were stranded at an airport due to their unacceptable behavior.

<comment><USER24> That might come following legal advice or action. I can understand erring on the side of caution here.

<comment><USER16> You can always name and shame later. However, once the name gets out, you can't take it back. Erring on the side of caution is the right move.

</comment></comment></comment><comment><USER25> This could easily make national news. Name and Shame.

</comment><comment><USER26> Put it on Glassdoor. Let people learn more about this employer.

</comment><comment><USER27> There is zero chance that this is authentic; ie that this gives us enough of a view into what actually happened.

</comment><comment><USER28> What a petty company</comment>


GNOME and logind+systemd thoughts - <AUTHOR> http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ <comment><USER2> I'd note that, based on the comments in that commit, by default OpenRC still doesn't kill off all processes launched by a service when it's restarted because generally that's not desirable. For example, if you restart SSH you don't want the child processes to be killed immediately because that'd disconnect you.

<comment><USER3> Testing that scenario with systemd - the child processes are spawned in a separate cgroup to the main sshd

(I'm trying out systemd for monitoring and automatically restarting my custom daemons, and finding it much nicer to use and more reliable than the alternatives - while at work we're using sysvinit, and I spent a whole day banging my head against couchdb's init script which tries to do auto-restart- on-crash at the shell level, with all sorts of terrible side-effects...)

</comment></comment><comment><USER4> A GUI being dependent on an init system!? I still don't understand why modularity had to be abandoned in order to implement event-based init.

<comment><USER5> GNOME is a lot more than a GUI. When I installed Arch Linux it was a pain configuring X startup, graphical login, wifi management, etc. As soon as I installed GNOME, all of that was working for me. Plus I like the latest GNOME desktop better than Unity, especially with the direction Canonical's taken with affiliate links in desktop search results.

<comment><USER6> So uninstall the shopping lens or do not use desktop search to find things to buy... this is not a serious usability or even ethical criticism

<comment><USER5> I'm not really criticizing Unity here, just saying I prefer GNOME.

</comment></comment></comment></comment><comment><USER7> tldr: gnome now _actually_ requires systemd

<comment><USER8> I am more and more convinced that moving from GNOME 2 to XFCE was the right move, not just for me, but for many other people.

Choosing a desktop environment ought to be completely decoupled from what init system you have. Building dependencies like this -- both the upstream dependency that was removed, and the various downstream dependencies that are unlikely to be removed because it is a support nightmare to do otherwise -- reduces the user's available choices.

Now, lots of people like to say that choice is bad. And they're wrong about that.

Choice is harder.

<comment><USER9> I think the real problem is that if you want fancy features like a sandboxing solution that leverages the proper way to do it (kernel cgroups, if I understood that correctly), you need to have some dependencies that reach deeper than before.

That being said, no-one is stopping enthusiasts from providing their own solution for the problems that systemd and logind solve for the GNOME project.

I always hated how all these little utilities of GNOME solved problems that were solved a long time ago and properly at that. leveraging existing solutions is definitely a good thing.

disclaimer: i really like systemd :)

<comment><USER3> > if you want fancy features like a sandboxing solution that leverages the > proper way to do it (kernel cgroups, if I understood that correctly)

I'm really liking systemd too, in particular because it integrates so well with cgroups -- IMO we should really be adding equivalent sandboxing APIs to other kernels rather than crippling the init system to remain compatible with the lowest common denominator

<comment><AUTHOR> Various APIs are being added at the kernel layer (kdbus). Only for cgroups there is a change coming up where they just want 1 process to manage the cgroups. At the moment that is only implemented by systemd. This resulted in logind relying on systemd. A lot of bits (kdbus) are on the kernel layer. This is on purpose, we the kernel should track and take care of the sandboxing as much as possible.

So for sandboxing you could do without systemd, but using systemd would automatically give you cgroups. So by (probably) duplicating the systemd code (or maybe using Upstart Session bit), you could do without systemd. But that is not what GNOME is doing.

</comment></comment></comment></comment></comment><comment><USER10> I wonder what the Ubuntu GNOME guys will do with regards to wayland / mir? Anyone know?

As an aside I really love GNOME 3.

</comment><comment><USER11> I'm sure that there would be less controversy about this if systemd and its associated parts were under a permissive license rather than a copyleft, which leaves it incompatible with several operating system environments, notably OpenSolaris which is released under the CDDL and incompatible with the LGPL that systemd is licensed under.

<comment><USER12> That's not correct. At its level systemd is just a component, it's not linked against anything that would cause it to be incompatible and all communication with systemd and its parts are through process-level interfaces (like D-Bus and signals). OpenSolaris, and certainly its derivatives, ship with many GPL and LGPL'd components as far as I'm aware. At this level it falls under GPL's "mere aggregation" clause.

<comment><USER11> It would still form part of a greater work and have to be shipped under the GPL, which is incompatible with the CDDL, so in the end you really can't do it.

<comment><USER12> The OpenIndiana package repository[1] appears to contain several dozen (counting all Gnome packages as just one) GPL'd packages as part of the OpenIndiana-distributed greater work. Can you be more specific as to why this one package would be different?

[1] [http://pkg.openindiana.org/dev/en/catalog.shtml](http://pkg.openindiana.org/dev/en/catalog.shtml)

<comment><USER11> Requirement to statically link against CDDL elements, which is still not permitted by the LGPL.

<comment><USER12> LGPL allows for static linking. The distributor need only be able provide the binary library elements necessary to re-link the LGPL library against. OpenIndiana already provides those. In other contexts, it wouldn't even matter if they were wholly closed-source binary libraries as long as they can be re- linked against. (Aside as an example, in our case of an embedded system, our lawyer has cleared us to do exactly this: link a LGPL'd source file against our proprietary application as long as we provide the ability to re-compile and re-link the LGPL'd source file against our code, delivered as a library.)

Also, the GPL'd portions linking against the CDDL system libraries (as all the other GPL'd packages do) fall under the system library exception.

</comment></comment></comment></comment></comment></comment><comment><USER13> GNOME also requires kerberos :S

[Edit: I originally wrote openldap, my bad...]

<comment><USER9> why is that a problem?

EDIT: Ah, I see. Is that a big overhead? How does it affect me as a non- enterprise user? unnecessarily large installation footprint? (if so, by how much?)

<comment><USER13> Well, mostly because it is basically an "enterprise" requirement. More info here: [https://bugzilla.gnome.org/show_bug.cgi?id=686840](https://bugzilla.gnome.org/show_bug.cgi?id=686840) :)

<comment><USER9> Gnome's Bugzilla 403's for me... is it just me?

<comment><AUTHOR> Please send an email to email@example.com with your IP address, browser, etc. Could be that you're in a netblock that was used by spammers/bots.

</comment></comment></comment></comment></comment><comment><USER14> Luckily it is a Linux only world, where we don't have to build cross platform solutions, none of that considering those nasty BSDs or Minix or anything else really. Just Linux. Oh wait....

<comment><USER15> The question is if it's worth the extra work. I think for minix it's obvious that it's not worth it — nobody is using it seriously as a desktop system with gnome (a quick googling for it even brought up that gnome 3 isn't running on minix anyway). Relying on some things can make it easier to go forward (for instance the mentioned sandboxes).

<comment><USER16> This point of view is perilously shortsighted; even I, a die-hard Linux fan, realize that nothing is forever. Someday (some would argue that day is today ;), nobody will be using Linux seriously as a desktop system with GNOME. Linux may not be around forever, and even if it is, one thing history has taught us is that it won't be the same.

On top of all that, it's never wise to turn down an opportunity to test code against multiple targets (hardware, operating systems, compilers, etc). You'd be amazed at the bugs such testing flushes out.

<comment><USER15> Having to write an own abstraction layer as a perl script that often stops working certainly is more likely to introduce bugs than having a reliable dbus api. Spending the time needed instead for working on bugs that are actually reported by users is more useful. The developers only have a finite amount of time, either they use it to move forward or they use it to try to support every obscure system.</comment></comment></comment></comment>


LALRPOP – a LR(1) parser generator for Rust - <AUTHOR> http://smallcultfollowing.com/babysteps/blog/2015/09/14/lalrpop/ <comment><USER2> Nice addon to Rust. Can this be implemented in rust itself, as part of the compilation ? For all the advanced features that current languages have in the compiler for building and generating code, we have yet to see the first one that actually has a parser generator that's part of the program.

Parser combinators do this, but at runtime (and imho work better than parser generators). It would be nice to see if you could do compile-time parser combinators.

<comment><USER3> > Can this be implemented in rust itself, as part of the compilation ?

I'm not sure what you mean by 'in rust itself'. Do you mean as part of the rust compiler? It works fine as library. If I understand this [0] correctly, you add lalrpop to your build process and it then pre-compiles your `.lalrpop` files to rust code every time you build your project. So, it is part of the compilation even though it's not part of `rustc` itself.

[0]: [https://github.com/nikomatsakis/lalrpop/blob/master/doc/tuto...](https://github.com/nikomatsakis/lalrpop/blob/master/doc/tutorial.md#adding- lalrpop)

<comment><USER2> I mean can the code generation be run as part of the rust compiler ?

D seems to make this sort of thing possible using a number of methods including mixins [1].

[1] [http://dlang.org/mixin.html](http://dlang.org/mixin.html)

<comment><USER3> rustc supports 'plugins' (like compile-time regex), but the interface is not declared stable.</comment></comment></comment></comment>


Why I don't touch crypto - <AUTHOR> http://pilif.github.io/2013/07/why-I-dont-touch-crypto/ <comment><USER2> Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin. Also good thing the Truecrypt devs weren't scared of it, or the Debian devs, or the OpenBSD devs and others who gave us OpenSSH.

Moxie Marlinspike doesn't seem to be scared of it either. According to him it's not impossible to learn simple, tried and true methods for crypto engineering that are all spelled out in Schneier's books and various white papers. These standards were completely ignored by the cryptocat guys (and ignored repeated warnings from auditors). So if you can read, comprehend and do bare minimum research of NIST standards you're pretty safe rolling your own crypto software if you know about attention to detail, the doom principal, PRNGs and their flaws, and know not to attempt to make your own primitives. If you guy's can push out incredibly complex and relatively secure financial trading software there's no reason you can't roll your own SHA-256 on your Android phone replacing SHA-1 FDE or even design Redphone like Moxie did. Would also help if you hung around hashcat forums, read Schneier's cryptogram newsletter, and watched some lectures about software crypto engineering.

<comment><USER3> No, _some_ "tried and true" methods of using crypto are in _one_ of Schneier's books, _Practical Cryptography_. _Practical_ is great, but it's not complete, a fact mitigated by the effort Schneier and Furgusen go to in that book to convince people not to write casual crypto.

The methods described in _Applied Cryptography_ are unfortunately well-tried, but few of them are true. _Applied_ is an almanac of cryptographic concepts. Where _Practical_ tries hard to present best practices at every point in the book, _Applied_ instead strives for the broadest coverage; it's a survey, not an instruction guide. Unfortunately for all of us, ~20 years of _Applied_ readers have tried to put directly into practice the material in that book, much of which is (relevant to modern standards) half-baked.

It's also important to know that _Practical_ is also showing its age. There are very common, very serious vulnerabilities that _Practical_ does very little to prevent. For instance, "Design Rule 4" in _Practical_, "The Horton Principle", implies that message authentication should precede encryption. This construction is now disfavored; protocols that use mac-then-encrypt have been broken with side channels abetted by attacker chosen ciphertext.

Other concepts missing from _Practical_: elliptic curve --- particularly given endangered status of RSA, which would be a nit if not for the extremely detailed coverage Schneier gives to more theoretical threats to AES, (EC)DSA parameter tampering, the notion of minimizing randomness from cryptosystems, the modern AE modes, an in-depth treatment of side channels (where "in-depth" might mean "at least as much coverage as is given to the question of what block cipher mode to use") --- particularly error oracles, applications of hash collisions, RSA message formatting (it doesn't even cover OAEP), and secure key derivation.

I write this from a place of love; _Practical Cryptography_ is one of my all- time favorite software security books. It's one of those books you can "read backwards" to learn how to break systems in addition to learning how to build them. With age, though, _Practical_ is becoming more useful as a breaker's guide and less and a builder's guide.

 _There is no book anywhere that a generalist developer can read to learn how to build a secure cryptosystem from scratch, and generalist developers should be relying instead on high-level libraries like Keyczar and Nacl._

I don't know a think about Satoshi's competence (I couldn't, because nobody knows who he is), but Moxie Marlinspike has spent over 15 years building his competence. If you're Moxie, build whatever you want.

<comment><USER4> If I remember rightly, they actually say in Practical Cryptography that some of the worst crypto they've seen comes from people who've read Applied Cryptography and then decided to roll their own. Which is presumably one of the dangers in writing an "accessible" cryptography textbook is that then people who read it think they understand it... (I say this as a fan of Applied Cryptography, but more as an academic text -- I'd never dream of writing crypto code myself)

<comment><USER3> Applied is a good _book_; it's fun and interesting to read. But people should read it as pop science.

<comment><USER5> What is the deal with Practical Cryptography versus Cryptography Engineering? I have frequently seen people say they are the "same book." How similar are they? The publication date is seven years apart. Did they just add a new foreword and change the title?

<comment><USER6> They _are_ the same book; Cryptography Engineering is simply the 2nd edition, although they decided to change the title for some reason.

<comment><USER3> Everyone in our practice has a copy of one or the other, and the differences aren't at all significant. I'd buy whichever one you can get cheaper.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is not really the most insightful comment, but anyway.

I found the article to be needlessly defeatist.

I am not a crypto expert. I've read Practical Cryptography and have a lots of experience with software engineering in general.

This article (yet again) loosely says "crypto" without specifying whether he's talking about "crypto protocols" or "crypto primitives" (I use "protocol" in a theoretical sense: saving a file piped through gpg with passphrase rememembered in memory constitutes a protocol).

It's well understood that mere mortals shouldn't create "crypto primitives". But I would argue that we're soon going to reach the point where many software engineers will have to understand crypto protocol creation.

Just like many software engineers in the past 10 years or so have had to become aware of multicore (NoSQL, horizontal scaling, Go/Rust concurrency, probably even async callbacks in Javascript etc are all different aspect of multicore, imho).

I don't think we as a profession should abdicate our responsibility to store/transport data securely by just saying "crypto is hard; so don't do it".

I also take issue with the claim that crypto code is either 100% working, or 0% working. From a crypto theory point-of-view, yes, that is how cryptographers think.

But in practice, there is a _VAST_ difference between an attack that requires 2^32 _INTERACTIONS_ with a remote server and one that requires 2^32 _COMPUTATIONS_ on the attackers machine. A cryptographer would say both attacks are equally easy (kinda like O(n) notation).

Just my two cents.

And finally, re: the RNG vulnerability in Cryptocat, that is very bad and just sloppy coding. But even that vulnerability required that the attacker compromise the private SSL key of cryptocat's server. Defense in depth FTW.

<comment><USER8> No, it's not just crypto primitives, it's crypto protocols, too. It's even designing other protocols that run _on top_ of crypto protocols (see CRIME). Even implementing existing crypto primitives is hazardous: D.J. Bernstein's work on cache timing attacks against AES are proof of that.

The problem with crypto is that it's a specialist profession that generalists think they can do. In reality, crypto is more like law than software engineering: You can't just reason it from first principles, and you can't write any tests that will tell you that it's working. You have to know the specific attacks that people are capable of, and come up with a strategy that will avoid not only the current attacks that you know about, but future attacks that haven't been discovered yet. You're tasked with building a system of obstacles that nobody will be able to find any clever workarounds for, and your adversaries are smarter than you, more numerous than you, more well- funded than you, they're experts in breaking crypto, and they're all _from the future_.

That's not something a handful of engineers working in isolation can do. It takes the whole community years to even come close.

Saying that software engineers can design crypto protocols is like saying that software engineers can be their own lawyers. A few can, but almost all engineers who think they know the law are wrong. Even lawyers routinely lose cases. The best we can do is to try to give them better tools to handle the common cases (e.g. Creative Commons, SSH, better APIs), and remind them to talk to the specialists before getting too creative.

</comment></comment><comment><USER9> The thing about crypto is that _nobody_ can get it right the first time. It requires two things that most programmers have in relatively short supply. Radical transparency and radical _humility_.

<comment><USER3> I mentioned on another crypto thread the frustrating fact that more than one professional crypto friend of mine is working on designs that could replace PGP, not to mention a lot of terrible ad hoc app crypto --- but because they're pro's, they're uncomfortable sharing designs until they're confident that they've fully validated them. That's what humility looks like: knowing you're an industry leading expert at cryptographic design and still waiting months or even years to publish so you can make sure you got things _right_.

Compare and contrast.

</comment></comment><comment><USER10> That attitude to crypto is pervasive, annoying, and wrong. We don't tolerate the "you're too stupid to use that" attitude in any other part of software development, and we shouldn't tolerate it in cryptography.

Every developer needs to touch crypto. Encrypted communications needs to be our default. And yes, of course, we should prefer verified, standard algorithms (NSA Suite B, for example).

It's OK to get it wrong, it's OK to fail forward, even with cryptography. ROT13 will protect you very well, if your attack vector is someone glancing over your shoulder for 1 second. As long as the code is open, and you're honest about what it does, you've made people a little bit safer.

There's a fair amount of gloating around Cryptocat, but it protected people's communications from me, because I didn't know how to break it. So that's better than nothing.

<comment><USER3> Everybody should be able to fly a plane, too. Think of how awesome that would be! A rebirth of the American general aviation industry; new airplane designs; solutions to congested airports.

It does not follow from that sentiment that anyone should be able to jump into the cockpit of a Cessna and just figure things out for themselves.

<comment> ryan-c The part where this analogy breaks down is that some random person will probably die in a fire pretty quickly if they try to fly a Cessna. Crypto is like a Cessna that's easy to fly but if you don't fly it exactly right, a few months after your flight, the ground under your flight path spontaneously combusts.

</comment></comment></comment><comment><USER11> I wrote some "home made" crypto about a year ago. It's a one-time pad implementation.

[http://16s.us/FreeOTP/nsa/](http://16s.us/FreeOTP/nsa/)

The math behind OTP is pretty simple, but I may have made a mistake. I've posted the source code to crypto forums, HN, wilders security and emailed it to several prominent crypto developers/experts. No one seems to care nor want to look at it in-depth.

I've worked as a dev where we encrypted research data using standard, industry-accepted crypto (RSA and symmetric AES, etc) as well.

Having said that, I'm not an expert. And the real experts (Bruce Schneier) won't verify anything. They just say, "It's not been broken yet, which is a good indication."

Dive in and write some crypto code. Do it and make mistakes. That's how you learn. Not every program is life or death/mission critical. And if you never do it, you won't learn how. We learn by making mistakes.

Tarsnap is nice crypto code if you like C. It's easy to read too. I have no relation to Colin Percival or tarsnap. He's an expert, and even he makes mistakes:

[http://www.daemonology.net/blog/2011-01-18-tarsnap- critical-...](http://www.daemonology.net/blog/2011-01-18-tarsnap-critical- security-bug.html)

<comment><USER12> _No one seems to care nor want to look at it in-depth._

I'm not an expert, but I wouldn't look at an OTP implementation either. Key management is already hard enough. It's hard to imagine a useful system you could build on a one-time pad.

<comment><USER11> Anyone wanting to learn more about information theory, decrypting to multiple plaintext messages or unbreakable encryption would find it interesting. OTP is an edge case and it does not scale (I understand that), but is useful for small messages between two parties when privacy is paramount. Government states have used it.

Also, I can't find any other OTP source code that compiles and works.

<comment><USER13> You take a file an xor it with the pad. It's like five minutes work, tops. The user interface on top of that might be very interesting, but I honestly find it hard to imagine that the underlying algorithm could be messed up and that you'd still have something that could use the keyfile on something encoded to produce a readable plaintext.

Not wishing to be a drag here, but it's been done over and over again in every intro to cryptography class I've seen.

Sorry ^^;

</comment></comment></comment></comment><comment><USER14> All these "crypto.... scary!" things are right of course. But somehow tiresome. They're ripe for satire... something involving Chuck Norris being the only one perfect enough to encrypt stuff, just as he's able to compress random data. 100%. With his biceps.

<comment><USER3> Serious question: why does this bother you so much?

If we were talking instead about people operating their own pharmacies, or doing their own home electrical work, nobody would bat an eyelash.

<comment><USER15> Home electrical work is a great example.

Just pick up a $10 book at your local Home Depot and if you can read and follow the simple instructions and guidelines inside, you'll be able to do most simple electrical work.

Some electricians may say that it's foolish to do your own electrical work unless you're a trained/certified electrician.

Lots of people do most of their own electrical work without problems, and only hire expert electricians for the really risky or technical parts such as connecting to the utility companies or dealing with really high voltages.

<comment><USER3> "Simple electrical work" might equate to "wiring Nacl into an application". Designing a cryptosystem to replace Nacl in your application is more akin to climbing up the pole in your alley and working from there.

But I'm particularly interested in David's response, because he raises this concern pretty regularly.

<comment><USER16> Is there some kind of cryptography for idiots guide around?

Something that explains how to use a high level cryptography library safely. A guide that recognizes that the reader is probably stupid enough to create a buffer overflow if he even goes near C++. A guide that assumes the reader will use rand to generate keys if able to and not reminded _multiple times_ not to. A guide for people who have never heard about side channels. A guide that seriously cautions not to hand over the plaintext to Eve even if she asks nicely.

<comment><USER3> If you use the right library --- Nacl or Keyczar, or call out to PGP --- you don't need to be an expert to build cryptography into your application.

In all the stories you read about some generalist developer blowing their users' feet off with bad crypto, what you're reading about is someone _reinventing_ these libraries with vanity crypto.

<comment><USER16> Edited, original from [https://code.google.com/p/keyczar/wiki/CppTutorial](https://code.google.com/p/keyczar/wiki/CppTutorial)

      keyczar::Keyczar* crypter = keyczar::Crypter::Read(location);
      if (!crypter)
        return;

      crypter->set_compression(keyczar::Keyczar::ZLIB);

      std::string input = "Hey Alice, here is Eves message: [quote]"+superescape(evemessage)+"[/quote] Your Bob";
      std::string ciphertext;
      bool result = crypter->Encrypt(input, &ciphertext);

Ooops because, [http://arstechnica.com/security/2012/09/many-ways-to- break-s...](http://arstechnica.com/security/2012/09/many-ways-to-break-ssl- with-crime-attacks-experts-warn/)

<comment><USER3> Sure. I think that speaks to my point; the compression side channel was novel enough that trained cryptographers missed it in Keyczar.

(Just don't use compression with your encryption and avoid the issue entirely).

<comment><USER16> Well, even if _they_ removed it, our hypothetical library user could do it by themselves if not told not to.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> This point bears repeating every so often: cryptography is difficult, and those of us who haven't spent years in its mathematical bowels are not qualified to create usable algorithms. Meaning: the encryption code you wrote yourself is probably hackable. Easily hackable.

I first encountered this in a classic essay by PGP's Phil Zimmerman: [http://www.philzimmermann.com/EN/essays/SnakeOil.html](http://www.philzimmermann.com/EN/essays/SnakeOil.html)

edit: fix incorrect link

<comment><USER18> It's not just algorithms. Implementing the algorithms securely is also hard. Even using libraries implementing algorithms is hard.

Actually, most problems are at the security protocol level. Implementing those is the hardest.

<comment><USER17> Excellent point; I wish I'd thought to mention that. I spent a few years as a CISO, and honestly, I know that I really want anything to do with the security industry again, outside of making sure that systems and apps are as secure as I can make them.

Why? Because security is a lot harder than most people recognize. Blowfish is an excellent symmetric encryption algorithm, but, as you say, it would be easy enough to implement it badly and end up with insecure, trusted code.

<comment><USER3> Blowfish is not an excellent symmetric encryption algorithm. For instance, it has a 64 bit block size, which makes it riskier to use in CTR mode and makes some ciphertext malleability problems easier to exploit.

<comment><USER17> Shows you what I know. :-) I assumed because Schneier created it ...

</comment></comment></comment></comment></comment><comment><USER19> I feel kind of divided about using the Cryptocat as an example. On the one hand, yes, off-by-one errors (and similar simple mistakes) are really easy to make if you you're writing something with low feedback.

But the Cryptocat example is frustrating because the code is _so bad_. Not in a "poorly written" sense, but in a "going about things in a completely insane way" sense. The code generates a random number between 0 and 1 not by dividing a 53 bit random number by 2^53, but by _generating 16 decimal digits_ , with the rationale that 2^53 ≈ 10^16. If the code hadn't been trying to do the wrong thing in the first place, there wouldn't have been an opportunity for that off-by-one error.

My point isn't that you'll be protected from simple classes of errors as long as you're coding sanely, but rather that that is the lesson you teach if you point to Cryptocat as your example. Crypto _is_ hard, but you can't make that point very well by pointing to code written by someone who doesn't know the correct (and incredibly standard) solutions to common _non-crypto_ problems.

</comment><comment><USER20> _" Crypto can't be a «bit broken». It can't be «mostly working». Either it's 100% correct, or you shouldn't have bothered doing it at all. The weakest link breaks the whole chain."_

I completely agree. Ever seen a password hash mega-post on paste-bin? Bought to you by bad crypto. Saying "I don't know" is one of the hardest things to do, and also one of the most powerful. I applaud you for knowing your limits in this regard. I like to say crypto is like surgery, best left for the experts. You never want to "I kinda messed up that triple bypass," because there are major consequences for it. The same is true for virtually all aspects of cryptography. Thank you for this post!

Edit: Here a link to a blog post that was discussed recently on HN that is pertinent: [http://www.daemonology.net/blog/2013-06-17-crypto-science- no...](http://www.daemonology.net/blog/2013-06-17-crypto-science-not- engineering.html)

<comment><USER21> I disagree. You could, for example, unintentionally lose entropy without entirely breaking your crypto.

</comment></comment><comment><USER22> I don't like this attitude. It's really anti-hacker.

Of course, the world is littered with cryptosystems that some foo thought would be secure and wasn't. XOR isn't encryption. ;)

I would suggest that hackers interested in crypto take a sober and unafraid look at the history of crypto and then spend time breaking ciphers, "hacking" in all senses of the word. Read the crypto papers and work on the advanced math until you really and truly grasp "all the things". Pour those 10K hours in....

Crypto is hard. Doing it mostly right requires humility and hard study, and then you have a good chance of being wrong. Nothing to be afraid of if you understand the situation and understand the years and years it takes to really become good at it...

</comment><comment><USER23> I have said this before, but what we really need is the equivalent of SQL for cryptography. We need a language that can be used to describe what kind of security is needed from a cryptosystem and a compiler to turn that into code. It is not just that cryptography is hard to implement; it is also easy to use it incorrectly, compose it poorly with other systems (see the Skype attack), etc.

<comment><USER5> I recently skimmed a giant manuscript about the creation of a language for defining cryptographic requirements and primitives (120ish pages). I seem to recall that the author was either from Stanford and/or had a name that begins with a "P". I wish I had saved the citation. Hopefully someone else will be able to recognize what I am referring to with my shoddy reference.

<comment><USER6> That does sound like CAO [1,3,4], from the CACE [2] project.

[1] [https://eprint.iacr.org/2005/160](https://eprint.iacr.org/2005/160)

[2] [http://www.cace-project.eu/](http://www.cace-project.eu/)

[3] [http://www.cace- project.eu/downloads/deliverables-y2/CACE_D5...](http://www.cace- project.eu/downloads/deliverables-y2/CACE_D5.2_M18.pdf)

[4] [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf)

</comment></comment></comment><comment><USER24> Why on Earth did the Cryptochat guy write his own cryptography functions in the first place? Couldn't he have used the Stanford crypto JS library?

<comment><USER25> The inexperience and hubris of youth. We all have this to varying degrees, but those entirely new to the field for whom it is their first profession have it in spades (that's both a gift and a curse; great things are built by "naïve" trailblazers).

</comment></comment><comment><USER18> It's not just a matter of perfection in the field of programming. It's an entirely different field that happens to involve some of the same things and ideas. Just because you're a driver, it doesn't mean you're a qualified mechanic, and if you're a mechanic, it doesn't mean you're a forensic crash investigator. They are related in terms of subject matter, but they are not equivalent skill sets.

As programmers, we are dealing with interfaces and movement/copying of data. Security deals with epiphenomenal leakage of access and data. It is not programming, though it involves programming.

</comment><comment><USER26> These aren't good reasons to not touch crypto, these are good reasons to not cook up your own. Use a standard implementation, and move along.

<comment><USER27> These also seem like good reasons not to use proprietary/closed source solutions.

At least with cryptocat everyone know knows about the security issues now and take precautions as if their entire encrypted communications have been compromised. With proprietary solutions you have to rely on an honor system where you hope the vendor tells you there is an issue.

<comment><USER28> Relevant: [https://www.schneier.com/crypto- gram-9909.html#OpenSourceand...](https://www.schneier.com/crypto- gram-9909.html#OpenSourceandSecurity)

</comment></comment></comment><comment><USER29> The article implies that the off-by-one error in the Cryptocat random number generator is catastrophic. Correct me if I am wrong, but surely that is hardly the case. The random numbers generated are a tiny bit less uniformly distributed than they would be without the error. That's an imperfection but does it have any practical consequences at all ? I know that flaws like this can introduce weaknesses that are vulnerable to attacks, but my intuition tells me this flaw is very close to the "doesn't matter" end of the catastrophic->doesn't matter spectrum. I am more than willing to be educated by someone with specialised domain knowledge.

</comment><comment><USER30> There ought to be a good set of FOSS unit tests for those who dare implement their own crypto. For instance, you let it hook in to your PRNG, and it'll tell you if the output is random-looking enough.

It wouldn't be a panacea for bad crypto, and it does create a risk of people thinking "oh, it passed all of the tests, it must be secure," while still implementing it overall incorrectly. But I still think it would mitigate these "foolish/easy" errors and allows devs to focus on proper overall implementation.

Or does something like this already exist?

<comment><USER6> If you're only worried that your PRNG doesn't _look_ random, there's TestU01: [http://www.iro.umontreal.ca/~simardr/testu01/tu01.html](http://www.iro.umontreal.ca/~simardr/testu01/tu01.html)

However these are just statistical tests; they tell you nothing about how much actual entropy you're actually getting (cf. Debian). That said, it probably would have caught the Cryptocat bias.

<comment><USER19> >they tell you nothing about how much actual entropy you're actually getting

I'm not actually sure what "actual entropy" would mean in this context if not "the number of bits in the seed".

<comment><USER6> Not only the number of bits in the seed, but also their unpredictability.

There are many things that can go wrong. Some examples:

\- the seed is timer-based and has far less entropy (information) than its bit size

\- the seed is OK, but the generator is somehow weak (e.g., only made with linear components, or throws away parts of the seed, or outputs too much of its internal state)

\- Bugs, bugs everywhere (cute example: an RC4-based generator that uses the XOR trick to swap elements)

No standard statistical test would catch those (it would catch the latter, actually), even though the security of the generator would be gravely diminished.

</comment></comment></comment></comment><comment> loup-vaillant When you can't have bugs, you can have proofs. While unknown angles of attack can exists, it is still possible to prove that the known ones are closed.

This is going to be costly…

</comment><comment><USER31> But if few people bother themselves with encryption code then there are not many eyeballs on it and mistakes or backdoors become more likely. Probably encryption code should not be left entirely to the "experts" at NSA, Microsoft, etc.

</comment><comment><USER32> So how does one go about writing crypto ?

<comment><USER33> Assuming you're talking about implementing, and not using preexisting, vetted libraries:

Spend a long time in the community. Listen closely to the people who have a good reputation. Have your code publicly vetted before it's ever used. Expect your code to be torn apart.

</comment></comment><comment><USER34> "Writing a testcase for this would have required complicated thinking and coding which would be as likely to contain an error as it was likely for the code to be tested to contain an error."

i don't know the details, by why couldn't you just collect a million bits of supposedly random data from the generator and run it through the nist test suite? it's true that testing for randomness does require complicated thinking, but fortunately it's been done. standing on the shoulders of giants and whatnot.

</comment><comment><USER35> Good, because you can't even spell it in your title.

</comment><comment><USER36> He clearly doesn't touch unit tests, either, or he'd know that they would address ALL (as in, 100%) of his concerns here. Crypto is even easier to test than 99% of things... all you have is a couple of inputs, and an output. Boom, test cases.

<comment><USER37> I'd just like to point out that `cryptography' is _not_ just about testing that `decrypt(encrypt(msg)) == msg`. memfrob'ing a region of memory does this, but would we consider that a 'secure' encryption scheme? I don't think so . . .

Even if it was -- how do you unit-test a PRNG to ensure the output is uniformly random? How do you ensure you don't have collisions in a hash function? How can you ensure that there's no replay attack on your protocol? How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma?

These are all very real and valid cryptography concerns. Sorry if this sounds snarky, but in all seriousness -- I'm very curious as to how you would unit- test these.

<comment><USER38> _how do you unit-test a PRNG to ensure the output is uniformly random?_

NIST standard test suite @ [http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_sof...](http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html)

 _How do you ensure you don 't have collisions in a hash function?_

All hash functions have collisions, by definition, since they represent a unique checksum of a large amount of data in a smaller keyspace. What you are really asking is probably "how do you prove that you have difficult to predict collisions"? I don't know. (I assume that the mechanisms for doing that are based upon statistical analysis of the propagation breadth and speed of various single bit changes in the input stream over varying numbers of rounds?)

 _How can you ensure that there 's no replay attack on your protocol?_

A combination of session keys and message sequencing? (eg. Each message must include a hash of the last.)

 _How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma?_

There's an entire field of computer science around formal proofs; I don't know enough about it to really comment, however a partial answer may lay in there. Essentially that means adopting a design-time proof strategy in your testing rather than a post-facto unit-testing proof strategy, though.</comment></comment></comment>


Bumblebee decline points to mass extinction, according to study - <AUTHOR> https://www.theguardian.com/environment/2020/feb/06/bumblebees-decline-points-to-mass-extinction-study <comment><USER2> The cynical among us can view this as an opportunity to invest in honey.

Clearly the bigger problem is that bees are one of a kind pollinators, without them we will probably starve in large numbers. But I wish my grandchildren would have the opportunity to taste real honey - unprocessed, unfiltered, unpasteurized with the amazing texture.

Luckily for us, honey has an almost indefinite shelf life, if stored properly (basically kept in a sealed jar, in a cool dark place). I have tasted honey that was at least 70 years old and despite the weird colour (almost black), it tasted just fine.

<comment><USER3> Apparently honey bees are gonna be fine. Humans will keep them alive. It's the wild bees that show signs of mass extinction.

[https://www.wired.com/2015/04/youre-worrying-wrong- bees/](https://www.wired.com/2015/04/youre-worrying-wrong-bees/)

<comment><USER4> Like, the ones that pollinate every crop?

<comment><USER3> Yea. I'm not sure what's gonna happen to wild flowers/vegetation after the wild bees die out though :(</comment></comment></comment></comment>


My first company was just Acquired  (Verelo.com) - <AUTHOR> http://dyn.com/dyn-acquires-website-monitoring-startup-verelo/

<comment><AUTHOR> Is the second one going to be harder?</comment>


Ask HN: "Do's" and "don'ts" for tech recruiters? - <AUTHOR> I am thinking about a more empathetic, non-odious approach to tech recruiting.  For example, subverting the principal-agent problem by hiring empathetic people who are easy to talk to, at a salary, rather than putting on commission.  And to this general end I am soliciting everybody's feedback on demeanor.
What do recruiters do that you like?
What do recruiters do that you hate?
Feedback in this format would be great:
Do:
* Tell me salary figure upfront
* Tell me the name of the company
Don't:
* Stop communicating with me once you realize I'm not a good fit <comment><USER2> Do:

Tell me details about the company, like its name, where it's based and what kind of things I'll be working on.

Provide a salary figure for the role

Give feedback on things like interviews done with the company, assuming they tell those things to you. Obviously it's better to have the hiring manager respond, but to get a message from the recruiter saying either they said the interview went well because of this and that or they're looking for someone else right now is useful.

Keep your job descriptions realistic. If there's a huge laundry list of keywords for skills your applicant 'needs' to know, don't be surprised if most people are hesitant when they reply to your email.

Don't:

Provide irrelevant job offers and leads. Seriously, sending a JavaScript programmer Java related offers is a waste of time, as is sending through roles where 90% of the skills required are ones that candidate doesn't have. If someone is a PHP or Python developer, then sending them .NET roles may not be the best idea.

Try and 'encourage' applicants to sign up for training through your company. Seen quite a few 'recruiters' who were seemingly only contacting people to sell them courses, and it's an annoying waste of time.

Force people to sign up with your inhouse system to receive new jobs. We get it, job sites are a difficult thing to market. But saying you have a role and then only having said role available on another site is a hassle.

Have people come to your office for an interview. You are not a company offering jobs, and for most people don't want to spend money and time travelling to your office for nothing more than a quick chat. Especially if said office is really out of the way.

</comment><comment><USER3> "Don't lie to me" would be a good start.

\- Don't place a job ad for a job that doesn't exist.

\- Don't use my references as a way to call my former managers to ask if they are looking to hire. I had a recruiter call my references "to check my references" and then segway into asking if they were hiring - when I'm not even looking for a job. I was burned once and I will never give out references to a recruiter, just to the hiring manager.

\- Don't call me from hundreds of miles away to talk to me about a position you know nothing about.

\- Don't say you are working with a company that you aren't.

\- Don't tell me our goals are aligned "because if I get you a higher salary, I make more in commission".

\- Please don't call me if your English is so poor that I can't understand you.

There are good recruiters (I've worked with them) so it is possible to act decently and still stay in business. [1]

[1] John Spencer at Connected Systems Partners is a guy you might ask about "doing it right"

<comment><AUTHOR> Sounds like an open recruitment code of conduct might be in order, with some evidence that it is adhered-to (like maybe a reward for reporting violators).

Can you expound upon this point please?

>\- Don't call me from hundreds of miles away to talk to me about a position you know nothing about.

Shall reach out to John Spencer.

<comment><USER3> I once had a recruiter from Texas call me about a position local to me (I'm in New England) who couldn't tell me much of anything about the position. "They didn't tell me" is what he said, referring to his employers. The same day, a "good" recruiter I'd worked with in the past, called me about the same position. "I wish you had called earlier" I told him.

The knows-nothing recruiter had already set me up with a phone screen interview for later that day. When the "good" recruiter learned that the knows-nothing recruiter hadn't been able to prepare me for the interview, _he told me all about the position and the manager_ , preparing me for my upcoming phone screen. Yes, he tried to help me get a job that, not only wouldn't have earned him a commission, I would have been competing with his own candidates.

My impression is that recruiters in my area, work with companies in my area. My experience with recruiters calling from thousands of miles away, was that they didn't seem to have a knowledge of local companies.

</comment></comment></comment><comment><USER4> Hiding the name of the company and what they do is my biggest annoyance. Yes, I really care about that. More than their tech stack, and way more than a buzzword soup that poorly describes their tech stack.

Second biggest annoyance is keyword matching me and hundreds of other people and spamming us all, because so many times there isn't even close to a good fit other than your client uses java and I have some Android experience. Most of these people then make me feel like I'm a high pressure sales target, and in many ways I know I am so it's more understandable. But I'm not likely to want to work with you.

The best recruiters I've ever worked with make me feel like I'm the customer and they're doing me a service. Finding good opportunities can be hard, and I probably don't know the market as well as you do. Those recruiters don't outwardly care if I'm not interested in a particular role they thought was a good fit. They say that's ok, what don't you like? What should I look for when I send you opportunities?

</comment><comment><USER5> Just to underscore: Definitely have the comp details + company info included in the _very first contact_ with a potential candidate. Don't make me ask for it, and especially don't try to hide it until I've gone through an interview/phone screen/coffee at your office/whatever.

Don't spam me with jobs that I couldn't possibly be interested in. For instance, I work almost exclusively with open source technologies. There is no world in which I'd be interested in building .NET applications for some soulless corporation, not attending conferences, etc. Also, because this comes up frequently: don't spam people with javascript experience with java positions.

<comment><USER6> I discuss the compensation range before the interview process begins (i.e. their resume preparation) only with candidates responding with interest to my initial contact. I make a leap in faith by sharing the company/job details in the first contact, and having been screwed over by doing this, I feel it's fair to hold off at presenting compensation details to literally every person I contact. After all of my hard work, all they need to do is take one second and respond with "looks interesting, but could they match or exceed $XYZ range?"

If they're interested and have not brought up numbers, I'll ask them to provide their expectations first and I appreciate when they do. If they don't, I'm happy to give them a broad range to see if they're at least in the same ballpark.

As an agency recruiter, I serve the employer. If I tell everyone that a job will pay $150K - $200K, far too many people will respond with "yeah, my expectation is around $200K." It's not fair to the CTO/VP Engineering.

I don't believe there's a right answer, but I'm trying to find that middle ground that serves everyone best.

I would be curious to hear what HN users think.

</comment></comment><comment><USER7> Don't:

* Try to lure me to your office "for coffee" in exchange for the name of the company you represent (why would I waste my time drinking coffee at your office?)

<comment><USER8> Real estate agents and recruiters both seem to think everyone works like them: on pointless phone calls and meetings all day chatting and what not. Then they get shocked when you don't have time to speak to them during the work day.

<comment><USER9> Consider that their roles are driven by relationships, spending time networking and building new relationships, and what you see as pointless is core to their role.

When my recruiter, who landed me a very well paying job out of the blue, calls me and asks if we can get lunch, I make sure I'm free for whenever she's free. "When's convenient? Your pick."

Soft skills are usually more important to get and keep a job vs technical competency, except in rare microcosms.

<comment><USER8> I didn't indicate I don't understand their role. They don't understand mine. They seem surprised and offended when I'm short with them and say I can't talk right now when they call me in the middle of the business day to "just chat" about some property I hit "inquire" on (and expect me to remember their specific listing). They lack empathy and that's why so many are poor salespeople.

</comment></comment></comment></comment><comment><USER10> I love what your proposing and hate to be the voice of dissent, but I suspect that you will (quite ironically) have a hiring problem. The best, most knowledgeable, most empathetic, rock star recruiters will be able to make MUCH more money on commission. You'll be stuck with the second tier: recruiters willing to settle for a salary. Do you have a strategy to overcome this limitation?

<comment><AUTHOR> A little bit more detail, I think that the top of funnel needs to be engineers doing extremely intelligent, programmatic searches - aided by low cost virtual assistants to do some tedious human level filtering where required by law.

High likely match candidates are then sent to the recruiter along with the engineer's notes as to why the candidate is a good fit, from a technical perspective.

The recruiter then leads a team of customer success personnel whose jobs are to transparently communicate with the candidate and guide them along the funnel in a high EQ way.

</comment></comment><comment><USER11> Do: * Let me know what you see as 'next steps' based on my current position. This establishes that you've looked at my background and have at least a general understanding of what my current job title means. It may also show you haven't and are likely wasting my time.

Don't: * Ask my current and expected salary requirements

<comment><USER12> Why wouldn't you tell a recruiter your expected salary requirements? The best part of going through a recruiter is that it's hard to find out salary up front when you're interviewing. Them knowing my minimum acceptable salary keeps both of us from wasting our time.

<comment><USER5> Recruiters are hired by the companies trying to fill positions. The company's interest is to fill the position with as low of a salary as the market will tolerate, which is direct opposition to my interest, which is getting the highest salary that the market will tolerate. That mostly only applies if the recruiter is approaching me.

If I'm approaching a recruiter, it's extremely likely that I'd at least be willing to give them a minimum salary. I've never done this though - it's always been random recruiters spamming me on LinkedIn.

<comment><USER12> Most recruiters are agency recruiters. They get paid a commission based on your first year's salary - usually around 20% and if you don't stay at company at least 3-6 months depending on the contract they sign with the employer, they don't get paid. They are theoretically interested in getting you the highest salary possible.[1]

Regardless, if you tell them your minimum salary and they know the hiring company won't possibly reach that salary, they won't waste the company's time.

[1] theoretically when someone is paid on a commission based on you getting the highest price, the incentives should be aligned, but studies show that in reality it doesn't work like that ([https://www.nytimes.com/2005/02/20/business/yourmoney/why-a-...](https://www.nytimes.com/2005/02/20/business/yourmoney/why- a-real-estate-agent-may-skip-the-extra-mile.html))

<comment><USER5> If you tell them your minimum salary, and it's below what the company would pay, you've shot yourself in the foot.

<comment><USER12> I know my market value. I talk to enough recruiters, former coworkers, etc. I doubt very seriously that the amount that I'm asking for is appreciably below market value. If so, it won't stay that way for long -- I'm fairly aggressive about job hopping to maximize salary.

</comment></comment></comment></comment></comment></comment><comment><USER13> Do:

* Try to have job descriptions that make a little bit of sense. A lot of times it's just a dumb collection of somewhat related programming keywords, which just makes me cringe.

Don't:

* Don't tell me my rate should be fine, and waste my and company's time by proceeding to interview process, if my rate is way more than what the company can actually afford to pay.

* Don't mass spam people with job postings, because most of them time they are a bad match. E.g. don't send ASP.net position to an iOS developer.

I know this is a lot to ask, because recruiters are busy, and would rather send the same message to 10,000 developer than go through each profile individually and pick only the ones that really match the criteria for the job. I'm just pretty tired of receiving all the recriter spam about developer jobs that don't match my interests at all.

</comment><comment><USER14> Don't: * Say you're working for a real company, solving real problems for real world users.

uhh, no shit? haha.

</comment><comment><USER15> Everyone's answers are reasonable and total obvious, yet that is not what happens in practice. The reason why is the way the recruitment industry works is completely broken. For any solution to work you need to change the incentive system for recruiters from spray-and-pray to targeted. It is a very hard problem and I don't think anyone has solved it.

</comment><comment><USER16> Do know what kind of things are required for the job, what technologies (actual names of stack, not concepts) the candidate would work on. If asked, let the candidate talk to the hiring manager of the team to see if they're a good fit. (this is usually done last, but I find it to be one of the most important parts)

</comment><comment><USER17> Do:

* Admit when you can't speak geek, and explain your own personal work background where it's relevant to the skills you're scouting for.

Don't:

* Hype candidates up and stroke their egos a lot, by getting them to as many interviews as they can as soon as possible. As you mostly throw them at companies who are only speculating.

</comment><comment><USER18> Play the long game. Build relationships that span years and begin years before a candidate is actively looking for a new role. Don't be transactional. Bring an executive recruiting mindset to tech ICs.

</comment><comment><USER19> Your listed Do's are great, and I'll add the following:

Do: \- Read my profile and make it clear in your email or message why you think the position is a good fit (referencing details from my profile)

\- Be personable and real with me. The more I feel like a random number to you, the less I'm likely to respond. I'm simply too busy for low-quality inquiries.

Don't: \- Require salary verification at any point in the process. These days it's offensive.

\- Blast out inquiries to anyone who has a keyword in their profile

\- Be uniformed about how and why I might be a tremendous fit.

\- Bullshit me

</comment><comment><USER20> Do while foreach try catch explode array_push, but always boring for loops at end. Throw exceptions.\n Don't read my echo.</comment>