SQLite: The art of keeping it simple - <AUTHOR> http://www.jarchitect.com/Blog/?p=2392 <comment><USER2> Since no one mentioned yet, the (lack of) license:

"The source code files for other SQL database engines typically begin with a comment describing your license rights to view and copy that file. The SQLite source code contains no license since it is not governed by copyright. Instead of a license, the SQLite source code offers a blessing:

May you do good and not evil

May you find forgiveness for yourself and forgive others

May you share freely, never taking more than you give."

<comment><USER3> I wonder if they've ever run into the problem Douglas Crockford had with IBM requesting he clarify the "The Software shall be used for Good, not Evil" clause he added to the MIT license for JSLint....

[https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_d...](https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s)

<comment><USER4> You can buy a SQLite license if you really want one:

[https://www.sqlite.org/copyright.html](https://www.sqlite.org/copyright.html)

at which point you are free to ignore the blessing.

</comment></comment></comment><comment><AUTHOR> [http://sqlite.org/src4/doc/trunk/www/design.wiki](http://sqlite.org/src4/doc/trunk/www/design.wiki) offers a good overview of SQLite deisgn, for those who are interested.

<comment><USER5> > _" SQLite4 is an alternative, not a replacement, for SQLite3. SQLite3 is not > going away. SQLite3 and SQLite4 will be supported in parallel. The SQLite3 > legacy will not be abandoned. SQLite3 will continue to be maintained and > improved. But designers of new systems will now have the option to select > SQLite4 instead of SQLite3 if desired."_

In addition to commitment, that's what I call clarity by repetition / reformulation :) . Good to see a writer handling worries about such backward- compatibility-breaking changes in the absolutelytotallymostest explicit way.

<comment><USER6> I listened to a podcast interview with Richard Hipp (the main SQLite developer) recently: [http://5by5.tv/changelog/201](http://5by5.tv/changelog/201)

It was really good. One of the things he mentioned is how they're planning to support SQLite until 2050 because of an agreement with Airbus (apparently that's the life of one of their recent plane models, and SQLite is used for some aspect of the software). Crazy!

</comment></comment></comment><comment><USER7> The link is broken at the moment.

I really want to read it to learn the answer to the following:

why isn't sqlite able to handle full scale loads? Why do I have to swap it out? Can't someone change the implementation details so it can work at scale and leave the interface the same?

Where is sqlheavy?

<comment><USER8> SQLheavy is called "Oracle". You want a feature, it's in there. You don't want a feature? Well, tough, it's in there anyway.

From [https://www.sqlite.org/about.html](https://www.sqlite.org/about.html) :

 _" SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine"_

Zero-configuration is actually quite an onerous design requirement, as it immediately eliminates most features which shouldn't be on by default. It also eliminates tuning.

Serverless imposes most of the rest of the performance penalty. If you're accessing a sqlite database from a single process, it will most likely be limited by your storage speed. But if you're writing to it from multiple processes, lock contention will quickly become an issue. The obvious technique to improve lock contention is to separate the tables so they can be locked separately, but then you lose the single-file convenience.

That's why that page also says "Think of SQLite not as a replacement for Oracle but as a replacement for fopen()".

<comment><USER7> I guess I don't mean more features. I just mean I want to write the same code and put in heroku or whatever and have it be ready for production load (10,000s or 100,000s of people hitting it).

The code I wrote has already told the machine what I want it to do. I don't want to be involved in figuring out how to make the DB work on a larger load.

Being serverless isn't a feature for me. Zeo-configuration is. Can't it handle the server stuff without asking me to type more lines of code? Maybe on heroku?

<comment><USER9> If you're into ORMs, then you can do that, use SQLite in dev and switch to PostgreSQL when in prod on heroku.

You're basically bashing the Smartcar because it can't pull your 5th wheel heavy trailer.

<comment><USER7> I agree with the analogy, but I disagree with "bashing."

I don't think its a failure.

</comment></comment></comment></comment></comment><comment><USER10> I recently hacked at sqlite to support some features I wanted (being able to retrieve same named columns from different tables in jdbc result sets and implementing some mysql functions)

and it was not fun. I guess maybe it says something that as someone with very limited c exposure I was able to get the column hack working in a night, but honestly following the code around was a chore. Lots of conditionals in a single function meant jumping back and forth a lot.

Also, as a primarily java programmer, I find what c programmers think is a descriptive variable name is a lot different than what I think is a descriptive variable name, but that's a personal issue.

</comment><comment><USER11> Cached: [https://webcache.googleusercontent.com/search?q=cache:http:/...](https://webcache.googleusercontent.com/search?q=cache:http://www.jarchitect.com/Blog/?p=2392)

The post says the first code snippet's variable naming is easy to understand. Really? To me it's unreadable despite ticking all the best practice boxes. I mean there are no comments and all the variable names seem to be as short as possible, it's hard to follow exactly what and why it's doing things to me at least.

<comment><USER12> * No comments

* No line jumps

* Cryptic variable names

* Magic numbers

* Multiple return points in the middle of the function

Yeah, this code might be doing good things, but I wouldn't be thrilled to inherit it in a project. I mean it's not bad code per se, we all have written things like this; it's just not something to point at for exemplary code either.

<comment><USER13> The only numbers I see are 1 and 0. Surely, you don't mean we should redefine 1 and 0!? :P Those numbers are hardly magic.

The function comment header describes the purpose of the major variables used in the function.

While the variables names may seem cryptic, they appear of a consistant format (within the function) so I bet the larger codebase is equally consistent in their usage -- and adapting to the codebases convention would be made easier.

<comment><USER14> It's a little _compact_ for my taste (eg: the mulitple early returns on error, I _think_ I'd like a blank line after a return, to make it stand out a bit more -- but I'm not sure. I don't write C on a daily basis).

The only other thing that strikes me is the convoluted calculation of nBytes, from (sizeof(char * ) + sizeof(i16) + 1) multiplied by the n-argument for resize. Granted nBytes is just used for the custom malloc-call, but I get a little scared with that and the naked mix'n'match of sizeof's in there.

It _seems_ like that (and maybe a few of the other things) could've been DEFINE-d in a header, and or factored out to easily in-line-able functions -- that might have provided an (even) clearer picture of what's going on.

</comment></comment></comment></comment><comment><USER15> I think a testament to the quality of SQLite is its flexibility. I was given the task of building a distributed, HA databases that ran without human intervention. I was able to adapt SQLite to run on a different storage backend in the area of days as opposed to the weeks or more it would take with another system.

In addition to this, I was even able to port SQLite to the Linux kernel: [https://github.com/sargun/ksqlite](https://github.com/sargun/ksqlite) \-- and IMHO, it's really neat that in <1000 lines of code I could adapt this database to run in kernel space.

<comment><USER16> Why would I want sqlite to run in the kernel? I'm asking out of genuine curiosity.

<comment><USER15> For fun. More seriously I was interested for two things: 1) Policy framework - every policy framework has its own wacky way of specifying matches, and actions. SQL turns out to be pretty good at this. 2) For some other projects I needed an in-kernel virtual machine. I needed something written in C, that had a no libc requirement. My choices were nekovm, and SQLite at the end. I decided to take out two birds with one stone.

</comment></comment></comment><comment><USER17> He's not as skilled as he thinks he is. And I can't even comment on the post, it returns a permissions error. Here was my comment:

1) Where's the unit test of this function? :)

2) The function could be purer. For example, sqlite3DbMallocZero could be passed in as an anonymous function. That way you could actually unit-test the out-of-memory condition that returns SQLITE_NOMEM_BKPT ... without actually being out-of-memory. ;)

</comment><comment><USER18> Is this a joke?

> No extra comments in the body.

Yeay no comments!

> The function body is well indented.

It clearly isn't. There's no whitespace to separate the lines making it hard to read, and the if bodies are on the same line as the if statements which is also hard to read.

<comment><USER19> I love the indentation. Much easier to read than a bunch of nested ifs and whiles and good to see a lack of outdated comments inside the method body. So a line-by-line read of that code seemed quite enjoyable to me.</comment></comment>


What Ben Franklin Really Said - <AUTHOR> http://www.lawfareblog.com/2011/07/what-ben-franklin-really-said/

<comment><USER2> 1.) The article didn't link the original letter. If you want to give the context, then link the entire text from the letter. Wittes may be completely accurate, but there is no way to verify his credibility.

2.) Wittes still didn't prove that his remarks are not a general argument to the specific issue he is writing about. The quotation is so generic that is seems to be a basic principle that he believes in, and he is using that principle as his argument against this specific instance of liberties being curtailed. If Wittes posted the actual text that surrounds the quote, it would become clear that he believes in this general principle in every context, not just in this specific argument.

"There is not in any volume, the sacred writings excepted, a passage to be found better worth the veneration of freemen, than this, "those who would give up essential liberty, to purchase a little temporary safety, deserve neither liberty nor safety;" nor could a lesson of more utility have been laid at the crisis before the Pennsylvanians."

[http://books.google.com/books?id=HptPAQAAIAAJ&pg=PA100&dq=%2...](http://books.google.com/books?id=HptPAQAAIAAJ&pg=PA100&dq=%22deserve+neither%22+franklin+-essential&hl=en&sa=X&ei=0Gn6UojUGuPr2wWlnYHoAw&ved=0CC0Q6AEwAA#v=onepage&q=%22deserve%20neither%22%20franklin%20-essential&f=false)

</comment><comment><USER3> Probably worth reading the author's follow up article. It's a Brookings Institute piece focused on creating a disconnect between Liberty and Secuity, or rather decoupling the concepts as non-related. Interesting logic.

"We seldom stop and ask the question of whether and when our surveillance programs are really coming at the expense of liberty at all; or whether the relationship might be more complicated than that—indeed, whether some of these programs might even enhance liberty."

[http://www.brookings.edu/~/media/research/files/papers/2011/...](http://www.brookings.edu/~/media/research/files/papers/2011/9/21%20platform%20security%20wittes/0921_platform_security_wittes.pdf)

</comment><comment><USER4> It's an interesting historical wrinkle to the quotation, but I don't think it alters anything fundamental about it's meaning.

All we can say is that Franklin considered a people's right to self government an essential liberty. Given his role in the independence struggle that shouldn't surprise anyone. What other things he, or we might consider essential is moot. But it's clear that he used the term 'essential' deliberately. He clearly isn't saying that we should never surrender any liberties in return for security.

<comment><USER5> When I read the article it struck me that it is nearly the opposite of how people use the quote today. It appears the quote's context was about the liberty of government (Ben Franklin as a legislator in 1750's Pennsylvania colony) to tax the elite Penn family to pay for arming British troops, the government's army at the time. It had nothing to do with individual liberty or individual security.

It was about his liberty as a legislator to tax the property owners inside the colony to fund the government's army to defend itself during the French & Indian war. The colony governor was appointed by the Penn family and the Penn family didn't want to pay taxes.

<comment><USER4> I don't read it like that at all. It was about the liberty of a people to govern themselves. I don't think Franklin saw the people and their representative government as being separable the way your interpretation separates them.

I certainly don't think he was talking about the liberty of the people from government, nor was he talking about the liberty of the government to govern the people. He was talking about the liberty of the people to govern themselves.</comment></comment></comment>


Ask HN: Any success with Toastmasters? - <AUTHOR> I'm looking into ways to get better at public speaking and have heard great things about Toastmasters. Has anyone here had success with their program as a way to prep for conferences and tech talks? <comment><USER2> 10+ years ago, a software development manager that worked for me had obvious problems with public speaking, even to small in-house groups (5+ people). She attended Toastmasters and, after a couple of years, was a changed woman. She now makes a great living through consulting and professional development seminars she sells.

Granted, she was both highly motivated to improve and extremely talented, but after seeing the complete transformation she underwent through Toastmasters, I became a believer in Toastmasters.

I think Toastmasters is perceived by most as a conclave of dorky awkward people who like to give boring speeches in front of a captive audience. It may or may not be that, but my experience with her and others, is that it is also quite effective in imparting valuable communications skills.

I think many view boys that earn their Eagle Scout rank in the same way -- they are square, uncool, dorks, doing things that nobody cares about -- anachronisms. But, in the long run, the life skills they get are priceless.

My experience has been that that there are many technical prodigies in any industry. However, the population of technically competent people that are highly effective communicators is quite small. Being at ease when communicating in the large, or in the small, gives one a huge leg up in competing with their peers.

My personal opinion is that it would be hard to go wrong giving Toastmasters a shot.

</comment><comment><USER3> I got my "Competent Communicator" a few years ago. It took me about half a year and I think the time was very well spent. Where I found Toastmasters very valuable was for getting feedback, it's a significant part of their program.

You'll have to invest time to see results, there is no shortcut to become a better speaker. That's also the only reason I stopped, I couldn't afford to spend the time to have a reasonable improvement.

Quality of clubs varies somewhat in my experience and you have to spend some time to find a good club.

To put this into perspective: My education was in Germany and public speaking is not part of our curriculum, neither school nor university. Also debates in the form they are done in the U.S. are completely unknown here. Toastmasters really fills a gap in that respect. If you grew up in the U.S. Toastmaster (at least how it's done in Germany) might be a bit boring for you.

</comment><comment><USER4> This is a bit off topic, since the question is specifically about Toastmasters. I haven't done Toastmasters myself, but the people that I know that like it feel that they have gotten a lot out of it. Despite the self- selection bias, I would recommend Toastmasters because communication skills are so important in the software field.

My company took a new approach and was making good progress with our product when the Open Software Foundation decided that industry standards in the area were needed. This posed an existential threat to our existence since no one else was doing what we were doing in our unique way. Instead of working as the software architect behind our design, I was thrust into role of software evangelist and had to speak persuasively in front of huge audiences (hundreds) and even participate in panel debates defending my designs against every imaginable critique from IBM, HP, Dec, Apollo, etc. They had deep talent, outside consultants (Carnegie Melon Univ professors, etc.), and they were all trying to take down my company.

Naturally, the most important way for a software person to be successful is to know your craft and be able to make software, but once you start to rise through the ranks you and your endeavors will greatly benefit from the ability to give a good technical presentation.

I had the good fortune of teaching a few courses in grad school and this led to an opportunity to do some internal training on new software methodologies in my first real job. I worked on doing it well, and this eventually resulted in me being sent to Sweden, England, and Germany to speak about the company's software to our own engineers and customers. All of this prepared me for what I had to do for my own company's success years later.

Suggestions for getting comfortable with public speaking: start out easy (magic shows for your nieces and nephews), avoid Power Point (at first) and learn to think on your feet in front of an audience at a white board, work with material you know, and watch videos of excellent presentations in your field from conferences (there are so many on the internet now).

</comment><comment><USER5> We have it here at Yahoo. I've personally never been to one, but I know a couple people that have and they've liked. Can't you do one session for free and see if you enjoy it?

<comment><USER3> You can do as many sessions for free as you like, even actively participate in the sessions (impromptu speeches, giving feedback). The only rule is that only members are allowed to give prepared speeches.

My recommendation is to try out a few different clubs to find one that suits you.</comment></comment>


A Simple Way to Route with Redux - <AUTHOR> http://jlongster.com/A-Simple-Way-to-Route-with-Redux <comment><USER2> I suspect my knowledge is behind the times, but I never understood the appeal of putting stuff like "current thread" in the app state at all. To me, it makes much more sense if the stores (or the single data tree, in the redux case) just contain the flat dumb data, and the URL is used to pick the relevant data that the components need. This way, no state is duplicated anywhere, the stores are dumb, and the URL is leading.

This is how most server side MVC frameworks work too, it makes server-side rendering super simple (even with shared app state between users), it fits with RESTful designs, it forces you to design state into URLs so users can share links by definition, and so on. It just seems obvious to me.

But somehow, Flux and most things derived from it seem to disagree and insist on storing the "this is what the user looks at right now" information in the application state. To me, that hopelessly convolutes things. But I've been wrong before and I'd like to learn.

Can anyone explain to me why that's better? I might just be a conservative, grumpy old man here.

<comment><USER3> There may be some state that belongs in the URL and some that doesn't. The threat currently read should certainly be in the URL to facilitate sharing/bookmarking etc. But, for example, the state of some checkboxes or a dropdown or values in input element – while being part of state – don't feel like they belong in the URL.

I've actually been struggling with some of these. For example, whether a dropdown is expanded or not is state, but it just doesn't feel 'big' enough to even be in the reflux store. Plus it turns out to be a major hassle to implement such a dropdown, with actions firing the new state all the way up to the store and the state then being passed down the whole chain of components.

Following redux orthodoxy here also precludes you from using existing libraries (bootstrap/jquery) and kinda leads to reinventing the wheel. I had no idea how much consideration a simple dropdown takes until I looked at the bootstrap/jquery source for it.

<comment><USER4> For common components like Dropdowns, DatePickers, etc, I've been using Kendo UI Core with a set of simple wrappers to make them (mostly) stateless:

[https://github.com/guscost/kendo-react- wrappers](https://github.com/guscost/kendo-react-wrappers)

Perhaps not acceptable for performance-critical or first-class consumer-facing UIs, but you get nice cross-browser compatibility and pre-built widgets that can be surprisingly complex.

<comment><USER3> So, if I see this correctly, these components save their state in a global object, and that is supposed to persist state on re-renders? I get how this can be considered somewhat 'dirty', but can you elaborate on the performance implications?

<comment><USER4> The global KW object is just a namespace for the widget wrapper components. You'd have to reference the Kendo UI Core library and then the KW.js script before rendering your components containing e.g. <KW.DatePicker /> as in the readme.

Internally the Kendo library is going to maintain its own state and manipulate the DOM elements needed for each widget, and I only know a bit about how that works. Most of these wrappers only run render() once because React would throw all kinds of errors if it tried to diff the DOM inside the components.

Updates are handled in componentWillReceiveProps, and whenever the component can be updated with the new props without destroying and recreating itself, the updates happen via the Kendo API (after the wrapper checks if the new value is different). This means that for common use cases these wrappers should perform just about as well as the widgets do normally. Also every controllable setting is exposed as a prop, and the props are synchronized on every update. Props that are not passed in are reset to the defaults, meaning these widgets should _appear_ stateless to the containing component.

The react-kendo project[0] uses some very cool introspection to provide full support for all the Kendo widgets, and it looks like it should be reliable and stateless. However it destroys and rebuilds the widget on every update. While that probably isn't going to be a huge performance hit it certainly makes a difference.

[https://github.com/tjwebb/react-kendo](https://github.com/tjwebb/react-kendo)

</comment></comment></comment></comment></comment><comment><USER5> Call me old (yes I am!) fashioned, but would it be too much to ask to see some sort of example app using said widget in the post?

This is the second article I've been interested in today here on HN that seems, to me at least, to go on and on extolling the virtues of said framework/extension/etc, and in the end gives absolutely no hint of how to use it.

Yes yes I know...farts like me are behind the curve/too slow/fat/old/stupid etc to understand all this modernity, but really, is it too much to ask for a small example of the Greatness?

<comment><USER6> Very fair point, however...

...in this case, it's not a widget, but a routing library. Actually a slightly nicer wrapping library around the same base routing library used by basically every React project, which means that for the user, it'll look exactly like every project that _doesn 't_ use it too. The only thing to "see" is basically the API docs.

(That being said, maybe that could be made clearer in the blog post...?)

<comment><AUTHOR> This post was strictly intended for current users of redux and react-router. That could be included yes, but I have limited time and I'd rather publish blog posts rather than languish in my "drafts" folder. I can add a few things to this though.

</comment></comment></comment><comment><USER7> Javacript moves fast (everybody knows that...). React and the tools around also move very quickly.

I've been delaying learning React for awhile. After a period of ranting about "another JS library, another JS tool etc etc!!", I got tired of my ranting and have been giving a decent go at picking up React and a myriad of related tools (webpack, flux, react-router...).

It turns out, if you have some experience of framework, whether it be AngularJS or Backbone (I come from BackboneJS and Marionette background), it doesn't take you too long to learn these things.

I signed up for Egghead, searched around for awhile for the latest relevant tutorials, opened up many Chrome tabs and jumped around different places, but after a week, things are falling into places (JOY!).

Learning part is frustrating, because there are references to old versions, old tutorials and you have to somehow mine through to make sense for yourself. But what isn't thesedays?

I haven't picked up redux properly yet, but now I get Flux, I don't think it'll take too long before applying it. Redux Router? Bring it on!!

</comment><comment><USER8> I recently switched to this library from Redux Router for a project, after having trouble with server-side routing.

It really is simple, as stated in his title, and I would definitely recommend it if anyone is using Redux and React Router.

<comment><USER6> I've been struggling with redux-router all week, and was just about to spend today trying to switch to this project. Glad to hear your experience. :)

<comment><USER9> Yeah, same here. Almost decided to ditch the whole redux-router for good before I saw this thread.

</comment></comment></comment><comment><USER10> As someone who's mainly just used react for simple components, when is the right time to think about pulling in redux? I'm getting by with just react, but it seems like at some complexity level everyone recommends a flux library (and mostly redux these days). Is it when you have multiple component trees on the page? When AJAX requests are involved? Or do people familiar with redux just drop it in from the very start even on simple components?

<comment><USER11> Dan Abramov wrote a blog post a while back with a bunch of "You might need Flux if..." use cases, which might be handy: [https://medium.com/swlh/the- case-for-flux-379b7d1982c6](https://medium.com/swlh/the-case-for- flux-379b7d1982c6)

</comment></comment><comment><USER12> This library lack some of the super powerful features that really made me fall in love with redux-router. Being able to get access to params was huge, and having action creators to pushState and replaceState was also huge.

<comment><AUTHOR> `updatePath` is an action creator, and there's a PR to rename it to `pushPath` and add `replacePath`. And you shouldn't access route params outside of a router component anyway.

(EDIT: ok, the last statement was a simplification. But generally you don't need to, but you could manually move data into the state if you needed to)

<comment><USER12> I get that, but still no access to params and the ability to change them is still a boon for me. I often will use stand to store some basic state for deep linking certain views. For example a data grid and the sort or filter options. I was able to very elegantly execute this with redux-router and its full exposure of the entire route object and API pairity to pushState and replaceState

<comment><AUTHOR> That's great! Keep using redux-router then. I think you'd find that there's another pattern that works too, but there are multiple ways to do it.

</comment></comment></comment></comment><comment><USER13> We got a router too for the same reason that Redux is complicated(and at that time redux-router was not released)

[https://github.com/teambition/router- view](https://github.com/teambition/router-view)

And it's demonstrated at here:

[http://r.nodejs-china.org/#/](http://r.nodejs-china.org/#/)

</comment><comment><USER14> There's an open issue to replace redux-router with this package:

[https://github.com/rackt/redux- router/issues/172](https://github.com/rackt/redux-router/issues/172)

</comment><comment><USER15> I personally agree with and admire the methodology behind Redux, but I'm cautious about using it because it's right at the bleeding edge of web technologies (which we all know are rapidly changing).

</comment><comment><USER16> So why so we want the URL in the state? What's the use case?

<comment><USER17> One use case of having URL in the state (from the lib's README: [https://github.com/jlongster/redux-simple- router](https://github.com/jlongster/redux-simple-router)) is that you can snapshot/serialize the app state, and load it up later and see the same thing. This can be useful for development and debugging.

It's also worth mentioning that this lib also provides a really useful action creator- updatePath(). It allows you to navigate from other action creators, for example, in response to a successful AJAX call. You could achieve that a couple other ways as well, but this is the simplest/cleanest way I've seen so far.

<comment><USER16> Thanks. updatePath is actually something I've been missing so that's great.

</comment></comment></comment><comment><USER18> Nice pictures. How did you make them?

<comment><USER19> I am curious too, really refreshing look. I would guess it's hand-drawn with something like Paper, the "smudges" reminds me of that app.

[https://www.fiftythree.com/paper](https://www.fiftythree.com/paper)

</comment></comment><comment><USER14> > This is what redux-router attempts to do, but it's very complicated and > prone to bugs.

redux-router is still in beta, so this isn't entirely fair.

<comment><USER20> I think the point is that serializing the entire react-router state into a redux store is in itself barking up the wrong tree, not that their approach is complicated or implemented in a buggy manner, per se.

</comment></comment><comment><USER21> It's disappointing that this depends on React's router, considering Redux is an agnostic framework. Unless I'm reading something wrong here..

<comment><USER22> From the post:

> After integrating redux and react-router in my site, I extracted my solution > to a new project: redux-simple-router. The goal is simple: let react-router > do all the work. They have already developed very elegant APIs for > implementing routing components, and you should just use them.

The explicit goal of the project is to take advantage of react-router's existing tools when used with redux, it doesn't make any sense to lament that it depends on react-router.

<comment><USER21> Then why not call the project redux-simple-react-router or something to that effect, given that it's written for an agnostic library but has a hard dependency on a third library? It's easy to get caught up in one's own bubble but you should be aware that there are plenty of people out there who don't use React but like some of the libraries and patterns that came out of that community.</comment></comment></comment>


Selective Reasoning - <AUTHOR> http://www.dustinland.com/archives/archives537.html

<comment><USER2> Ridiculous strawmen sure are fun to demolish, aren't they? Who needs logic or accuracy?</comment>


Venture Capital Fundraising Is Down Nearly 40 Percent In First Quarter of 2009 - <AUTHOR> http://www.techcrunch.com/2009/04/13/only-40-us-venture-funds-raised-new-money-last-quarter/ <comment><USER2> I hate headlines like this. Yes, it's down 40%, but from what base? Read the article and the benchmark is Q1 2008. Compared to the previous quarter (Q4 2008) funding is up 23%. What's the better benchmark? It's debatable but I would argue the previous quarter is a better benchmark (are things still deteriorating, stabilized, getting better or unclear)? Looking at 2007 and 2008, Q4 seems to be the seasonal high in terms of fund raising.

I know sensationalism sells and that gets people to click on stories which in turn helps sell advertising, but please...let's break the cycle...

</comment><comment><USER3> So what? There's still billions out there and the cost of starting a business is getting cheaper every year.

</comment><comment><USER4> Is that all? Given all the doom and gloom I was expecting something like 95%.</comment>


I've been a software engineer for 10 years and I can't do interview questions - <AUTHOR> https://www.reddit.com/r/cscareerquestions/comments/5xrs2n/ive_been_a_software_engineer_for_10_years_and_i/ <comment><USER3> If you hate the idea of coding questions as part of interviews, please consider the other side for a moment.

There are people out there (not you, obviously) who can talk their way into an interview for programming jobs that they simply can't perform. We're talking about no skills whatsoever, apart from the ability to sling buzzwords around enough to impress a recruiter. God only knows how they get their degrees, but they have them.

Simple, straightforward programming questions that aren't already on the Web are like an immune system response to these non-programmers who interview for programming jobs. I'm truly sorry when a real programmer feels insulted when I ask them something like "given the starting and ending times of two calendar appointments, write an expression that's true if they conflict", because it's not their fault that there are people out there who will struggle for 20 minutes thinking about how to solve it before trying something like a doubly- nested loop over all the milliseconds in both intervals, testing for equality.

I am not making this up. It's a real problem. if you can program a digital computer, you have nothing to fear from a _good_ coding interview. And if you have a better way to reliably identify the non-programmers, I'd love to hear it.

<comment><USER4> I myself have sat in an interview with my mouth agape as I watched a "senior" engineer try to figure out how to find the largest element in a one- dimensional array.

So, anymore I don't have much of a problem with simple coding questions to filter out total non-programmers (fizzbuzz, your calendar problem, etc.).

But the whole _stand on one foot and implement a red-black tree in bash script on the whiteboard while I peck at my smartphone and sigh every time you pause to think_ has got to freaking stop.

<comment><USER5> > _while I peck at my smartphone and sigh every time you pause_

This is a much bigger deal to me than difficult algorithm questions. Shitty interviewers give shitty interviews, regardless of what kinds of questions they ask.

The worst interview I ever had was like this. The guy showed up late, told me he forgot he even had an interview, gave me a strange question with little detail, and told me to start coding. Then ignored me for an hour while he typed on his laptop. Even when I directly asked for feedback to make sure I was solving the problem he asked and not a misunderstanding, he gave me basically no feedback. I've had interviews that I bombed before, but this was the first and only time that I felt like I bombed an interview and it was utterly not my fault. It was also the only time I've had a bad interview that actually ruined the rest of the day for me because it threw me off so much.

<comment><USER6> I think I would just walk out at that, at the end of the day this is someone you are going to have to work with or for.

<comment><USER5> I wish I had. If something like that ever happens again, I will.

</comment></comment></comment></comment></comment><comment><USER7> I was in the same situation a couple of years ago. I had over 15 years of experience, was invited for a technical interview at Amazon, and failed. At first I was irritated, just like the author. But then I decided to turn this negative energy into something positive and followed a couple of courses on Algorithms on Coursera, also I discovered Hackerrank. And I found out that I actually loved solving algorithmic problems!

Now it is a couple of years later and I actually was able to land a job thanks to my new skills (not at Amazon though). But what's much more important: I found a new hobby that will keep me entertained for many more years.

<comment><USER8> My story is the same too. I was a promising junior developer when I went to an interview at Amazon. Got my back handed to me. I was upset, but decided to work on it. Read a few books on the topic, and I no longer find these interviews difficult.

<comment><USER9> Before I interview I mention that I am uncomfortable with whiteboards. I prefer pen and paper. It's faster to write and feels a bit natural.

Only one company denied me the request and I didn't go ahead for them. Their loss.

I've also found having a github profile where you've files issues on projects and made a couple of commits really helps the chances. It gives more data than a resume.

At one interview, the interviewer read some of my commits and he said "I don't have any doubts you can code, but I wanna ask you about design". He went on to ask why I did things in a certain way.

But seriously. "Say no to coding on whiteboards".

<comment><USER10> I'm the opposite way. I prefer the whiteboard to pen and paper.

</comment></comment></comment></comment><comment><USER11> I think algo/ds interviews are created to test only one thing, and that is hard work. The idea that they test problem solving is mostly bullshit.

 _Most_ people are good at algorithm interviews because they've practiced them a ton. They've seen basically all the different kinds of questions that get asked on an interview, and are able to use that mental database to answer any questions.

Most of the time in interviews, interviewers will commend an applicant's "problem solving" skills if they did well on a difficult algo problem, when in all likelihood they've seen that exact problem, or an extremely similar problem before. If the applicant hasn't seen dijkstra's algorithm before and is able to derive it in a 45 minute interview, you would need to hire them on the spot, assuming that Dijkstra himself didn't develop this algorithm in 45 minutes. That is a contrived example, but you get my point.

For better or for worse, algo interviews are for testing how much work you've put into studying (mostly worse).

<comment><USER12> I've seen that many good interviewers have a problem that has a straightforward sub-optimal solution, which they expect you figure out ('problem solving') and code. If it can be solved better using Dijkstra, that comes as a follow-up.

</comment></comment><comment><USER13> I've had a lot of trouble finding a job since shuttering my start up, which I constructed on my own. I open sourced my code, but no one seems to care. They still just look at me as if I have no experience and pass on me before a technical assessment.

It's troubling to know that engineers with many years of experience still have difficulties. Every job listing I see asks for someone with 6+ years, and the only feedback I ever get is "we're looking for someone with more experience, try again in 4 years."

Tech companies should really just hire for soft skills. Screw tech interviews completely. A lot of this stuff can be taught. Maybe just give people a contracted trial period. Companies are spending incredible sums of money just searching for candidates that meet their exact "needs." In reality, they're not going to know how well someone performs until they actually work with them. Stop wasting your employees' time by having them grade pointless coding quizzes. Use that time instead to train someone who's a good communicator, is passionate about the product, is creative and eager to learn, and wants build something your customers will love. Even if that doesn't work out, at least you didn't waste everyone's time.

<comment><USER14> You are arguing that we should just hire anyone regardless of tech skills if they can carry on a conversation? It takes years to do learn how to do actual complicated programming. I think we need to screen for both tech skills and soft/people skills. I always strive to do both in my interviews.

<comment><USER13> I'm not saying that, and I doubt there is a very high number of fraudulent applicants to companies. If that becomes an issue, then there are less terrible ways of dealing with it. Wha I am saying is that we should let people's experiences speak for themselves. If someone's been a developer for three years (and didn't get fired for incompetence), then they probably know how to code.

<comment><USER15> > _I doubt there is a very high number of fraudulent applicants to companies_

The payoff is a $100,000 salary that you can collect for a month or two, of course there are fraudulent applications.

> _If someone 's been a developer for three years (and didn't get fired for > incompetence), then they probably know how to code_

I've worked with very capable Ph.Ds with wonderful problem-solving & analytical skills who would write the worst code, and were the worst at accepting feedback because of their extremely visible and objective achievements allowed them to believe they didn't need to improve their coding skills (which had already gotten them so far)

</comment></comment></comment></comment><comment><USER16> But could all practicing lawyers pass the bar _right now_ in their respective state? I'd guess no. The problem is not the questions _necessarily_ , it's that you have to study a bit and do the same goddamn interview questions at multiple companies, sometimes with very different interviewers. Some are helpful, some make me nervous, some are asking the hardest possible questions without warmup easy questions, etc.

Whiteboard or live coding is not the problem. Bad or untrained interviewers are, along with the fact we can't do one interview that proves to multiple companies what level we are at.

<comment><USER17> However, should a practicing lawyer have to re-pass the bar in order to land a new job?

<comment><USER18> Are we going to make the PE exam a requirement for the title of "Software Engineer"?

<comment><USER19> It really should be considered. I'm a registered (civil) EIT. IT would help towards the ambiguity in hiring and the ever increasing absurdity in interviewing.

Especially since the conflicting statements of "software jobs need protection to ensure good salaries" and "everybody needs to code" are all to prevalent here.

Being a PE means you have a certain level of experience and skill. It's a distinguishing feature and sets you apart as a "real" engineer. Additionally, it holds you to an ethical code.

What continues to astound me is the lack of rigor and ethical backbone coming from engineers in important places. Yeah you're not building a bridge, but incidents like Volkswagen and Yahoo could have been prevented if people's jobs were bound by not being unethical.

<comment><USER20> I suspect your advocacy of a PE designation for software and the discussion in this thread are slightly orthogonal. Not that is a bad characteristic, but I want to point out that the question under discussion would be similar to asking if civil engineers should prepare as if they are sitting for their PE exam every single time they start the interviewing process? Should practicing doctors, no matter how accomplished, prepare as if sitting for their boards every single time they start the interviewing process to say, move to a new hospital?

I also suspect that everyone is asking the wrong questions. From the anti algorithm questions for interviews crowd, there is scant acknowledgement that it can't be a blanket policy, as undoubtedly some positions are strongly algorithm-heavy roles. From the pro- crowd, there is scant acknowledgement that by the time you are trying to find new high tech hires through a process that bases an evaluation upon actual interactions that are measured in hours or at best days, _you may have already failed_. The industry is fitting an interviewing process last majorly overhauled during the industrial age that screens for basic three-R's and attendance skills onto a post-industrial landscape where those skills are barely above cosmic background radiation noise, and demonstrated achievers are as often groomed into hirings through networking over years and decades. Perhaps part of the response to better outcomes to "this high tech interviewing process that takes place in hours or days" isn't "find better questions" or "find a better procedure that still fits in hours or days", but "re-think our premises"? Some kind of PE might fit into that re-think, but the brokenness is so bad that Google has quantified the inability of our conventional processes to yield significantly-better- than-random outcomes, so it might be time to start questioning the entire premise that we can even hire based upon tech interviews in the first place.

<comment><USER5> > _but I want to point out that the question under discussion would be similar > to asking if civil engineers should prepare as if they are sitting for their > PE exam every single time they start the interviewing process?_

I suspect the typical PE exam is quite a bit more rigorous than the typical technical interview. Technical software engineer interviewees are asked to do thinks like reverse linked lists and provide the most basic runtime and space complexity analysis. The structural engineering PE covers everything from load analysis and building codes to runoff analysis an slope stability[1]. There are 9 different "breadth" exam areas and 3 different "depth" areas, and they're all covered.

I think it's slightly ridiculous to compare understanding basic datastructures and algorithms to sitting for a PE.

[1] [http://ncees.org/wp-content/uploads/Civ-Str- April-2015_with-...](http://ncees.org/wp-content/uploads/Civ-Str- April-2015_with-design-standards.rev3_.pdf)

<comment><USER20> I think what they are trying to point out is PE holders don't revisit taking even part of the PE when they interview. Is that true, though?

<comment><USER5> I have no idea what a typical (civil/structural/etc) engineer goes through when interviewing. I suspect that the PE isn't actually very relevant, though, since most practicing engineers are not PEs. Something like 20% of engineers get their PE. I'm guessing the interview process for PEs and non-PEs is pretty similar.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> You know the process is fucked up when experienced professionals (with a track record of delivering projects) start complaining about how companies don't look for the ability of delivering projects.

<comment><USER22> Every engineer says they delivered projects on time with great maintainable code. Unless the project is open source, they often have no way of giving any evidence.

I'm not saying whiteboard interviews are the right way to interview, but in my experience you can't trust people's judgment about themselves and their skills. You need an interview that is equally fair to the person that will exaggerate their past successes to the people that are more reserved or the people that don't have much experience yet.

<comment><USER23> > you can't trust people's judgment about themselves and their skills.

Unless the candidate is fresh out of uni, any qualified candidate with experience should be able to provide at least several solid contacts at previous employers from which to obtain this information.

<comment><USER5> References from co-workers aren't really that valuable. Many people have no qualms about giving glowing reviews for friends, even if those friends don't really deserve glowing reviews.

</comment></comment></comment></comment><comment><USER24> The interview process is great for employers...

1\. Make qualified job interview candidate feel stupid by asking difficult questions unrelated to the job

2\. Offer candidate low salary and argue that they barely passed the job interview

3\. Profit

Best solution I can offer is to not play their game. You'll lose no matter how hard you try. You're better off studying marketing and psychology for job interviews.

<comment><USER25> Great points about marketing and psychology. once you've won the lottery and got a whiteboard question, that you've prepared for. You additionally have to win unconscious biases of the interviewers and exhibit behavior that makes them judge you as a trusted "cultural fit" tribe member

<comment><USER26> Sigh. I completely crashed and burned at a phone screen once with a question that was easy but required knowing a bit shifting trick. I knew that the trick existed because I had glanced at it while studying and thought, "no way they'll ask that."

</comment></comment></comment><comment><USER27> Form over substance, as usual with large bureaucracies. Unfortunately, tech seems to view the biggest and most "successful" company as the model way to move forward, instead of throwing up the middle finger like they used to. It's sad to see the transformation of Silicon Valley to a pseudo-government style group of mega-conglomerates. The next batch of real innovators will not be from the Valley or be from Valley culture.

<comment><USER28> Yep. Used to be, the dream was to beat Bill Gates. Now the dream is to get bought by Facebook.

<comment><USER29> The dream was to make your own rules (which includes a ferrari, a private office and all sorts of perks). Getting bought by Google, Facebook, etc. is the new way of getting "fuck you" money.

</comment></comment></comment><comment><USER30> I have spoken about this to many SEs who are senior enough to conduct interviews in their companies. I ask them, what do you intend to get out of such interview process. Their response: 1) Evaluate how to think about a problem 2) Evaluate their approach to a problem 3) Evaluate how to solve by asking questions

So, most of these interviews, an experienced Software Engineer dons the hat of a psychologist (without having any qualification/experience of a psychologist) and evaluates an interviewee.

How sad is that?

Whats worse? I know a few who prepare to interview a candidate by going through "how to crack the coding interview"!

I'm only glad that there are quite a few in my circle who believe in giving a problem they have faced at work, to a candidate, and ask the candidate to solve, using the same tools they use, with the laptop hooked to a projector. Interviews where I have done this as a candidate, I feel are more respectful of the candidate.

Many of those who love the "let me be an unqualified psychologist today" interviewing style disagree with my opinion. So do I, with their's.

</comment><comment><USER31> Application performance matters, that's why these data structures and algorithm questions still matter. The issue is dogma surrounding the technicalities of data structures and algorithms.

We make sure in our group to focus on application of those concepts, not memorization or detailed knowledge of the concepts themselves. But yeah, fast algorithms matter. Memory usage matters. Proper data structures matter. I don't really care if you can spit out a syntactically correct implementation of a red-black tree on the spot, but you should know what a tree is and why you might pick or tree over a hash table.

I'd rather hire a writer who can really get a concept across but relies on autocorrect for spelling than a writer who can spell the hell out of stuff but can't actually write. Dogmatic interviews weed out the software engineers with the big picture skills and performance thinking who might be fuzzy on the details, like experienced folks who are decades out from school.

<comment><USER32> _Application performance matters, that 's why these data structures and algorithm questions still matter._

THIS! It's one of my go to stories but back when I was working as a co-op during my undergrad days, in my department there was a .NET programmer who was skilled but had no understanding of the underlying data structures.

He would be mystified at how I could write Perl programs that would outperform his .NET programs, even on less robust hardware.

</comment></comment><comment><USER17> It's all become a game now. If you spend enough time on sites like codefights and hackerrank and know all the algorithms you can land a job. However, if you aren't prepared for these whiteboard interviews you are screwed.

</comment><comment><USER33> This is by design, they're looking for students.

<comment><USER34> Students, super high achievers / superstars, and people who are willing to "play the game" and re-study everything for 2 weeks or a month.

<comment><USER35> LMAO.2 weeks?

HA!

Currently a graduating student that goes to one of those top schools. Do you really wanna know how long many of my peers are studying for these interviews? Months!!!!! I have a few friends that spent all of last summer after their daily internships doing interview prep for fall recruiting season. I also have a cousin that spent 5-6 months unemployed(given he did a masters/bs in ee and not in cs but wanted to move into the field) doing interview prep and just landed offers from Google and Dropbox. The competition is absolutely ruthless.

</comment></comment></comment><comment><USER36> I worked at an unnamed big company where the interview process involved being interviewed by a PHP expert, a java expert, and a javascript expert. They were surprised when NO ONE ever passed the interviews. Most actual hiring at the company involved getting contractors from a recruiter and then hiring them if we liked them--no technical interviews, just how much we liked them personally and if they could perform at the most basic level. I would imagine this is pretty common.

<comment><USER37> That's called 'contract to hire' and it was fairly common about 5-10 years ago. I don't see it as much these days. I'm not sure why, but it seems to have fallen out of fashion.

<comment><USER38> You don't see it because it gives the candidates a chance to see what a companies code base is like and look elsewhere when they discover how bad it is.

<comment><USER37> And that's exactly why I like work to hire. The biggest factors that contributes to whether you like your job or hate your life are your boss, the people you work with and the state of the code base. You don't get a good impression of any of them until after you've been hired.

</comment></comment></comment></comment><comment><USER39> For some folks 10 yrs experience is truly 10 yrs experience, for a lot of folks, 10 yrs experience is 1 yr experience repeated 10x. Or worse a few months experience repeated more. Unless you are truly learning each week and working with new tech often. Number of years doesn't tell me much. I've seen 2 yrs experience crush 20 yrs experience all around, in design, programming, OS knowledge, database, etc.

</comment><comment><USER40> I don't quite understand this point of view and the whining. Why is it that Software Engineers feel the need to whine about these technical interview questions? I don't think many of these are THAT technical either, just requires some practice. I dislike brain teasers, but I don't think Algorithms questions are out of line, even if you might not use them.

I graduated with an Aerospace Engineering degree. While I don't exactly remember how to derive the Normal Mode of a wing, I wouldn't have any issue relearning it for an interview. For my first job, I was asked questions that had very little to do with my day to day but I still answered them and didn't complain.

<comment><USER15> > _Why is it that Software Engineers feel the need to whine about these > technical interview questions?_

Because they're pointless for the vast majority of positions: why make me learn something for the interview that I'll never use again? This offends many engineers' sense of laziness.

Because it's a pithy indication about what's wrong with tech interviews: we can't ask 'are you good at delivering with weird requirements' (because the candidate says 'sure I'm the best'), and we can't check their ability to do that in 45-60 minutes. Instead, we use these shibboleth questions to see if they are like other engineers (who can deliver etc.)

Because it's gatekeeping: if you didn't study algorithms or have the time/energy to keep it fresh, you can't get past these interviews and get these jobs. It doesn't matter if you'd excel if you don't have the same opportunities as the normal privileged young white male engineer.

Because it's inefficient: plenty of engineers could perform well in the position but get screened out by these imprecise questions. Sure, for a startup of 4 employees, you can't settle for great and have to keep rejecting until you get the best, but for a mature stable company, you want people with solid skills and abilities who can learn (how to do algorithms) on the job.

<comment><USER40> None of that is specific to software engineers.

My non software-engineering Interviews contained tons of questions that aren't completely relevant. For example, describe in detail how pressure and velocity are correlated in each turbofan stage and how they affect efficiency. Describe what isentropic flow is and how it relates to lift.

I also hate getting random whiteboarding questions, but I'm not going to complain about it. If I really want a job I'm going to study for it.

<comment><USER15> > _If I really want a job I 'm going to study for it._

Congratulations on having the resources and stability that these interviews select for! Unfortunately, these are not requirements for doing well at the job.

</comment></comment></comment></comment><comment><USER41> I call bullshit on this train of thought.

I've been reading about this on HN and reddit for years now. This last December, I was promoted high enough, that I could design the entire interview process (with executive help) for my teams. Which was important, I very much need to hire some people.

So, keeping posts like this in mind, I designed as follows:

Phone Interview - We talk about you, the company, etc. Then a few technical questions. Do you know certain things about js that make me think you are genuinely familiar with the language (as opposed to just jQuery)? Do you know certain things about sql that make me think you are genuinely familiar with the technology (as opposed to just using a table designer)?

Assessment Test - Do a quick crud app, that will require some thought behind how to query the data. Make a point when talking to the prospective applicant that the code will be read by the team members they'll be working with, so while you can do the test quickly, please spend enough time on it that we can talk about the code, your choices, etc going into the technical interview. Ie) don't just link together 3rd party plugins.

Actual Interview - Interview with leads, interview with actual team members. Offer both use of Visual Studio / SSMS / IDE of choice or whiteboard. Ask questions about technology in general. Ask the applicant to explain how he'd design out a new feature. Change the feature spec, so that there's a little bit of a hard problem. Have to populate a tree from flat sql data, or aggregate data from a service, or some other not-quite-an-algorithm question.

The RESULTS?

Recruiters figure out what questions you are most likely to ask during the phone interview, and school the candidates.

The assessment test? No one bothers, everyone just hands in the simplest 3rd party libraries plumbed together with shitty code. Was the question select top per group? How about top 1 *? The really good devs shine through here, but a huge percentage don't even bother.

Actual Interview? No one uses IDE / SSMS. All of them choose whiteboard. The ones who genuinely know how to code, have no problem answering, and would be fine answering algorithm questions straight out. The ones who can't, get confused somewhere or other. They try to implement hacks around the problem (I'd have the dba do it), then fail to actually solve the question.

So In Short? I completely understand where this guy is coming from. But I also think, that at this point, I'm so tired of interviewing people who clearly don't care about their craft, that I want to start asking nothing other than algorithm questions... because the guy or gal that actually answers them will actually care about their craft. And at least with algo questions, I can change the question easily, and frequently. Coming up with real code problems, and good probing questions is much harder, particularly if they're going to have a short shelf-life before recruiters start training their candidates with answers.

<comment><USER42> Algorithm questions come in two flavors:

sensible: given the problem statement discuss your initial choice of algorithms and datastructures. This probably covers 80% of tech jobs out there. And you easily dig deeper with big-O and related here. You should have a very good idea if the candidate is clueless or not after this.

other: given a datastructure and algorithm, implement it. This makes sense for a minority subset of jobs/devs.

<comment><USER5> > _given a datastructure and algorithm, implement it_

This can be entirely appropriate for most jobs/devs, depending on the datastructure/algorithm. One of the guys I work with sometimes asks people to implement mergesort. I was suspicious of this question at first but it's been quite good at weeding out mediocre candidates. Mediocre candidates will write broken code all over the board, and more telling, they won't understand why it's broken even when you point it out. Good candidates will generally make mistakes (because no one has mergesort code memorized and coding on a whiteboard is frankly tough), but they'll recognize them, typically on their own and always with pointers, and they'll be able to explain the issue and how to fix it once they see it.

There's no trick to this question. There's no riddle, no "gotcha", and it's not a hard algorithm to understand or code. Just show that you can write minimally complex code and walk through it. It's like fizzbuzz but you can't memorize it.

</comment></comment></comment><comment><USER43> I am just beginning my studies in computer science. I find discrete mathematics, data structures, theory of computation and algorithms to be the most interesting aspects of computer science. If I took an undergraduate algorithms course (Chapters 1-3, 7-9, 11-13, 15-16, 22-24 from CLRS) would I be prepared for most interviews?

I noticed the graduate course overlaps with many of those chapters and also cover: chapters 18,21,25,26, 29-32, 35.

Ideally, I would like to take both courses out of pure self-interest.

<comment><USER44> As others have suggested, get a copy of "Cracking the Coding Interview" and review the questions therein. If you can answer those questions easily, you'll have an easy time at the average interview.

If you want to prepare to interview at one of the top companies, then afterwards procure a copy of my secret weapon: Aziz, Lee, & Prakash's "Elements of Programming Interviews". The questions there are an order of magnitude more difficult. If you are able to apply the CS concepts you are learning to questions of that difficulty, all doors will be open to you.

<comment><USER43> Thanks for taking the time to answer my question. This is my first time commenting on HN and am being downvoted for my legitimate question.

<comment><USER44> Just a helpful tip: mentioning being downvoted is against the HN guidelines and usually attracts more downvotes.

pkahler's sibling post also brings up an important side point: beyond the basic core, what you study really needs to be focused on what aspect of the software industry you want to be in or are likely to find yourself in. While I, too, encourage you to take C/asm courses or whatever your preferred focus is, the bulk of the jobs in the industry are in creating web sites and business systems (much of which are so-called CRUD apps; see [https://en.wikipedia.org/wiki/Create,_read,_update_and_delet...](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)). Even if you plan to do something else, a course in databases and concurrent programming will stand you in good stead as a fallback if your career doesn't quite go as planned.

</comment></comment></comment></comment><comment><USER45> Hiring at most companies is fundamentally broken.

We have no way of knowing if someone will work out, so finding ways to rule people out makes it seem like we did our job in the hiring process. Some Wonderlic-type questions, the person asking them gets to say, "Well, look we have some quantifiable way of measuring applicants." Total BS.

No cure for it, other than to not turn around and be that asshole once you are hired. We should be more open about what the criteria is; hiring comes down to a few gut checks... do you like the person and think they will fit in, do you feel confident that they can do the work you will ask them to do, and are they in your budget?

Unless you work with a person over time, there's not going to be any way of knowing how they are as an employee. If they are smart, if they keep up on current trends, if they are a good communicator (and any good at communicating inside of your organization), if they care, if they show up on time, if they are conscientious or just pass the buck, if they are a hard worker, if they are opportunistic / selfish with praise...

Anyway HR needs to justify itself so we can't just throw darts at resumes... but essentially that's all hiring is. Trying to get a sense of someone quickly, cheaply, and correctly? Nah, just pick 2... at most.

</comment><comment><USER46> Well, you have to understand, the whole point of an interview to construct questions you or at least a subset of the candidates can NOT answer. When there's too many qualified candidates, you've got to weed them out somehow.

</comment><comment><USER47> I must admit I can not really relate. What about somebody who can not FizzBuzz, but claims they can code? Most whiteboard interviews I had were not much harder than FizzBuzz. I was asked to implement Quicksort once, but they gave me the specification, some time and a sheet of paper.

Why would somebody for whom it is easy consider to hire somebody who can not do a seemingly simple thing?

I can understand if somebody has anxiety issues. Then maybe you can negotiate something else, homework project or coding on site for 30 minutes. But odds are you'll discuss stuff with your colleagues on a whiteboard, too.

</comment><comment><USER48> I reject all that too, the recruitment process is broken, it's not even the riddles it is the stupidity of some tests for the "less bright" companies.

But every problem is an opportunity :), now most of my freelance work are companies who "had a problem and couldn't find anyone willing to solve it" and me who asked "can I give it a shot?"

Showing you want to solve problem so far "works for me" much better than doing the guinea pig with riddles

</comment><comment><USER49> Same here, I've stopped doing tech interviews, they are a waste of time. Hopefully my freelancing network will continue to grow and I can avoid them forever.

<comment><USER50> Freelancers do no tech interviews?

<comment><USER51> When I did freelance work, it was all about connections and reputation. "Hey we got some problems with our overnight processing, you've done that before" type stuff.

</comment></comment></comment><comment><USER52> I think tech interviews are broken. I've been on both ends of the equation and the process usually seems both unfair and random.

I work hard, get good reviews, have nice looking work that doesn't crash and scales - and I can't interview either.

I've also interviewed great candidates that get shot for no reason at all.

That said, it is a numbers game, if you need a job keep at it - you have not other choice.

But in the long term I think our community needs to chill out a little bit.

</comment><comment><USER50> The prevalent thinking is that algorithmic skills transfer very well to other problem-solving skills. This is especially the case in Google, Microsoft, Facebook and Amazon who ask a lot of these questions. I do not necessarily agree with it, but it is the way things are.

It's just another skill that can be acquired with proper effort and concentration. I can recommend "Cracking the Code Interview", it is chock full of these problems.

</comment><comment><USER53> "I oppose hiring practices that would exclude me." Really? How profound.

</comment><comment><USER54> Modern interviews are metrics and every smart system (human/AI) will exploit them. Metrics are always exploited. Job Interview is just another profession that requires a lot of training and preparation.

</comment><comment><USER55> I have read these threads for a while now and concluded that people are going to complain no matter what companies do.

I think that while whiteboard nor algorithms nor random questions about technology are perfect, they are still better then vague talking about how passionate one is or variants of beer test. The issue with talking about good code is similar - it matters whether you know the principles, but it is too easy to fake by people who have more talking bluffing skills then anything else.

Personally, I like the best when they tell me what they will ask for, so I can prepare myself - whatever that is. That seems the most fair to me - <USER2> programmer does not know everything fresh, but should be able to refresh or learn something new reasonably fast.

</comment><comment><USER56> I have never, and would never subject myself to the types of sadistic games masquerading as "hiring" that you see at a lot of software companies.

<comment><USER37> How do you find work?

<comment><USER56> Most jobs in this world do not require a laborious interview process with timed puzzles and riddles.

Bear in mind that the companies that do put people through that kind of thing do it _because they can_. When you have people lined up down the street to work for you, you can be very selective in who you hire and put them through all kinds of skill tests before hiring, to triple check that they have the requisite skills. Many (most?) companies do not have that luxury.

<comment><USER37> > Most jobs in this world

You're not US based then? Because I can say with some certainly that most advertised jobs in the US absolutely do. Granted, most open jobs in the US aren't advertised, but I haven't found a way to reliably find jobs that are both open and unadvertised.

<comment><USER56> Sorry, I was referring to literally most jobs, not just the ones in our industry. Electricians, plumbers, writers, accountants, etc. are not typically solving timed riddles and jumping through silly hoops to get their jobs. There will be technical questions, yes, but for the most part their experience is presumed and the employer assumes some risk by hiring them and having them go through a probationary period.

</comment></comment></comment></comment></comment><comment><USER39> I'm truly sick of this rubbish that has been brewing lately. If you can't do interview questions, your ability is questionable. The bar has been lowered enough with the push of "everyone can code and should code" mentality. If we want quality, we must raise the bar. Everyone can code, everyone should be able to code if they want to. But everyone can't qualify for as a professional software programmer. If the company has a standardized interview process and everyone else gets asked the same set of questions, then it's fair. If you can't answer or whiteboard it and other candidates could, Don't cry! Those candidates obviously know more than you in regards to what the company is looking for. Take the case of Google or Amazon, most of us can agree that they have very smart folks working for them. If the filter these smart folks had to go through was puzzles, math problems, algorithms, white boarding, then why should anyone get an exception to join them?

Interviews are broken in most environment, and that doesn't mean we should do away with them or make them easier. Rather, we should fix them, make them better, and have them test what the candidate will be doing on the job. I see people say, "you don't need to understand algorithm complexity to build a website, or to know C or assembly" Sure! But you don't know what you don't know! If you know and understand algorithm complexity, you will use it even when building websites! You will think about scale. If you understand lower level languages and you are using PHP, you might understand how your code turns to C and how choices at a higher level turns to lower level. If you never studied computer architecture, you wouldn't understand the magnitude involved in fetching something from a register, processor cache, ram, drive, over the network. Yet such things do rear their ugly heads when developing these so called simple CRUD apps.

So if you are interviewing for a PHP programming position, and you get asked about algorithm complexity or C or TCP/IP or other questions. Don't frown, those are important questions, if you don't know it, you don't know it. It doesn't mean you are a "bad programmer" but it does reveal that you are a programmer without a wide breadth of knowledge. A one trick pony for the most part. Get over it and widen your knowledge.

The other day I was using an external API that was crapping out. After hitting a dead end, I informed the vendor and they said nothing was wrong. I did a system call trace and noticed a lot of error was being returned on poll(), I fired up tcpdump and noticed an abrupt and random FIN ending the connection. With this I was able to convince the vendor to test their API from outside their network, and once they did, they agreed that the issue was on their end and they fixed it. This was a basic PHP app. Without a wide breath of knowledge, I would have been stuck, no google or stackoverflow would have solved this.

Great developers have knowledge that are wide and deep. If you fail an interview, Don't get mad, get glad that you found your weakness and brush up your skills.

</comment><comment><USER28> I'm kind-of on the fence about this topic.

On the one hand, algorithms is a broad subject, so there's a large hole for false-positives and false-negatives to slip through. Sometimes it's like they'd pass on Gerry Spence as a trial attorney because he flubbed their question on tax law.

On the other hand, can't totally drop the brain-teasers because you'll need all the IQ points you can get before the corporate retardation sets in.

<comment><USER57> Does ability to solve brain-teasers correlate with a drop in "corporate retardation"?

<comment><USER28> Everyone gets hit by the CR, so it probably doesn't hurt to start with a higher baseline.</comment></comment></comment>


Print me a jet engine - <AUTHOR> http://www.economist.com/blogs/schumpeter/2012/11/additive-manufacturing?fsrc=scn/fb/wl/bl/printajetengine <comment><USER2> I'm not really sure what relation the article's headline has to its content - apart from the obvious problem that current 3D printing technology is nowhere near accurate enough for the tolerances involved in a jet engine, I don't think it will _ever_ be possible to print one entirely, as the fan blades are each a single crystal of metal, and that's not a property you can achieve through any 3D printing method (or any incremental building method - they need to be created in one piece)

<comment><USER3> I was thinking the same thing.

They are most likely printing things that 1) don't move, and 2) aren't subjected to any type of stress or heat.

I can't imagine that you can print something layer by layer with fused powder and expect to make anything as solid and tolerant as the normal (crystal) growth and/or casting/molding/etc processes make.

<comment> guard-of-terra In fact powder metallurgy is not new, it's an established and respected way to make various parts including ones for aerospace.

<http://en.wikipedia.org/wiki/Powder_metallurgy>

</comment></comment></comment><comment><USER4> Computer guys are so cute, what with their naivety about the speed of progress in non-computer engineering fields. The article might as well be about terraforming Mars.

<comment> guard-of-terra What's wrong with terraforming Mars? I've read an article about it this week and it was amazing: The gist of it [http://translate.google.com/translate?sl=ru&tl=en&js...](http://translate.google.com/translate?sl=ru&tl=en&js=n&prev=_t&hl=ru&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fvitus- wagner.dreamwidth.org%2F804242.html)

<comment><USER5> Very interesting article, but what will happen if that cover film will be broken in some part by a meteorit or by bad weather?

<comment> guard-of-terra If you read comments to the post, the proposed solutions are: self-healing film for tiny holes; baloons that move with the air flow and plug the holes with their bodies for medium holes; and evacuation to a safe place for a huge holes once in a century. It is a Russian blog so most ideas reside not in the article but down in comments :)

</comment></comment></comment></comment><comment><USER6> While the title is clearly suggesting that an entire jet engine is to be printed. The details of this application as stated in the article point to the specific method of laser sintering, which as a form of 3D printing, is useful to creating specific parts.

This article does illustrate the different methods of 3D or additive printing capabilities, outside of the common knowledge we seem to be exposed to through the maker movement. NASA / Military has also explored a multitude of options with additive printing, battle field printing and space station printing.

In regards to parts such as fan blades, which are mainly composite materials in recent engines, this would not be applicable. Where there are parts that are subject to extreme heat and must retain certain properties, therefore, expensive to manufacture, this process has many benefits as highlighted.

EDIT: In the case of "extreme heat", it may apply for certain types of metals.

[http://machinedesign.com/article/new-superalloys-boost- direc...](http://machinedesign.com/article/new-superalloys-boost-direct-metal- laser-sintering-0824)

[http://www.onlineamd.com/amd-0310-laser-sintered-titanium- eo...](http://www.onlineamd.com/amd-0310-laser-sintered-titanium-eos- shellabear.aspx)

<comment><USER7> In regards to parts such as turbine blades(parts subjected to extreme heats and pressures), which are usually made of single crystal nickel-based superalloys, this would also NOT be applicable. That is until 3D printers have the resolution to print atom by atom....

</comment></comment><comment><USER8> Some part of me refuses to let this go unsaid. I'm sorry in advance.

sudo print me a jet engine

<comment><USER3> > sudo print me a jet engine

 _sudo: can't open /private/IP/license/jet-engine: Permission denied._

 _sudo: no valid Intellectual Property license on file to print object._

 _sudo: contacting authorities, reporting potential IP violation attempt._

 _sudo: locking down local system to preserve evidence... [done]_

 _sudo: quitting. have a nice day._

<comment><USER9> lol, he must have had the 2015 version of Ubuntu ;)

</comment></comment></comment><comment><USER10> I'm already 3d-printing most parts of the RC foamies that I need (except .. the foam materials itself), so .. props, control-surface elements (horns), motor-mounts, etc. So, its at least happening ("sudo 3dprint airplane") on the micro- level.

It will scale, eventually. I guess as soon as someone gets serious about the reproducible nano-compositor/decompositor style of printnozzle..

<comment><USER11> You don't happen to have some pictures or a blog entry about that lying around do you? Sounds fascinating!

<comment><USER10> I don't, but you can see lots of great RC stuff on <http://thingiverse.com/> as well as in the forums of <http://rcgroups.com/> where there are a great deal of hobbyist builders pressing these new techs - as always - into serious use.

</comment></comment></comment><comment><USER12> That's great. I'll wait awhile before boarding a plane with 3D-printed Engine, that's for sure.

</comment><comment><USER13> Print me some food.</comment>


What the interns have wrought, 2018 edition - <AUTHOR> https://blog.janestreet.com/what-the-interns-have-wrought-2018/ <comment><USER3> Kudos to Jane Street for giving their inters what seems to be very interesting projects and for publicly acknowledging their work.

</comment><comment><USER4> It would be cool to start seeing more of this from other companies. Also, I wonder if anyone has done an extensive cost-benefit analysis of using OCaml instead of a more common language. It seems like the training and cost of always needing to build your own frameworks would be exceptionally high.

<comment><USER5> Why "exceptionally" high? The programmers you are hiring are (or should be!) bright, they learn new things fast, and OCaml is not very difficult to learn.

At _any_ software company you have to learn new things. Every company has its internal development stack and custom software, unless the company literally isn't a software company at all or is doing something so unoriginal and dull that you wouldn't want to work there.

<comment><USER6> >>> and [any language] is not very difficult to learn.

I'm all for training and learning, but pretending that anything can be picked up quickly and easily is just wrong, especially in a trading environment.

Any typo or bug is going to cost millions of dollars, it's very hostile to newcomers. They will be struggling enough to learn about finance and the company.

<comment><USER5> > Any typo or bug is going to cost millions of dollars

Good job they're using a language and other techniques which ensure that bugs are caught early, often at compile time.

<comment><USER7> yeah... no. only certain tupes of bugs.

a compiler can't catch a bug if you calculate interest rates incorrectly, for example.

<comment><USER8> Minsky is on record as saying they have a maniacal bent for code review & code readability at Jane Street.

</comment></comment></comment></comment></comment></comment><comment><USER9> > There is, as you can imagine, a lot of ground to cover. With 45 interns > between our NY, London and Hong Kong offices, there were a lot of exciting > projects.

Wait, we're leaving the defense of our realm against mystical incursion to _interns?_

<comment><USER10> Ever use Kerberos? >=)

<comment><USER11> That's 1 dog - they have 3 offices to defend.

<comment><USER12> Kerberos. Not your usual guard dog.

</comment></comment></comment></comment><comment><USER13> What tech interns do at trading companies, especially JS, always amazes me. Not because of the complexity of the problem domain but rather the rigor of the solution.

Something like Tristan Hume's famous blog post [0] on Tree Diffing would be _unthinkable_ at Amazon, or most likely even Google or FB. If it's for internal use, they'd just slap together whatever works and looks nice, test the crap out of it and launch (part 2 optional). Nobody would want to spend weeks minimizing the white space like this, especially over 5 weeks.

I know multiple people who have interned at Trading companies - all making more than $9k a month - working on optimizing React rendering for tables. They have solutions that are amazing and wonderful because they are superior engineers and computer scientists than mere mortals like me, but for the problem space it seems pretty ridiculous.

I know people who have done crazy stuff that has gone into production during their Google, Facebook, or even lesser companies like Amazon internships but were compensated a fraction ($6k a month at Amazon vs. $10k a month at JS). I guess this is the dollar value difference of prestige.

[0]: [http://thume.ca/2017/06/17/tree- diffing/](http://thume.ca/2017/06/17/tree-diffing/)

<comment><USER14> It really sounds like you worship these kinds of companies and the people who work there. Hopefully it's not too personal, but the grass might not be greener on the other side. I grew up in a relatively wealthy family, with extended family coming from poorer backgrounds - and they were just as happy as us. At the end of the day it's up to you if course, I'd just recommend reflecting on what about those companies/people truly is aspirational besides hot "job prospects."

<comment><USER13> I spend too much of my day looking at the LinkedIns and Instagrams of my friends and peers who are at "top companies".

1) They all have legitimate accomplishments. They have USAMO/USACO medals, chess trophies, ISEF distinctions, National Merit Scholarships, multiple research papers, etc. Because of this they are all interesting people and have significant pedigree, even if some of them went to similar schools as me.

2) Almost all of them seem to be very photogenic and have wide friend groups who do expensive activities with them (flying, skydiving, Europe trips, skiing, traveling to Thailand, flying to Colorado for the weekend to hike, etc). Even when they're not spending money they're still doing cool stuff, like going to expensive company events or traveling in business class to events.

3) Their friend groups are _also_ accomplished, highly pedigreed individuals. Meanwhile I moved to a new city without knowing anyone now that my intern cohort moved to better and more impressive companies.

They all have the money to do anything they want without any real fear, whereas I do not. I don't have their wide friend groups at my company, and the lifestyles of the people at my company are decidedly "normal" because of my peers' advanced ages and differing priorities (many have kids and didn't go to elite schools).

<comment><USER15> This perspective is bullshit. You can do anything you want, without real fear, no matter who you are. There's a panoply of literature to help you change your mindset. Seek it out.

> They all have the money to do anything they want without any real fear, > whereas I do not. I don't have their wide friend groups at my company, and > the lifestyles of the people at my company are decidedly "normal" because of > my peers' advanced ages and differing priorities (many have kids and didn't > go to elite schools).

This is an excuse. I am not anything like the friends you described, and I have a wide circle of friends, and do exactly what I want in life. So does everyone I call a close friend. They all come from completely different backgrounds. It took years of hard work to get here. Start now.

Sorry for the off-topic post in this thread, but I think it's deeply important to refute this kind of thinking. Don't waste your life.

<comment><USER13> Well, for one thing they can do it at 22, with no constraints on the function they're optimizing. Their hard work was done in 4 years of undergrad and 4 years of high school. I thought I did OK - but apparently I didn't, and now I have another 8-12 years to even begin to be in the same position they're in right now. I'm way, way way behind.

<comment><USER16> This is the sort of race where once you get to the end, you realize you were racing against yourself. Stop comparing your blooper reel to their highlight reel. It's not healthy. I guarantee there are people envious of your life.

</comment></comment></comment></comment></comment></comment><comment><USER17> Where the interns paid, at a market rate? This seems like legal documentation demonstrating that they were working on core development for the firm. So without fair pay, that is illegal is it not?

<comment><USER18> Jane Street pays interns a little more than $60/hr. Pretty competitive. Definitely in line with unicorns and big tech ($50/hr @ FB and AirBnb, $45 @ Apple, etc)

<comment><USER13> Airbnb is ~$40 an hour but they have unlimited overtime.

From what I've heard Apple starts at $38 an hour.

FB isn't hourly, it's $8k a month.

Amazon is $7.725k a month or $7.2k if you take corporate housing. It's more in California and NYC - $8.4k a month, or $7.9k if you take corporate housing.

<comment><USER19> I was told Amazon interns also had to pay $300/mo for not particularly nice corporate housing in the UW dorms. My understanding was this was in additional to the salary reduction.

<comment><USER13> Nope, its only a salary reduction. In addition, they get a "husky card" with a daily stipend for on-campus dining hall/food court meals/gym entrance etc - <USER2> few friends of mine took it and they said the value of the husky card was more than $300 if they spent all of it.

Also, UW Dorms are only for summer interns. Off cycle interns live in 1 bedroom apartments in SLU. They're _really nice_ with a $500 salary reduction.</comment></comment></comment></comment></comment>


Plot to steal cryptocurrency foiled by the NPM security team - <AUTHOR> https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm <comment></comment>


Mapping Who Lives in Border Patrol's '100-Mile Zone' (2018) - <AUTHOR> https://www.citylab.com/equity/2018/05/who-lives-in-border-patrols-100-mile-zone-probably-you-mapped/558275/ <comment><USER2> Unfortunately, the map isn't accurate. The actual definition of the "100 mile zone" comes from 8 CFR 287 (see [https://www.law.cornell.edu/cfr/text/8/287.1](https://www.law.cornell.edu/cfr/text/8/287.1)), which says:

> The term external boundary, as used in section 287(a)(3) of the Act, means > the land boundaries and the territorial sea of the United States extending > 12 nautical miles from the baselines of the United States determined in > accordance with international law.

What does that mean? That means that the 100-mile radius does not start from the Chesapeake Bay, it starts from about 13 miles off the Eastern Shore. Washington, D.C., for example, is not within this zone. Nor is Chicago or any part of Illinois within the zone--Lake Michigan doesn't have any 12-nautical mile basis to start counting from.

<comment><USER3> The ACLU, MIT researchers, think tank representatives and the border patrol itself contradict your claim in the article.

[https://www.law.cornell.edu/uscode/text/8/1357](https://www.law.cornell.edu/uscode/text/8/1357)

[https://www.aclu.org/other/constitution-100-mile-border- zone...](https://www.aclu.org/other/constitution-100-mile-border- zone?redirect=constitution-100-mile-border-zone)

<comment><USER2> Neither of your sources clarifies the interpretation I gave or offers any sort of refutation. The link I gave and the text I copied provides the definition of "external boundary" for these purposes.

<comment><USER3> The 100-mile border zone is being enforced. Are you contradicting the news articles, videos and other first-hand accounts of raids taking place far from the border? The evidence is right in front of your eyes.

<comment><USER2> I'm not disputing that there is a 100-mile border zone.

I'm disputing that the depiction of the border zone is inaccurate with respect to the water borders, which greatly skews the map around the Chesapeake Bay and Lake Michigan.

If you want to convince me that my interpretation is wrong, please either:

a) Provide a link to a court ruling or CBP interpretation that the 100 miles starts at the _coast_ and not the international waters boundary at 12nmi, or

b) Provide a link to evidence that checkpoints are being conducted under the provision of this regulation that are occurring within 100 miles of the coast but not within 100 miles of the international waters boundary.

<comment><USER4> The ACLU page includes the following claim:

> And still CBP cheats its way to more interior encroachment, for example, by > claiming that the Great Lakes shared with Canada are "functional equivalents > of the border" so that all of Michigan and Chicago are in its reach.

Unfortunately it doesn't seem to provide any support for that, but presumably they have some basis for saying that.

<comment><USER5> Lake Michigan is not shared with Canada. Chicago is not within 100 miles of Lake Huron, Lake Erie, or Lake Superior.

<comment><USER6> I'm sure it's not legally relevant but, hydrologically speaking, Michigan and Huron are a single lake.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> In an odd coincidence, while I was reading this I received an email announcement about a Cato Institute event on February 4:

"America's Border Wars: Inside the Constitution-free Zone"

[https://www.cato.org/events/americas-border-wars-inside- cons...](https://www.cato.org/events/americas-border-wars-inside-constitution- free-zone)

They will be streaming the panel discussion for free on their site. Should be interesting!

<comment><USER8> Warning: the cato instituit is a "libertarian think tank" funded by the koch brothers. Be very wary of their particular biases

<comment><USER7> Everyone is biased, and the Cato Institute makes no secret what their biases are.

Personally I prefer to get information and opinions from a wide variety of biased sources, instead of trusting some news institution that pretends to be unbiased.

<comment><USER8> I wasn't suggesting who to trust. I just know that I personally wouldn't trust an organization founded by the Koch brothers to be honest debators, and I know I'm not the only one who would want to know they were involved.

</comment></comment></comment></comment><comment><USER9> Is this how the inland CBP checkpoints are allowed to operate? For instance, there's one on I-5 near San Clemente, CA, and another on I-8 near Yuma, AZ.

They've never been open and actively checking cars when I've passed by, and I heard that they're only used when looking for vehicles that match a tip they may have received, but I have wondered about their authority.

<comment><USER10> Have they shut down?

A few years ago I frequently traveled through Yuma and San Diego, and twice through New Mexico, and those checkpoints were always open.

<comment><USER9> They still exist and are staffed with officers in the building and patrol cars outside, but I've never seen the I-5 San Clemente one actually checking cars. According to some Google Maps reviews, they only use it when a relevant tip comes in, so perhaps I've just been lucky. That being said, I don't drive through the area extremely frequently. It may have been around 5-7 times in the past year.

</comment></comment></comment><comment><USER11> I am not lawyer, however the border-zone sure seems unconstitutional to me...and if arguments for it Constitutionality rely on the idea that the border zone represents a very restricted edge case, then this excellent article clearly makes that position a farce.

<comment><USER12> IMO, the idea was that smugglers passed the border and now are moving inland. They should not be safe just because they crossed that line. So they drew another one. In general a good idea but as always the government abuses it.

<comment><USER13> If the line was say 5 miles you might have a point. But, 100 miles is long enough to basicly be meaningless.

<comment><USER14> Agreed. Having a zone is reasonable, otherwise people could make it a mile over the border and CBP would have limited enforcement ability.

However, 100 miles seems excessive.

That said, it's more complicated than "a 100 mile constitution free zone". CBP can have checkpoints and can briefly question people, but they can't search a vehicle without a warrant.[1]

[1][https://en.m.wikipedia.org/wiki/Border_search_exception](https://en.m.wikipedia.org/wiki/Border_search_exception)

<comment><USER15> Sure, but then there are the warrant issuing dogs.

</comment></comment></comment></comment></comment><comment><USER16> I note that the number of non-deportable detentions are well above deportable detentions.

So it certainly seems like the CPB check points are now primarily being used to spot check for crimes other than immigration. If so, it seems that the special rules in the border zone are already being widely used to extend search and seizure beyond what would be legal outside the border zone. Perhaps this is being justified as yet another semi-exception to the constitution in the name of the endless war on drugs.

</comment><comment><USER17> A few years ago, the CBP was tracking private aircraft on state-to-state flights and searching them without warrants on questionable grounds [0].

[0]: [https://www.aopa.org/news-and-media/all- news/2013/june/19/ao...](https://www.aopa.org/news-and-media/all- news/2013/june/19/aopa-demands-answers-on-aircraft-searches)

</comment><comment><USER18> Hasn't there been a single case that has gone to the Supreme Court over this in 60+ years? Or do they just refuse to hear them?

<comment><USER12> Judging by what ACLU says, asking about your alien status is all legal. After all, USA does have a lot of immigrants staying illegally. We need them etc., but the agency is tasked with removing them and stopping the flow.

The main problem is not the law, it's DHS doing illegal stuff: [https://www.aclu.org/other/constitution-100-mile-border- zone...](https://www.aclu.org/other/constitution-100-mile-border- zone?redirect=constitution-100-mile-border-zone) _" The Supreme Court has upheld the use of immigration checkpoints, but only insofar as the stops consist only of a brief and limited inquiry into residence status. Checkpoints cannot be primarily used for drug-search or general law enforcement efforts. In practice, however, Border Patrol agents often do not limit themselves to brief immigration inquiries and regularly conduct criminal investigations and illegal searches at checkpoints. The Border Patrol also frequently pulls over motorists in "roving patrol" stops, often without any suspicion that an immigration violation has occurred."_

</comment></comment><comment><USER19> It's funny how this thing was ignored for 4 whole presidential terms but now it's suddenly a big deal.

</comment><comment><USER20> There's so much fear in the US of A :( And you don't have to be Yoda to realise what fear leads to...</comment>