Sunshine Helps Kill Germs Indoors - <AUTHOR> https://www.npr.org/sections/health-shots/2018/10/18/658335490/grandma-was-right-sunshine-helps-kill-germs-indoors <comment><USER2> In a similar vein, you can get even porous dishware remarkably clean by scrubbing them out with salt and letting them bake in direct light for a while.

This works reasonably welly while car-camping or situations where doing dishes is annoying, or water is scarce but sunlight's plentiful.

direct sunlight for baking off mold and mildew and bleaching whites are other old but effective tricks.

<comment><USER3> People used wash their dishes with the ash from the stove. It acts both as an abrasive, and an absorbent.

<comment><USER4> Soap was traditionally made from the ashes of hardwoods combined with rain water (higher nitrogen content).

[https://www.wikihow.com/Make-Ash-Soap](https://www.wikihow.com/Make-Ash-Soap)

</comment></comment></comment><comment><USER5> GDPR/tracking bypass: [https://text.npr.org/s.php?sId=658335490](https://text.npr.org/s.php?sId=658335490)

</comment><comment><USER6> I wonder why drying clothes in Sunlight is avoided in western countries. Even in Summer, i don't see people hanging clothes outside in US. While this is the norm in Asia.

<comment><USER7> Well it depends on what part of the "West" you mean. Lots of people still hang clothes out to dry in Italy, France, Germany, Spain, etc.

In the USA, we don't hang clothes out because we changed our cultural norms with the introduction of convenience machines. Once air conditioning became affordable, we all bought it. Same for refrigerators, dish washers, garbage disposals, washing machines, and of course dryers. Having a machine to do your work for you was seen as a middle-class status symbol, in addition to relieving housework.

Once line-drying became passé, people began to dislike the sight of line-dried clothes (it reminded them of being lower-class) and so was now "unsightly". Neighborhood association bylaws were passed to ban line-drying completely, and many apartment buildings also banned the practice. So now around 80% of homes in the USA have a washer and dryer, and people in apartments use laundromats or apartment facilities.

This article from the BBC mentions the millions of U.S. homeowners who were banned from using clotheslines: [https://www.bbc.com/news/magazine-11417677](https://www.bbc.com/news/magazine-11417677)

<comment><USER8> > Why would you line-dry your clothes if you have the convenience of a dryer?

Some advantages:

1\. Clothes last longer with less dryer agitation

2\. Less agitation means less lint

3\. Lower carbon emissions and gas/electric bills

I have a gas clothes dryer at home but I hang dry my clothes year round.

In the summer I have a line, more delicate and fade-senstitive items get hung in the shade while towels, sheets, undershirts, socks and underwear can go in the sun. If you hang them in the morning or evening when light is less intense, or bring them in as soon as they dry during sunnier hours, there's very little risk of fading in my experience. The most delicate items are hung inside on a drying rack.

In the winter or rainy periods I have a folding indoor drying rack that I hang clothes on. It takes longer but still works. During furnace weather I can leave them in front of a vent and the dry furnace air gets some humidity as well.

Some tips if you haven't hang dried before:

You may notice your clothes are stiff after air drying. Depending on your water hardness you may be using too much soap (most detergents recommend too much). Try using less, or add plain white vinegar in the fabric softener dispenser (no commercial softener)

Vinegar will soften the water, remove soap buildup from the washer and clothes, and leaves fabric soft without any other artificial softeners.

<comment><USER9> The sun will ruin clothes much faster than a properly configured dryer

<comment><USER8> YMMV - it may be different closer to the equator, but in the great lakes I don't have an issue. The brightest colors and most delicate fabrics are hung inside or in shade. With a medium washer spin speed there's very little wear on the clothes.

In contrast, my experience with the dryer is clothes and up looking threadbare and worn from a high heat dryer. Just look at how quickly the lint trap fills up.

<comment><USER9> I've found most wear on clothes comes from people who only used timed washes on high heat

I wash my clothes and dry them according to type with automatic settings which end the cycle early if the clothes are dry before the full cycle is complete

On the flip side when I lived in a place where dying clothes outside was the norm there was no avoiding sun bleached clothes unless you dryer your clothes at night (which only partially worked because it was a tropical climate)

</comment></comment></comment></comment></comment></comment><comment><USER10> So the statement "sunlight is the best disinfectant"[1] is indeed true, both literally and metaphorically.

[1] [https://en.wiktionary.org/wiki/sunlight_is_the_best_disinfec...](https://en.wiktionary.org/wiki/sunlight_is_the_best_disinfectant)

</comment><comment><USER11> We use a steam-cleaning device (looks like a small vacuum cleaner) at home and I swear we get sick less often if we use it regularly. It supposedly kills over 99% of all kinds of pathogens. Not sure if it creates resistant strains, but I guess such high temperatures are difficult to adapt to.

<comment><USER12> Killing 99% of everything is not very good if you have young children. It can lead to allergies, if their immune system can't train on harmless bacteria.

<comment><USER13> That's nothing but a hypothesis. It might very well be the case but it isn't proven at all. So stop spreading it as if it were fact.

So sick of bullshitism on the Internet.

<comment><USER14> Surely bullshit is something that's clearly false?

<comment><USER13> Implying that the hygiene hypothesis is a fact __is __clearly false.

</comment></comment></comment></comment></comment><comment><USER15> In Eastern Europe pillows, bedsheets and blankets are put on the windowsill every morning for airing. It is also a customary thing to keep windows open for a couple of hours at least, every day. I was surprised that is not the norm in the US for example. It's the AC that is always blasting instead

<comment><USER16> It's very hot in the US. Today at 2pm the temperature where I live will be around 29 degrees celcius. I googled ukraine's weather right now and it's 14C over there.

<comment><USER17> I thought you were going to say 35 degrees(Arizona, Nevada, Texas?) but you said 29? Where I am from that's a nice to normal day.

<comment><USER16> I live in louisiana, it's actually really nice today compared to most days since we're in that nice 3 days of fall season. I was just giving an example of why AC is always blasting here. Your comment backs up my point that it's HOT in the USA

<comment><USER18> Not going to argue with you about using AC in Louisiana. I think a lot of people just don't understand how fucking hot and unpleasant it gets in the southern states during summer.

<comment><USER19> If it was just heat, it wouldn't be as bad. But a good chunk of the "South" in the US is swampland. And that means 95-100% humidity.

That means that when you sweat, it doesn't evaporate. And it doesnt make you cooler. And the sweat then warms up to the air/body temperature, and further blankets you in hot... And you sweat more.

Some scarier numbers, mammals die without shelter in around 8 hours if the temp is 35°C (95 °F) in saturated (100% humidity) air.

</comment></comment></comment></comment></comment></comment><comment><USER20> There have been quite a number of recent studies into the use of light for medical/health purposes -- for example, using blue light for its antimicrobial effects[0], or various wavelengths of light for other healing effects[1,2]. Use of LED light for this purpose is often covered by insurance and has been developed & used by NASA[3].

Anecdotally, a family member of mine has one of those "led light therapy" systems[4]. Initially he was going to a local clinic to use one and ended up buying one of the packages for himself. I have seen person after person experience shockingly beneficial effects from using them (like people are saying "this is the first time I've slept without pain medication in years". From putting a pad covered in bright LEDs on them for 40 minutes. People are so skeptical, then suddenly their chronic pain issue is mitigated by simply sitting there.

0: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3438385/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3438385/) 1: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4126803/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4126803/) 2: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3799034/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3799034/) 3: [https://www.nasa.gov/topics/nasalife/features/heals.html](https://www.nasa.gov/topics/nasalife/features/heals.html) 4: [https://www.balancedlivingllc.com/light- therapy.html](https://www.balancedlivingllc.com/light-therapy.html)

<comment><USER21> Careful with the blue light, it can be toxic to the retina. Tilt towards warmer spectrum whenever possible.

[https://journals.plos.org/plosone/article?id=10.1371/journal...](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0194218)

<comment><USER20> Yeah, that's right. Normally you use the infrared, but the blue are still included and the instructions usually specify exactly how to use those properly/safely :)

</comment></comment></comment><comment><USER22> I wonder if the high-E glass used in new construction affects this.

<comment><USER23> I think you mean "Low-E", for low-emissivity. But your question stands.

</comment></comment><comment><USER24> Does anyone have a recommendation for a commercial product that can disinfect a room with UV? Something like a more scaled down version of what is used in hospitals. I'd use it at home, and when staying in a hotel room.

<comment><USER25> A UVC lamp will work very well for that, just make sure nothing you want to remain alive is in the same room when it's on, because the UV is just as effective at killing _your_ cells as it is bacteria.

[https://en.wikipedia.org/wiki/Germicidal_lamp](https://en.wikipedia.org/wiki/Germicidal_lamp)

<comment><USER26> There goes my idea of a room sized tanning booth :)

</comment></comment></comment><comment><USER27> Read that a few months ago. I let some fruits out in the open, they stayed 'mint' for weeks. While in my house, after one week I'd see rot starting and mold showing its head.

<comment><USER28> Could also be temperature and humidity etc.

<comment><USER27> Could be but I don't think it was the case. Unless it a very sensitive, there wasn't a lot of difference, it was summer, house was open, low humidity if at all.

<comment><USER29> Still, objects in sunlight are significantly hotter than air temperature, and molds have pretty strong requirements for developing, temperature wise.

</comment></comment></comment></comment><comment><USER30> From what I've heard in China UV boxes for dishes sterilization are more popular than dishwashers.

<comment><USER31> Now I wonder why dishwashers don't have UV light in their washing cycle. _runs to patent office_

<comment><USER32> [https://gizmodo.com/5995220/this-ultraviolet-lamp-keeps- your...](https://gizmodo.com/5995220/this-ultraviolet-lamp-keeps-your- dishwasher-clean-no-matter-how-dirty-the-dishes)

</comment></comment></comment><comment><USER33> I once dried something outside. It ended up being in half shade half sun. When I checked on it a couple hours later, there was a distinct fading line where the sun/shade line had travelled. The sun side was completely faded.

</comment><comment><USER34> this explains a lot :D we have an old saying in Turkish;

"A home where the sun do not visit, gets a doctor's visit"

</comment><comment><USER35> Data protection cookies? What are these?

</comment><comment><USER36> Next you're going to tell me drafty windows will give me a cold.

</comment><comment><USER37> c.f: the concept of prana; and the belief that you can sustain yourself on sunshine alone

<comment><USER38> People starved themselves to death believing a version of that.

<comment><USER39> It seems counterintuitive to believe that a thing you evolved not to do is a thing you can do.

It'd be like training yourself to breathe underwater like a fish.

Or training yourself to molt like a snake.

You're simply not designed with the right hardware for the task, not matter how much "practice" you get. Amazing how people can convince themselves otherwise.

<comment><USER37> you didn't evolve "to do" anything. that's teleology.

<comment><USER39> I mentioned things we evolved _not_ to do, which obviously wouldn't fly in a biology paper, but perhaps gets across "things we lack the evolution-provided hardware to do".</comment></comment></comment></comment></comment>


Ask HN: Recommended platform for small discussion lists? - <AUTHOR> I could readily start a Yahoo Group for this, but I suspect that would flop in tech circles. What options are currently available that would not have techies turning their nose up at it?<p>Thanks. <comment><USER2> Google groups.

<comment><AUTHOR> Thanks: [https://news.ycombinator.com/item?id=12573081](https://news.ycombinator.com/item?id=12573081)</comment></comment>


I don't understand the 9-to-5 - <AUTHOR> http://blog.phpdeveloper.org/?p=332 <comment><USER2> I'm really surprised by this mentality, especially evident in the comments, that if you're not spending all of your time outside of work doing projects related to development that you're suddenly a "bad developer." Others have said it but it really bears repeating: at some point even the best developers realize that finishing one extra feature on a side project isn't as important as spending some quality time with your spouse our children.

Moreover, I don't want to be in a situation where my job owns my life. I enjoy software development and I've been doing it now for 14 years. I certainly spend some of my time at home tinkering on personal projects and continuing to learn. But work for me is generally 9-5ish--and by work I mean the job for which I'm paid. Speaking as someone who will be a father in just a couple of weeks, I can say that at 8:00 pm I'd far rather be putting my son in bed than working on anything related to work.

Life is short, and there's more to it than software development. Understanding that doesn't mean you lack passion or aren't good at it--it just means you believe in going beyond one-dimensional.

<comment><USER3> I think you're taking things a bit farther (though I haven't read _all_ the comments).

Chris is referring to the people that treat it as a job, and nothing more. They don't advance their knowledge outside of work. He isn't _just_ talking about work. He's talking about tinkering with code, working on fun projects, etc.

He isn't suggesting that you should program all the time. Rather, it's the people that treat it merely as a job. This isn't something unique to programming.

That all being said, I think when you understand it's not unique to programming, you finally understand it: these people aren't doing something they are passionate about. They are there for the paycheck.

<comment><USER2> I think it's fair to say that people exist in all fields of work that don't enjoy the work they do. I feel bad for them; but there's a (false) generalization being made that just because you don't spend your time outside of work doing it means you're not passionate (or, to take the generalization further as was done several times in the comments, a "bad programmer").

I spend 8+ hours per day sitting at my desk at work slinging code. I love my job; I learn a ton while I'm here and I believe I'm helping in building great software. My skills improve daily during my time at the office and most days, when I get home, I'd rather do just about anything than sit at my desk at home doing exactly what I've been doing the past 8+ hours.

<comment><USER3> I think the generalization is fair. Their are always exceptions, but overall, the generalization is spot on. You might be one of those exceptions.

At the same time, I also think we are taking 9-5 to literally. He isn't talking about 9-5 exactly (otherwise, anyone working from 8-4 is safe!). Rather, it's the people that treat the job like a 9-5 job, and that's it. They go to work, do the job, and go home. They don't try to learn, they don't try to advance themselves.

You don't do this, so even though you might work between 9-5, you aren't _just_ a 9-5 coder.

</comment></comment></comment></comment><comment><USER4> Health.

If I program 9-5, go home, eat, program more, program some more, and then go to sleep, I get fat. Fast. My social anxiety mounts. Fast.

I need at least 1-1.5 hours a day of gym time, .5-1 hours cooking time, some social time squeezed in there somewhere. I _do_ have side projects - but I don't have kids, and I don't have another hobby - what if I enjoyed woodworking, painting, writing, or music? Devote a decent amount of time to that, to your health, and to a 9-5 job, and squeezing a meaningful programming project in there starts to get difficult.

<comment><USER5> I'm with you on this. I've taken to seeing everything as "stages". Instead of trying to fit my music, writing, or x hobby in I assume to undertake it as fulltime project in segments over the years.

Two years ago, I stopped working, lived off of savings and pursued my self- education and personal projects for nine months free from the distractions of "work". I go on and off with these phases.

<comment><USER6> I'd be interested to know more details as to how you were able to accomplish this. Specifically:

How long did it take you save up enough?

How frugally did you have to live to stretch your savings for 9 months?

Does your geographic location have a high cost-of-living?

What were you able to accomplish in 9 months' time?

Did you have to quit your job or were you able to convince your employer to take an unpaid leave of absence?

If you quit, how hard was it to get a new job?

Do you like this new job better?

<comment><USER5> I did it on the spot within a matter of three weeks. I had already saved up enough to support my lifestyle at the time for three months plus I have a consistent source of passive income.

My lifestyle was extremely frugal. I never ate out, only bought the food that I needed, no TV, layered up instead of turning on the heat, didn't buy anything I didn't need, etc...

At the time, I was living in Las Vegas - cost of living wasn't too bad. For a time I considered living out of a tent (urban camping) but decided that my budget was capable of supporting me without resorting to that. (it is much easier to maintain a structured self-education and side-project routine when you live in an apartment vs. a tent!)

In nine months I completed a book on college level rhetoric, a college level course on philosophy and reasoning, re-taught myself how to perform arithmetic on fractions (my weakest point in math), algebra 1, geometry, and half way into algebra 2; I studied a few classics too: Aristotle, Ovid, and Emerson. I was a core committer for a popular open-source project, put a lot of time into that; I also finished two of my personal projects/ideas. The projects were academic interests and at the time I didn't really have the knowledge nor network to monetize them, so they've just gone into the personal history book as "experience".

Once I was done with my nine month stint, I moved to San Diego (from Las Vegas) and began doing contract work under my own sole-proprietorship for about six months. After that I co-founded a startup (8 months ago) which is now paying my salary entirely and very close to profitability.

I like this new job much better :) I got the idea to pursue nine-months of structured personal focus from the dissatisfaction I was experiencing with the "work for someone else" thang.

</comment></comment></comment></comment><comment><USER7> The article says he doesn't understand how someone can code at their job, then not code when they go home.

Here's how: even if you are very excited about programming, you can realize that there are other things in the world besides being a workaholic perfectionist who stares at a computer screen 16 hours a day. Things like spending time with your significant other, enjoying nature, exercising, concerts, volunteering, etc. I love coding and trying to improve, but have you ever just got tired of looking at a computer screen?

<comment><USER8> I agree with you Larry. I do like to enjoy life as well. There are the type of people who are so passionate about their work that they would love to stare at a computer screen 16 hours a day. When I was younger, I had the time to read, grow and get better at my work. Nowadays, I have a fiance and a marriage to plan so hence I have MUCH less time to learn outside the job. However, I still try to sneak in as much as I can in my outside work hours ;)

<comment><USER9> same here - in my early days I was more interested in screwing around than I was working, but as I get older I find that I'd rather work than do anything else.

Call me a workaholic, bad father, bad husband, but it is what it is.

</comment></comment></comment><comment><USER10> Dude, you can make the same statement about anything in life that fires you up. Take cooking, millions of people go home and put a frozen meal in the microwave, some cook indifferently the same stuff over and over, and some are totally into their cooking.

I am sure there's a person somewhere putting together an awesome meal with fresh ingredients thinking "How can people eat spaghetti with sauce from a jar every night".

Embrace your passions, but don't be surprised if others don't share them.

And if you want to understand how others feel, think of all the things you do in a day that don't bring you a driving urge for self-improvement.

<comment><USER11> Agreed. There are things you _love_ and then things you do. Hopefully you can find something that lets you do both, but a lot of people don't.

</comment></comment><comment><USER12> I don't understand 9-5 either, why start so late? I do 7:30 to 4, and get out in time to go surfing, sailing, or skiing depending on the season. Or maybe just hang out on the beach with my girlfriend. Or maybe BBQ with some friends. Or get a nice book at the library. Or hop online and play Starcraft. Or watch a good movie. Or maybe, spend some time working on my sideproject or programming in general.

Work to live. Don't live to work.

<comment><USER13> > I don't understand 9-5 either, why start so late? I do 7:30 to 4, and get > out in time to...

Woah there Mr. Personal Responsibility Man[1]! Clearly the reasonable solution is to capaciously adjust our definition of what time it is twice a year so that we can have "more daylight".

[1] Or woman, of course. Curse our lack of fully developed gender neutral language. (Ohh, sure, Person, but what about the Mr. bit? Bah.)

</comment></comment><comment><USER14> The article talks about two types of programmers. The passionate type and the type that programs because it's a way to make money to fund life outside of work. Then it points out that many of the latter type write poor code.

I've found that if you engage your non-passionate co-workers and try to educate and inspire, you can really help them improve their skills. Nobody wants to be bad at what they do. A guiding hand can do wonders.

It makes their life better and it makes your life better.

</comment><comment><USER15> I find that I cannot write code at top quality for more than about 6 hours a day. IMHO, most programmers aren't able to write at their top skill level for more than that, but don't realize this about themselves.

Factoring in time to handle my mails, some meetings, and that 6 hours adds up to a working day. If I program private projects after hours, I get grumpier and less focused. For my own health and sense of accomplishment, I need to stop coding at the end of the working day.

I don't switch off entirely. I do read tech books during my evenings, but that's a non-creative activity, so my coding doesn't suffer from it.

</comment><comment><USER16> Why is this on HN? It's clearly written by some kid who hasn't yet realized that there are people who think differently than he does.

He also probably doesn't have a family, a house, or other responsibilities. There are only so many hours in a day and once you have all of those things, you can't spend every waking minute working on code -- if you want to or not.

</comment><comment><USER17> Don't take this the wrong way; but a potential short answer is that there is more to life than programming. Or doing a single thing non-stop, for that matter regardless how passionate your are about it. Taking your mind off of it is not necessarily a bad thing - in fact, it might help you acquire a different perspective which ultimately might assist you in becoming a better problem solver in the long run. Also, "those" people might have different, additional and probably more important obligations such as family or children. Yet some others (as pointed above) might have hobbies which require some time investment.

</comment><comment><USER18> As well as the other valid points, I think he is looking at it bass ackwards.

The two types of programmer do the job for different reasons and came to the job for different reasons.

There are the types like me and presumably him, who are into that sort of thing and enjoy it. When it came to finding a way to pay the bills it makes sense to do what we enjoy and get paid for that, especially at times when the economy offers us good rates for our hobby. We'd program even if there was no money in it (though we'd probably chose to work on very different projects!)

The other type come into programming because they need a job to earn the money to maintain the lifestyle they want, and programming jobs pay far better than many others that are readily available. So those with the ability to learn at least the basics do so and try make their way. It isn't their hobby. It just pays the bills. They want to go home and do other things at the end of the day/week.

Sometimes the second type of programmer will catch the bug and become the first. Sometimes the first becomes completely dissolutioned and becomes the second. Or they can go half way: works 9-5 on work projects then goes home and does something completely unrelated but still programming, like being a C#+MSSQL developer 9-5 and a Linux+Python+Other person in their own time - this can be quite useful for developing new experience that will help you move away from the area you are dissolutioned by.

</comment><comment><USER19> Another big variable in all of this is just the natural variability of time. There are times when I have side projects that I'm totally engaged with and passionate about, and times where the same projects don't hold my interest as much as other things in my life, and times when I just don't have any side projects at all. Just because you're not developing on the side _now_ doesn't mean that you _never_ do or _never_ would.

Also, I find that it's hard to serve two masters. When I _do_ have a side project I'm engaged in, it tends to bleed off any enthusiasm I have for doing paid work where, by definition, I have only so much say in things. It could be that the developers not developing at home are the _better_ ones for being smart enough to save themselves for the big game, as it where.

As developers, we also have to be careful about having too much of this attitude in ourselves, because it makes us, in many ways, rife for exploitation by people who _expect_ us to be so passionate about our jobs we'd do them 12 hours a day if we could.

</comment><comment><USER20> What's disappointing is the 9 - 5 job that doesn't teach your anything nor provide much time or ability to learn it on your own. That actively discourages on-the-job self-development and innovation. And yes, they exist. A lot of "grow our employees" language is, when the rubber meets the road, hogwash.

I don't advocate endless additional work off-hours, unless you are really into it. And in the latter case, I'd suggest it be for your own, personal benefit and not simply to make you better at your job. Unless it's a job you love and you otherwise have what you need.

But, when the job's a dead end in terms of personal growth, you're going to have to invest in off hours (self) development. Or be prepared to: 1) Move to management, if you can get on that career track (given the precondition, not a good sign with respect to the quality of your organization, BTW); 2) Stay in a very protected niche; 3) Face the end of your career before too long.

</comment><comment><USER21> Well, if you spend all your time programming, then when would you have the time to learn design & composition, color matching, copywriting, blogging, customer relations, viral architecture, business modeling, customer development, investment tactics and everything else you need to know to build a great product?

</comment><comment><USER22> I don't understand it either, as in why don't most people have any concept of time-off? I guess many Americans depend on 100% of their salary to pay their bills and so can't afford to take any unpaid leave. But why not take sabbaticals if even for coding something interesting to yourself?

</comment><comment><USER23> I'm kind of halfway inbetween. I like to code several hours a day. Often I don't get to do that at work, since there is more to writing software than programming. When that happens I code on side-projects, or not really side- projects so much as recreational coding.

For example, the other day I wrote several implementations of the burrows- wheeler transform, just because it's neat and there is a non-obvious way take the simple N^2logN algorithm and turn it into a more inscrutable linear-time algorithm.

</comment><comment><USER24> Collaboration.

It's really that simple. We live in cities and work in groups and/or at companies because the benefits of collaboration and casual exchanges of ideas outweigh the detractions.

</comment><comment><USER25> Once you discover other programming languages -- like Python or Scheme -- you will understand why PHP is better kept as a 9-to-5 thing _at most_.

<comment><USER26> that was one of my first thoughts too. Self-righteousness is a bit hard to stomach when it's coming from PHP dev.

The world is a lot bigger than that - in and outside of programming.

</comment></comment><comment><USER27> This guy sounds like he would be astonishingly dull to talk to. Both on a personal level (he has no interests outside coding PHP) and on a technical level (he has no interests outside coding PHP).</comment>


Sequoia is sounding the alarm about the economy again as coronavirus spreads - <AUTHOR> https://www.cnbc.com/2020/03/05/sequoia-capital-alerts-companies-about-coronavirus-economic-fallout.html <comment><USER2> Darwin never "surmised" about adaptability. [https://quoteinvestigator.com/2014/05/04/adapt/](https://quoteinvestigator.com/2014/05/04/adapt/)</comment>


"Web Scale" - <AUTHOR> http://www.jacobian.org/writing/web-scale/

<comment><USER2> I agree with Zed Shaw here -- both "web scale" and your definition are not very good. "Web scale" is especially bad because it can mean anything and be used by anybody.

However, your definition doesn't really make sense either. Exactly what is being scaled here? Static web hits? Database lookups? Database writes? What characterizes your ability to scale? Sharding? Distributed processing or retrieval a la MapReduce? Instead of describing what you _think_ your architecture can handle, why not try describing exactly _what_ your architecture can handle. If someone is actually trying to convince me that their architecture is a good one I don't ever want to hear "web scale," I want to see graphs and hear means, medians, standard deviations, and confidence intervals.

</comment><comment><USER3> Reed's law follows from the fact that a set has 2^N possible subset. So it's a statement about how group membership affects the dynamics of a social network.

There are O(N^2) possible connections, which is related to Metcalfe's law.

<comment><USER2> Metcalfe's Law is trivially reducible from the number of edges in a complete graph.

</comment></comment><comment><USER4> Your web scale number is the Levenshtein distance between your company's operations and Google.

To me, "web scale" means "We can consume, store, organize, process, transform, and deliver information for the entire world." Web scale is planet scale information technology.</comment>


GitHub Report Card - <AUTHOR> https://githubreportcard.reflect.io/ <comment><USER2> I did this the other day when it was posted, been stuck on this message since:

> We're experiencing unusually high traffic so we'll email you when it's > complete.

Have yet to receive an email.

<comment><USER3> same here. anyone else?

</comment></comment><comment><USER4> This was just posted a couple days ago [https://news.ycombinator.com/item?id=13320579](https://news.ycombinator.com/item?id=13320579)</comment>


Venture capital is a hell of a drug - <AUTHOR> https://techcrunch.com/2016/09/16/venture-capital-is-a-hell-of-a-drug/ <comment><USER2> My own experience is that the big risk that I did not account for, as a founder without venture backing, is that you become ramen profitable and just sit there for a decade.

This is hugely destructive for the founder in question. If you don't have vc baking and you don't sell to a big name? Looking for a job after running a business with a gross of a few hundred thousand a year is just not the same as looking for a job after working for one of the big valley companies. I mean I exaggerate and say that employers treat me like I was unemployed, and it is not that bad, but compared to working for large companies with reputations for hiring good people, running an unfunded, ramen profitable company looks pretty bad on your resume.

I would argue that vc mitigates a lot of these risks. First, you have a name, a reputation to put on your reputation. Second, the bit about get big or get dead? In many cases, that is as good for the founder as for the vc. You are way less likely to end up starting your career over when the thing fails, both because of the reputation factor and because either you got big (which is good for the career even if the company gets dead before you can cash out) or you got dead fairly quickly, and have less time to explain away.

<comment><USER3> I think if you're so concerned about how you look on paper you should not be launching startups. Although some might argue that starting a startup has become a semi-established career path in itself, which I have mixed feelings about, and I suppose in that case it could be thought of in terms of typical career moves.

Also, a few hundred k/year in gross can get you a lot of very expensive ramen. That's probably more than most devs make at FB or Twitter.

<comment><USER2> My concern for how I look, as you say, on paper largely has to do with career options. If you find that shallow, that is your right, but personally, I think it is important to talk about the risks inherent in this sort of thing. This career downside is not one of the risks I anticipated when I went into this.

<comment><USER4> How were you handling sales, relationships building, market/MVP feedback, lead nurturing, and marketing in your business?

And what happened with your business? Were you left with no connections, relationships, and reputation of results to leverage to your next "thing" (I.e. new career path, consulting gigs, resume material)?

Even if your startup / bootstrapped / micro-enterprise failed, you got tired of it, or the market shifted, you don't get to a few hundred K in revenue in a solo/micro operation without having some results, reputation, and relationships to stand on when you walk away. At least not in any situation I can think of.

I don't know you, but I'm wondering if this is more about your perception being off about what's making this next step (i.e. interviews and selling yourself) challenging for you. If it is off, maybe you're overlooking something else that is really the root cause of it, preventing you from addressing it or even asking the right questions of yourself or the community.

<comment><USER2> >Even if your startup / bootstrapped / micro-enterprise failed, you got tired of it, or the market shifted, you don't get to a few hundred K in revenue in a solo/micro operation without having some results, reputation, and relationships to stand on when you walk away. At least not in any situation I can think of.

Sure, but that's the thing, reputation and relationships might get you an interview, but it won't get you a individual contributor job at a top-tier company. Why do I fail those interviews? Maybe I am not technically good enough. Maybe, as a friend says, "They can tell" \- they can see that I am depressed. Maybe it's a little bit of both.

My point is that you can show up to interviews at second or third tier companies (or contract gigs at first tier companies) and pretty much say "hey man, I've got hands, I can figure it out" and they hire you. And contacts and experience selling works great for that. But my experience has been that there is a ceiling on how far that takes you.

Contacts are important but they are not everything.

I'm actually fairly certain that a reasonable portion of my problem is that nobody cares about the problems I was working on, or rather, that the sysadmin role has shrunk a lot, and that's where my focus is. I need to redirect effort into SWE skills. (The path forward for me is probably SRE jobs, but the part of that I'm missing is the SWE stuff.)

That's another problem with working for a company you are majority shareholder of; the temptation is to do what you are good at and hire people who are better than you to do the things you aren't good at. When the industry moves, and the thing you are good at are no longer really in demand? well, you have a retraining problem, one you probably wouldn't have had if you had been working as an individual contributor during that time.

>I don't know you, but I'm wondering if this is more about your perception being off about what's making this next step (i.e. interviews and selling yourself) challenging for you. If it is off, maybe you're overlooking something else that is really the root cause of it, preventing you from addressing it or even asking the right questions of yourself or the community.

eh, that's possible. You could argue that my biggest problem right now is mentality. I was defeated, I _feel_ defeated. And now I'm back contracting, which pays way better than working for a small company, and better than any of the jobs my contacts offered me, but it doesn't feel like success for a bunch of reasons; The role itself looks like what I did when I was 17 (It pays a lot better than what I did when I was 17... but it's about the same work) and it is still 1/2 to 2/3rds total comp for direct hires at places like amazon and facebook.

That's the thing, if I want to work for startup wages, sure, I could get a lot of jobs. no problem. But that's not a step up from where I was before I started this company. Hell, if I wasn't depressed as fuck, I would probably have a shot at being a co-founder somewhere funded, which possibly could be a step up, but I _am_ depressed and exhausted and so that's not really an option right now.

I mean, as others have pointed out, I have it okay now. bills are getting paid, etc, etc, and why should I be unhappy about my current situation? Lots of people would be happy to have my job. I feel bad for feeling bad about it, you know?

but... my point that running a business (vs. working as an ambitious individual contributor) doesn't move your career forward as working as an ambitious individual contributor would, or at least that it hasn't moved _my_ career forward.

(And yes, I'm sorry for sounding so self-pitying and bitter. That's how I feel right now; it will pass. Either I will retrain and continue my upwards career path as an individual contributor, or I will become accustomed to, you know, that path not always leading upwards. Either way requires time.)

Re-reading this... I'm painting a pretty unsympathetic picture of myself. The fact that I've spent a lot of effort on non-technical things (that, turns out, I'm not so great at) rather than moving my technical skills forward almost certainly has a lot to do with me not being able to get technical jobs that are as good as I'd like. Shock! surprise! I mean, that seems pretty obvious, no? I took a risk. I thought I could become good at business. Turns out? it's harder than it looks, and progress in that field is way harder, for me, than progress as a technical individual contributor. Now, I'm complaining because that time away from the things I'm good at is now slowing down my career progress. I reached a little too hard for that brass ring, fell off and am now whining about my bloody nose.

I'm still arguing, though, that there are costs to your technical career to taking time to try to go into business.

</comment></comment></comment></comment></comment><comment><USER5> This all makes sense, if your only goal as a founder is to get rich.

I can only speak for myself, but to me, getting individually rich is not the goal. Having a quick exit isn't the goal.

The goal is to make a huge company that shifts the way people behave in a way that I think will make them better off and "build a world I want to live in."

The reality is, for big moonshot things (AI, Nano, Genetics, AR), you can't bootstrap them with revenues - you need a shitload of high risk money to build, grow & scale. That's what Venture money is for.

If you get venture money, make some waves and flame out or acquihire before the unicorn exit and see it as a loss, then I don't really know what you were working for. Think about it like a PhD on steroids - if you do it right, no matter the long term outcome you are making a dent in the market.

<comment><USER6> Many things that end up changing the world start out very small. Think about the Altair (hobbyist kit), Microsoft (dorm-room project), Linux (grad student project), Facebook (dorm-room project), Google (grad student project), Twitter (weekend project), the WWW (CERN project), penicillin (moldy petri dish), saccharin (unusually sweet bread), radioactivity (a cloudy day), etc.

Many other things that promise to be huge moonshots end up being huge fizzles instead. Think about AI the first time around, VR the first time around, pen computing the first time around, flying cars, supersonic transports, and of course the literal moonshot, which got us to the moon 6 times and then we never went back.

I'm sure many smart people will disagree with me on this, but when I see lots of money invested in a moonshot, I usually think "That's an awful lot of people who are about to spend years of their lives chasing an _image_ of what the future looks like rather than discovering what the actual future will look like."

<comment><USER5> None of these contradict my point though. You only mention where those started. They wouldn't be where they are today without outside investment. WWW, penicillin etc... are great examples of significant investment before there was a tangible way to afford growing and scaling distribution through revenue/bootstrapping.

It's hard for frontier technology projects (ML/AI, AR/VR, Genetics, Robotics etc...) to even get out of the lab without significant investment, as the personnel needed have so many lucrative options and they are generally done by older people with relatively high personal burn rates (kids, mortgage etc...).

 _chasing an image of what the future looks like rather than discovering what the actual future will look like_

That doesn't make sense. By definition you have to blaze a trail in new technology/markets - you don't chase an image. The image you have is the the world you build - and hopefully people respond.

<comment><USER6> The difference is in the feedback cycle. Innovations in the first category get released in a minimal form, exposed to real users, receive input from a variety of sources, and only then get capital to expand. Innovations in the second category are a "big idea", get lots of capital to build it out...and then very often, miss the mark when it comes to having a lasting effect on society, because without that feedback cycle, they don't fit into everyday life in a useful way.

It's not a matter of "hopefully people respond", except for the initial first draft (which, if you're smart, you'll make as simple and minimal as possible). It's a matter of testing things out and then observing what people _do_ respond to, then going down that path. Once you've validated the business model, you can take capital to bring it to more people, but taking capital itself does not help you identify that model any faster.

<comment><USER5> We're saying the same thing. I don't even reference the first example because those aren't really in the ballpark I'm talking about. Lean principles still apply to moonshots IMO.

</comment></comment></comment></comment></comment><comment><AUTHOR> The author talks about why founders should be more critical about taking venture capital, and how it polarizes the possible outcomes of the company.

I think Eric put together a strong piece that missed commentary from being published on Friday.

<comment><USER7> Totally agree—this is a well considered post that provides a counterbalance to the conventional wisdom.

<comment><USER8> Even more surprising... it's posted at TechCrunch

<comment><USER7> People crap on the "Crunch Network" quite a bit, but there are some real gems in there. Take "The Stack Fallacy," a solid post that might have gotten 20 hearts on Medium, but TC helped elevate the idea to the point that the WSJ picked up on it.

Granted, there's some dross in there, but like it or not, it's tech's paper of record.

[https://techcrunch.com/2016/01/18/why-big-companies-keep- fai...](https://techcrunch.com/2016/01/18/why-big-companies-keep-failing-the- stack-fallacy/)

<comment><AUTHOR> > In a surprising way, it is far easier to innovate down the stack than up the > stack.

That was quite unintuitive to me on the surface, but the examples provided really drove it home.

</comment></comment></comment></comment></comment><comment><USER9> _Viewed probabilistically, the most likely positive exit for a startup is an acquisition for less than $50 million. This outcome has little benefit to VCs, and they will happily trade it for an improbable shot at a higher outcome._

Am I misunderstanding something, or is the author asserting that VCs regularly make the sunk cost fallacy?

<comment><AUTHOR> I think he's referring to the distribution of VC-backed companies: since most will fail, the ones that win have to win really big.

If all of the winners in a fund get acquired too early (small wins instead of big wins) it could mean the fund is not actually successful because it's not enough to outweigh the losses.

<comment><USER10> This is accurate. Returns of VC portfolios follow a power law distribution. One or two companies generally return the entire value of the fund, and these tiny acquisitions are considered 'gravy'.</comment></comment></comment>


Face Recognition Using Pytorch - <AUTHOR> https://github.com/timesler/facenet-pytorch <comment><USER2> I see from the MTCNN code that this repo (like all others I've seen) is still bouncing tensors between GPU and CPU while passing between the P/R/ONets.

So many ML repos make this mistake in pre/post-processing and end up bottlenecked on CPU.

Anyone know of an MTCNN that's been ported to run more or less fully on GPU? (Or even that does batching instead of an image-by-image approach?)

<comment><AUTHOR> I'm not aware of any implementation with these features, but they are both on the roadmap for the linked repo. Both should also be achievable. Batch processing, in particular, will be a straight-forward change and should result in quite a speed-up. Although it will require the input images to have the same dimensions.

<comment><USER2> Good stuff.

In my experience inputs to MTCNN tend to be full frames, so the uniform dimension requirement is usually met.

</comment></comment></comment><comment><USER3> I usually use this one: [https://github.com/deepinsight/insightface](https://github.com/deepinsight/insightface)

<comment><AUTHOR> That's a good repo. It uses mxnet right? The aim of the repo in the topic was mainly to provide a clean implementation that could slot easily into an existing pytorch workflow.

</comment></comment><comment><USER4> Thanks for sharing. I'm working on face recognition with homomorphic encryption, therefore without compromising the user privacy. The bold goal is the first privacy preserving videocamera. If you find this interesting, I would love to chat about it.

<comment><AUTHOR> That sounds like a pretty interesting challenge. Happy to chat more - you can get in touch using the contact details on github.

</comment></comment><comment><USER5> Where in the page is the evidence of the speed claim made in the headline for this submission?

Edit: title has now been changed

</comment><comment><USER6> Great repo, been using it for a while now! Thank You Tim!

<comment><AUTHOR> Awesome, and thanks for your feedback in the early days. I've made the tracking interface much nicer as a result.</comment></comment>


Coding Problems from Programming Job Interviews - <AUTHOR> http://www.java67.com/2018/05/top-75-programming-interview-questions-answers.html <comment><USER2> I personally sat next to my boss in some of our few "classic" job interviews. Questions like the ones mentioned in this article were never brought up, because it would've felt extremely unnatural, even ridiculous. We usually took day-to-day real-world problems that weren't abstract and asked the candidates how they would approach them.

Some of the best software engineers I have seen in my life were not trained computer scientists and would've failed many of the questions presented in this article. Not because they weren't highly intelligent, but because terms like "bubble sort" meant nothing to them.

E: The company had around 10 employees. "Interview" processes often went like this:

1) Establish first mail contact (either because they are applying for a job, or because the company found out about an interesting tool they wrote, or met them somewhere, or...)

2) Discuss skills of candidate, decide whether the skillset fits the companies needs

3) If so, take a programming job fitting their skillset (usually some low- priority ticket) and give it to them as a freelance job

4) If delivered in good quality, pay them and discuss future job options. If delivered in bad quality, pay them and don't discuss job options. If not delivered, ignore.

Which I always thought was a very reasonable approach. Very often, the people weren't even interested in a job, but wanted to continue to work as freelancers.

<comment><USER3> > give it to them as a freelance job

I've always wondered why this isn't more common. It's win-win to be able to test the waters in this way. What downsides am I not seeing?

<comment><USER4> In addition to what the other commenters wrote, take-home assignments are also negative for diversity as they pre-select against candidates with less free time, which likely includes single parents and people from low-income backgrounds.

<comment><USER5> Gotta be honest about this. You are applying to a job of 40 hours a week and 6 figure salaries, and you cant make time for 10 hours of work?

<comment><USER6> You might currently be working a job that is 50 hours a week -- or 60! Also with the example of a single parent they often can't make room for yet another 10 hours of a work in a week because they need to spend time with their children/take them to activities/cook dinner etc. Manageable when you are working 40 hours a week but it quickly becomes unreasonable. To me a job that wants me to work for them before I have an actual job offer is a red flag. I don't even work for them yet and they don't respect my time. What's it going to be like when I do work for them?

<comment><USER5> Sorry, this triggers no empathy to me. This is alledgedly a workforce that requires years of study ,training and practice.

Being unable to work 10 hours to prove it shows you are a pauper, all the other excuses are complacency.

<comment><USER7> Quitting your job or dropping some other responsibilities might he reasonable for some people who can live off of their parents money or their own savings, but for many people that means losing their home, their car, or even their children. Indigo945 isn't making excuses for them or himself; he's telling you that for them to make that 10 hours would cost them far more than the new job might give.

Also, if anyone should be able to make another 10 hours in their week to work in tech why not say Steve who works at $BigTechCo? Now I know we just asked Steve for another 10 hours, but lets go ask him for another 10. No, the circumstances shouldn't matter, he's making 6 figures after all. Let's ask him again. And again, And again. Oh, Steve quit? What a pauper.

<comment><USER8> The same can be said for requiring candidates to have a github or using a college degree as a filter. Not everyone has the luxury to take out 10's of thousand in debt and spend 4+ years of their life learning instead of earning.

So unless you advocate for completely blind interviews that do not rely on a resume and only take up 3 hours of someone's day, your point is moot.

<comment><USER7> It's a part of hiring someone to have them send in a resume and verify that they have the skills needed to do the job. I contest that it is not fair to disqualify candidates because they cannot meet arbitrary and unreasonable demands for their time. A phone interview is almost always reasonable. A 10 hour work sample due this week would often be unreasonable. It depends a lot on context and conanbatt discarded that.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> A take from someone who asks these types of questions in interviews on a regular basis:

1) Don't just memorize this list. The fact that this list is publicly available means that we know not to ask these specific questions.

2) This is a very good way to practice the types of problems that are often asked in interviews, so if you can tackle these then you should be good to go.

A lot of people on HN and in real life (I've had people get angry for asking them to write code in an interview) hate these types of interviews. There's a lot of research done on this topic and so far, it's kinda like democracy. A crappy system, except for all the others. For all the complaints about this, I have never seen anybody propose something that satisfies the long list of requirements for interview questions.

Here's the list, pasted from an HN comment I made a few years back on a similar discussion:

Objective - the process avoids human bias (this guy was in my frat, therefore is awesome).

Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview.

Risk Averse - Avoids false positives.

Relevant - it properly tests the abilities needed for a coding job, and not irrelevant ones (like the ability to write an impressive resume).

Scales - this will be used for tens of thousands of interviews.

Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding.

<comment><USER10> Leadership ability, communication ability, team-work ability are probably more important factors than algorithmic ability in getting a project done, depending on the team. It seems the big-cos have figured that stuff out enough in order to make the development process as much of a meat-market as possible. However, these interviews would probably not select a maximal team for a startup.

The big-cos are also leaving a lot of talent on the table -- which makes it silly when they talk about a "talent-shortage." But, they're also paying enough where people WILL game these interviews in order to get the job... So the best argument I've seen for why these interviews work is that it selects people who work hard at learning this type of problem solving, to get the job... which correlates well with how hard they will work at the job.

Having an "objective" process is near impossible... and in fact probably not something one should strive for. Everything we do has humans has intuition behind it, whether good or bad. I think intuition is very important for finding a maximal team, especially a small one.

"Inclusivity" is kind of weird here.. most often you'll want someone with domain knowledge to get a project going quickly.. It's definitely less important for big-cos, but you still end up interviewing for a web job, an iOS job, etc.. so domain knoweledge does come into play.. at least at the big companies I've interviewed for (google, fb, lyft, uber, etc..)

I doubt this process is risk averse... you'll find people smart enough, but you learn little about their character.

Relevancy seems like a joke in your list... unless all you need is people to iterate on a small set of already solved algorithms in slightly different ways. I'd say that applies to zero companies. Except maybe leetcode, which helps people study for these tests.

The process scales well, and is easy to do, i think thats its strong suit... it's mostly effective across a ton of people.

So in summary, I agree that it seems like the best known process for these big companies. but I doubt it's as risk-averse as you think, and if you truly have a talent shortage, it's an artificial shortage created by your interview process. You might need to take some risks on people if you need to grow faster...

That being said, having that big-co process is great for startups! There's a lot of exceptional talent out there that will fail at the big-cos interviews, but will be better than their engineers for your team :) (There's also exceptional talent that will succeed at those interviews too, but would rather work at a startup) It might be a matter of using your intuition to find them... it's definitely a hard game.

I think this recent data-driven trend that is spreading across all realms of companies is poisonous in some areas where it does not belong... Human intuition still wins in a lot of areas, if it's good.

<comment><USER9> You're right, a lot of these metrics aren't as useful for startups and small companies as they are for bigcos.

> Having an "objective" process is near impossible

You're completely right here, however there are plenty of biases that can be avoided by attempting some level of objectivity.

> I doubt this process is risk averse

The risk-aversion is about avoiding hiring people that can't write code. You're right that it doesn't filter for character, which you will discover very quickly when working at larger companies! However a lot of the processes such as code review and design reviews help mitigate some of the bad character quirks that impact software. These processes are often not present at smaller companies, so the impact of character flaws is much larger there.

> Relevancy seems like a joke in your list

I'd say it's one of the most important ones on the list, especially for startups. When I was hiring for startups, I would get loads of people who could talk the talk but couldn't write a line of code. "Relevancy" means that your interview confirms that the candidate can actually code rather than just talk about it.

<comment><USER10> Interesting on the relevancy stand point. As an iOS developer, I had to learn a whole new set of skills for the interviews... I can count on one hand the number of times I needed to use techniques needed for the algorithm questions. I feel like the skills around making large scale apps is more about being able to reason about large scale projects and keeping everything clean and tidy.

I haven't really met anyone yet who could talk the talk but couldn't write code... I've definitely met people who have tried... maybe I have a good BS detector, or maybe I've been lucky? All people I've hired without doing the BST/linked list/DP problems, Ended up working out great. They probably can't do those problems still, but they can code a damn good app. Guess it goes back to not caring about false negatives

</comment></comment></comment></comment><comment><USER11> The given answer to #1 is incorrect.

It proposes to find the missing number in a range 1, 2, 3, ..., N by computing the sum of 1+2+3+...+N and then subtracting the sum of the given numbers. It tries to use the old Gauss formula Nx(N+1)/2, but gets the implementation wrong:

        int expectedSum = totalCount * ((totalCount + 1) / 2);

In Java, of course, "/" means "divide by 2 and throw away the remainder", so if you happen to use this for an even number (like 100, as in the original problem), you'll get 5000 rather than 5050.

It happens to work for their sample program because they used N=5 with the array [1, 2, 4]. Had they picked N=4 with [1, 2, 4], this program will say that the missing number is 1.

I didn't get any further in their list of questions.

</comment><comment><USER12> It includes the cycle detection in a linked list problem, and even has an illustration of the classic algorithm of Floyd using the tortoise and hare. It's kind of fun and interesting to look at what is actually required for that algorithm to work.

It's almost always presented as having the tortoise and the hare start on the same node, with the tortoise advancing one node per iteration and the hare advancing two nodes per iteration. Let's call this a (1,2) stepping version.

That suggests the first question to explore: for what positive integers n, m does an (n, m) stepping always work, when the tortoise and hare start from the same node?

A lot of people from what I've seen think that n and m have to be relatively prime, but that is not correct.

The surprising answer is that an (n, m) stepping works for any positive n and m as long as n != m.

This is surprising, because you might expect that if you were using something like a (2, 4) stepping, and the cycle length was a multiple of 2, you could get the tortoise and hare stuck in non-intersecting loops. E.g., if the cycle length is 8 and we number the nodes in the cycle 0, 1, ..., 7, and the nodes before we reach the cycle are -1, -2, -3, ..., couldn't we end up where the tortoise gets stuck in looping over 0, 2, 4, 6, and the hare gets stuck out of phase with the hare looping over 1, 5?

It turns out that there is no way for the hare to enter the loop at 1 without the tortoise also entering the loop at 1, which puts the tortoise on the 1, 3, 5, 7, and it will meet the hare. This is a consequence of the tortoise and hare starting from the same node.

That suggests the second question to explore: what is required for an (n, m) stepping to guarantee it works regardless of the starting nodes of the tortoise and hare?

The answer there is the difference in speed, m-n, has to be relatively prime to the cycle length.

Note that (1, 2) is a stepping that works universally. If the tortoise and hare start at the same node, it works because 1 != 2. If they start on different nodes, it works because 2-1 = 1, and 1 is relatively prime to every possible cycle size.

But (1,2) is not the only stepping that works universally. (n, n+1) works for the same reason.

That suggests a third question to explore: are there circumstances where it is better to use an (n, n+1) stepping with n > 1 than to use (1, 2)?

<comment><USER13> The linked list cycle problem was an open question for many years in the mid 20th century.

You may have discovered why: it's not actually as easy as it seems when you know the answer.

There's a blog post about this somewhere, how it's not actually a great question to ask.

</comment></comment><comment><USER14> It's an interesting thought to approach these types of coding questions from a different angle -

If I wanted to become a better programmer, what would be the best way of doing that?

In other words, if I practice this style of problem solving day in and day out, will that make me 10x more efficient at my day job? Honest question... I don't know the answer, although, I doubt it will.

</comment><comment><USER15> A company that asks these types of questions has likely never critically examined its own interview process. For every last one of them, my first thought was "why was this data structure chosen, and could this specific problem be solved architecturally rather than algorithmically?"

First question: "How would you find the missing number in an array?"

Easy answer: If there's only one missing number, XOR every number in the array together and XOR that with your expected result, from XORing every number you expected to have been there. That's the missing number. It even works with nonconsecutive numbers, which your n(n+1)/2 solutions won't get. And for consecutive numbers, to get the XOR of the whole list from 1 to N, switch on N % 4, returning 0: N, 1:1 , 2: N+1, 3: 0 .

Hard answer: I can't think of any real-world situation in which the developer couldn't solve this problem better by ensuring it never needs solving at all. Keep track of numbers that were never added, or later removed. What are the missing numbers? Return the list. Fix the problem upstream, and you won't have to recover missing information later.

<comment><USER16> Fucking Christ, both the OP's answer and logfromblammo's one are all that's wrong with this industry: really zero field experience and requiring the academic, PhD-thesis level clever fucking answer. A seasoned professional would use a fucking map and get the job done. No XOR tricks, no clever arithmetic, no niche BitSet crap. FOR i=1 to 100 occurences_map[x[i]]++. FOR i=1 to 100 if occurences_map[i] == 0, found the fucking number.

Of course giving this answer WHICH SOLVES THE FUCKING PROBLEM gets me instantly disqualified for not being cumbersome enough for the liking of the rookies running the industry.

<comment><USER15> I thought about including the answer that doesn't require branching, but didn't, because it sounded too fucking clever even just proofreading it. The N(N+1)/2 and summation is the answer they _probably expect_. Gimmicky XOR tricks set you slightly ahead of the pack. Magical bit-twiddling answers and branch elimination make you look pretentious, unless you're literally Carmack.

My point was that solving the problem as posed does not solve the problem inherent in posing the problem. Finding the one missing number in an array of otherwise consecutive numbers means that you were already storing N-1 numbers instead of the one number you wanted. If you stored the missing number instead, it's trivial to construct an array from 1 to N that skips over it. Save space, save time.

And if the profiler says that this problem is on a critical path in an inner loop, optimizing the heck out of it still won't help as much as unmaking the problem entirely, pulling all the cumbersome calculations out into less-used code. If the profiler says that it barely ever gets hit, then there should be zero algorithmic tricks, and the code should be optimized for human readability instead.

As an interview question, it might as well be a cryptic crossword clue, because the solutions that would be put in place by perfectly good developers are not the ones in the back of the textbook.

</comment></comment></comment><comment><USER17> So it's almost HN cliche to complain about these sorts of questions, and that's a fairly earned failure, but I just want to reiterate that these sorts of questions are one or two orders of magnitude more meaningful than the nebulous questions you sometimes see, "estimate how many auto mechanics serve Portland" or "I shrink you to the size of a pea and throw you in a blender, how will you survive?" or the like.

At the core, what you should be doing if you want to hire properly, is to take a break approximately 10-15 minutes into the interview. Go get a bottle of water or something. During the next 1-5 minutes, jot down on a piece of paper your initial impressions of the candidate, your suspicions and biases.

Some studies show that based on folks viewing the first five minutes of an interview, they can usually predict the outcome. One can interpret that in several ways, but the more cynical is to just say that most interviews are exercises in confirmation bias: you get some suspicion of the candidate, you spend the rest of the interview looking for evidence of your suspicions so you can feel good about your eventual predetermined decision.

If you want to do better, it's very simple: do what a scientist does and flip this on its head. Write down your suspicions and then _try to disprove them_. You think that this person is too egocentric for your company? Then ask them to talk about how they have worked with others, ask what they'd do if a coworker was struggling with a personal issue, try to gather evidence that they can actually be compassionate and empathic. You think that this person cannot program their way out of a bag? Throw them a softball programming question like FizzBuzz. You think that they have encyclopedic knowledge of algorithms? OK, then ask them to implement a Dijkstra's algorithm and if they don't know what that is, a breadth-first traversal.

What people are really sick of is that people use these tools as crystal balls into their own psyche: You as an interviewer tend towards "he got QuickSort wrong!" if you subjectively didn't want him in your company, "she got QuickSort almost right, except for some finagling around the pivot!" if you subjectively did want her. What's missing is _deliberateness_ : choose what you want to know deliberately, choose the question deliberately to satisfy some goal: either saying "yeah my hunch was wrong about that, they did pretty well" or else "no, I really tried to give them every opportunity to show me that they can code and even trying to give them the benefit of the doubt I am still unconvinced."

<comment><USER18> > Some studies show that based on folks viewing the first five minutes of an > interview, they can usually predict the outcome. One can interpret that in > several ways

I have interviewed dozens of people, possibly hundreds of people.

I do get an impression within the first three questions. Some people I ask three questions covering different areas, and they knock all three questions out of the park. Some I ask three questions of and they kind of fumble around and give a very limited answer for two of the questions, and can't answer the third at all.

In my experience, I can't recall ever seeing a divergence after this. If they fumble through the first three questions, they will fumble through the rest of the interview. If they can answer the first three questions coherently and in- depth, they will be able to answer virtually all of the subsequent questions coherently and in-depth.

I'm not really confirming biases because I generally ask everyone the same questions. The only time I mix it up is if they're answering all the easy questions correctly, I start asking slightly more difficult questions which I don't ask much. I don't ask them much because if someone is stumbling over the easier questions, there's no reason to ask them tougher questions.

Also, my first technical question is almost always an incredibly easy, standard question. I just ask it so they can answer one quickly and correctly and relax a little. But maybe 20% of people botch even this.

<comment><USER17> Now that's very interesting. I think you're right that within those first questions you do get some sort of perception about technical capacity in some raw form. Maybe it's even worth not trying to disprove that hypothesis by asking a separate question.

But what I'm confused about, that I'd like to hear your opinion on, is why if you have this confidence that your first three questions contain 90% of the signal, that you spend the rest of the interview doing anything vaguely related to that? Like it sounds to me that you just told me, "I get a 90% accurate measurement in the first, say, 30% of the interview, and then I waste my time for the remaining 70% trying to up it from 90 to 98%," and that just doesn't seem like a great use of your time after that point. Can you help me understand -- why don't you pivot to something like trying to evaluate their conscientiousness or openness to learning or emotional intelligence or ownership of their previous projects and mistakes and such? Or do you mean that you ask these programming-type questions and you indirectly learn about those other dimensions of success?

Also, I'd be curious to know what you do about teachability for some of the skills -- I know that sometimes it's just "we're hiring for a senior role and we cannot accept a junior/intern at this time," but very often it seems like it's just "we're growing in general" and then you _are_ open to saying "hey we don't have an opening for you as a mid-level developer but we would be willing to hire you on as a junior-level dev and if you are as good as you say you are we'd also consider promoting you after your 90-day-review when we've seen you really shine." Are you trying to assess the level of the role that you would offer the candidate with your questions, in other words? Or are you just judging fitness for a fixed role?

<comment><USER18> > why if you have this confidence that your first three questions contain 90% > of the signal, that you spend the rest of the interview doing anything > vaguely related to that?

When interviewing people maybe one in six answer questions correctly and in- depth, one in six do very poorly, and the other two thirds do so-so. The two thirds are all kind of interchangeable - they can answer most simple questions in a basic manner, missing a few here and there, but can't go into much depth on things.

I would say it is kind of a strict culling thing. The purpose is to find the one in six who can answer the questions well. There's not much reason to change it up much with the twelfth interview who is doing so-so, because if I interviewed twelve people I probably just talked to two people who are a standard deviation above the person doing so-so. So I want to talk more with them, not the one who doesn't know anything in-depth.

On the interviews where they're really stumbling, sometimes I have felt like standing up after only a few questions and going back to my work. Initially I am never focused on one particularly area, I am jumping around in case the last question was in some area they have a gap in, and perhaps they have a strength in some other area. I use their resume, and ask them directly about the areas of strength, to guide this. If they tell me they are strong in an area I will certainly ask them some questions in that area. If I know early I will say no, but keep asking questions any how, I suppose I stay the minimum amount of time I can without seeming rude.

The one in six who do well, those are the ones that I "pivot to something like trying to evaluate their conscientiousness or openness to learning or emotional intelligence or ownership of their previous projects and mistakes and such". Or more broadly, get a sense of their personality, how they will fit on the team, what their expectations are etc. I suppose it is almost the pattern as the technical questions - one in six will have some obvious personality quirk (they really don't listen to what we're saying at all, or they are very obnoxious, or they seem uptight beyond being nervous at an interview - or they take a pen out and start writing on different objects in the office, and the the boss comes by later and asks who wrote over everything and you say the interview subject, and the boss asks why you didn't stop them from writing on desks, walls, machines etc. with a pen - yes, this happened), two-thirds seem normal, and one in six is very friendly and/or seems like a real go-getter with a lot of accomplishments under their belt. I'm pretty lenient at this stage, although others are less so (also, I wouldn't mind having a teammate who would gripe about features and projects they thought were BS, but maybe my team lead or manager would mind - so a pass by me for this type might be a block by them).

So in short, I don't even try to fathom their "emotional intelligence" if they're stumbling on easy questions.

Insofar as teachability, we're usually hiring for a role. They're also being interviewed by multiple people - my technical assessments of the one in six who are good usually matches my coworkers. I tend to be more lenient on personality, emotional intelligence etc., they will say no to people I say yes to. So even if I was more lax, they are not, and they won't get in. Usually there is not much leeway, we are hiring for set roles. The main leeway people get is if they know someone in the group already. If their friend works in our IT group, and they know the subject but not in-depth, we often OK them on the basis of the recommendation that this person is the type that will get up to speed.

</comment></comment></comment></comment><comment><USER19> Sometimes I think that interviews steal business time. They don't show what a person can do exactly. Your qualification shows your test work, trial days. So, you have to show how you are in the job. Because interviews create a stressful environment. These questions in the article show that you can memorize answers and tell them immediately. Very soon AI will check our skills and fit us with the most relevant projects for us. I see it's the future. For example, two startups as [https://talent.works](https://talent.works) and [https://periodix.net](https://periodix.net) . Their AI algorithms check a CV of a candidate and match them with open positions. It really works! First one is for searching for full-time jobs. The second project is for remote and freelance workers. I believe that AI destroys interviews in a wink.

<comment><USER20> How do you account for people inflating or lying about their work on their CV?

I think those sites you mentioned only get you to the point of actually having your skills vetted. It's not a solution to the proposed problem of interviewing.

<comment><USER21> How to check a lying person on an interview?

<comment><USER22> Ask them a few questions. It's pretty easy to figure out that that AWS "expert" has just clicked around on the console for a while and doesn't really understand things by simply talking to them about it. Or if someone says they've been programming in python for 10 years, make them talk about the projects they've done, how the code was structured, etc.

</comment></comment></comment></comment><comment><USER23> In my role I've frequently had to interview software developers for the company I work for. We ask similar questions to this as the type of software we write needs an understanding of what's going on at a basic level.

We've interviewed developers who are amazing on paper, but can't answer simple questions that are mainly around enumerating a collection of integers.

I'd say communication is something we look for. Can you articulate why solution x is better than solution y? What are the compromises? Do you need to ask for more information?

So many candidates don't know an interview is an invitation to a conversation. You need to be able to engage with the people who are interviewing you. Ask questions to clarify if required.

The key advice I'd give developers is to be humble. I've met and worked with developers who are very talented, but also difficult to work with because of their personalities, we filter for this as a result.

</comment><comment><USER24> There's literally no question in that list (or questions like those) I would bother asking during an interview to any candidate at any career level. My expectation simply is that a solid candidate would be able to figure out anything on that list given a reasonable amount of time commensurate to their career level.

I've been interviewing software engineer/dev candidates for 10+ years, and I would be extremely concerned if these kinds of questions either sunk or swam a candidate on their own. Obviously if someone couldn't figure out any of these, they'd be a bad hire - but I've found simply discussing work/projects people have done before, peeling the onion away layer by layer, to be a far more effective way of determining skill/fit/critical thinking skills.

<comment><USER25> "My expectation simply is that a solid candidate would be able to figure out anything on that list given a reasonable amount of time commensurate to their career level."

The point of the interview is to determine if they are in fact a 'solid candidate'!

Also, sometimes very experienced engineers have difficulty thinking, communicating and writing code coherently even if they can 'discuss' project issues in detail.

Here's a famous and interesting article on that [1]

[1] [https://blog.codinghorror.com/why-cant-programmers- program/](https://blog.codinghorror.com/why-cant-programmers-program/)

<comment><USER24> Oh, I had an edit to my original post that included something about coding challenges (either homework or pair programming) - didn't want to give the impression that should be ignored - forgot to submit that change to my post.

</comment></comment></comment><comment><USER26> Just the first two question's solutions are wrong. Did not bother reading past that. I assume whoever wrote this article either, a) wants to make sure other people fail these types of interviews, or b) is trying to hire people and wants anybody who google this to get these wrong.

</comment><comment><USER27> If you were trying to hire Jimi Hendrix to play guitar for you, would you make him audition by playing Mary Had a Little Lamb? Don't dictate what they should play, let them show you what they got.

<comment><USER28> This is sort of like how if you want to hire a chef for a Michelin star restaurant, you ask them to make an omelette, not come up with an innovative dish.

[https://www.reddit.com/r/AskCulinary/comments/2qw1rp/executi...](https://www.reddit.com/r/AskCulinary/comments/2qw1rp/executive_chef_threatened_to_have_me_make_him_an/)

It's something that virtually everyone knows, and is a test that they have a very solid command of the basics as a foundation to build more complex things on.

</comment></comment><comment><USER29> What about graph problems? Admittedly, I only did a 10 second scan, but nothing jumped out.

</comment><comment><USER30> As DHH said: "I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles." I tend to agree.

</comment><comment><USER31> I would immediately put a X mark on a company which asks as stupid interview questions as those...

Thats not how you look for developers with passion - people that care about you as a customer and want to solve your problems the best way possible.

Thats how you hire coding monkeys which produce sub bar code and dont care about their job..

</comment><comment><USER32> No Fizz Buzz?</comment>


21.co: Replace your public email with an inbox that pays you - <AUTHOR> https://21.co/ <comment><USER2> I have long thought email should go in this direction. We only need to ask just a few pennies per message to eliminate spam completely. Also, by setting a highish fee per email, it's a good way for busy people to filter out all but the most serious inquiries.

Glad to see someone is doing it.

</comment><comment><USER3> Can't tell if it's a joke or not.

<comment><USER4> It's no joke. I've seen a variant of this (or perhaps this) before.

It's paid access of the crudest kind and to be honest it seems to me that it is designed to fleece people who are borderline mentally ill. I know from experience that a lot of people suffering from mania fixate on contacting specific individuals about: business ideas, a book they're writing, a spiritual/religious idea that needs championing...

I think they would be avid users at this price point.

</comment></comment><comment><USER5> Been a member for a few months and got 2 "emails" for $1 and $0.01. don't get your expectations up if you're a developer.

</comment><comment><USER6> This seems rather useless if I am not given an email address so recruiters have to pay to say dumb things to me.

</comment><comment><USER7> Does anybody know what happened with 21's vision of an embeddable mining chip?

[https://medium.com/@21/a-bitcoin-miner-in-every-device- and-i...](https://medium.com/@21/a-bitcoin-miner-in-every-device-and-in-every- hand-e315b40f2821)

</comment><comment><USER8> I used this service a few weeks ago to get a response from a VC that I wanted to contact, and it worked great! The cool thing is that you pay only if you get a response.

</comment><comment><USER9> The website seems very light on information about its own service

</comment><comment><USER10> This is the future of email.</comment>