freeCodeCamp

I just went through my bookmarks and quite a few of the links are dead... I've been doing this for decades so that's not a surprise. And not really a big deal. Most of the progress I've seen has been made in the last five or so years. Technical interviews might be horrible now, but they used to be way worse!

A LOT of the articles I've read over the years I have not bookmarked because my idea of a good technical interview is the opposite of what those articles recommended.

I normally read everything interview related I come across in HN or Reddit programming subreddits but I'll also do a search every six months or so and see if anything interesting comes up.

Although I have cherry-picked advice from reading many articles over the years, more importantly I've tried really hard to come up with an interview process I myself would enjoy as a candidate. That factor is very important to me because I think the interviewing process sucks at many companies. It's painful for everyone involved and ineffective. I would tolerate painful and effective. But I think it can be somewhat painless and effective.

I remember getting at least a few valuable ideas from these:

http://firstround.com/review/The-anatomy-of-the-perfect-technical-interview-from-a-former-Amazon-VP/

https://www.wired.com/2015/04/hire-like-google/

https://medium.freecodecamp.org/we-analyzed-thousands-of-coding-interviews-heres-what-we-learned-99384b1fda50

Also ask someone in HR what soft skills you need to improve…

The right number is zero and a UBI until they figure out how to stop being jerks. (My primary personal reason for supporting a UBI is I want to be able to say "No rational employer should employ you" without that implying "so you should be homeless and starve.")

But short of that, the right number is zero on the interview circuit. You can employ jerks if you have to, but don't put them in more positions where they have to interact with others than necessary. Give them the legacy products where you can't staff a team of more than one qualified person anyway. Give them an office. And keep the door closed.

Remember that a jerk is basically a 0.1x developer - an employee who causes other employees to lose productivity by spending time working around the jerkiness, taking a morale hit, etc. Even a remarkably productive jerk at best only compensates for their negative effect on people they work with, and most jerks are not consistently remarkably productive. https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde is a good example of a company learning that lesson a little too late. A company that signals that they trust their jerks enough to make hiring decisions and to represent the company's culture to potential new hires is a company that signals they're actively cool with jerks (or incapable of noticing, which has the same effect).

If a jerk makes a good employee unhappy and they leave, the jerk is a net negative. And if you keep…

While there are many great reasons to learn languages like Scala and Kotlin, "Java is old" is not the right one (for one, it's false).

The functional programming elements in Java 8 (<4 years old) do make it a new language. I've been keeping up with Java since V1.4, and I felt like Java 5 was the update that made Java a modern language, but Java 8 brought a paradigm shift (if you felt like changing your style).

And in any way, the title is misleading. It should have been "Kotlin: here is why we think it's better than Java 5" - because that's the actual content of the article.

I like learning about new languages, but I wish the article had more. For instance, it doesn't mention functional programming paradigms (the new thing in Java 8), even though Kotlin does have them, e.g.[1]. That's one way to improve the article beyond the title.

[1] https://medium.freecodecamp.org/my-favorite-examples-of-functional-programming-in-kotlin-e69217b39112

Great post, but lofty.

Here is an example of a relatable situtational system thinking in the very small:

https://medium.freecodecamp.org/how-to-organize-your-thoughts-on-the-whiteboard-and-crush-your-technical-interview-b668de4e6941

I havent read much on the theories, but part of my write was also inspired by two books and hence why I am responding to help others. Pragmatic Thinking and Learning by Andy Hunt and The Fifth Discipline by Peter Senge helped me with this type of thinking.

A few things key concepts. Organization of related systems and their interaction patterns. But a key, that you are also apart of the system as you interact.

For instance, the causal link of bringing sweet smelling dry erase markers. You could shift the whole system of interview rating based on memory of smell on that sweet expo choco mint as you erase your complex mistakes away.

Or they could think that you're just crazy.

For editing, one thing that has helped me is learning sales copywriting and direct response.

Copywriting forces you to trim the cruft and makes you take the reader's perspective. Their time is valuable so you need to be entertaining and engaging, AND you need to get to the point fast.

Tested Advertising Methods & Scientific Advertising are just some of the classic books about sales copy.

I don't know what topic you're writing about, but sometimes you really just need to get your work out there, despite it not being perfect.

I spent too much time writing and re-writing this article on procrastination (https://medium.freecodecamp.org/procrastination-sucks-so-heres-the-eat-that-frog-way-to-powerful-productivity-543b07ecf360) till I finally said "f--- it, I'm going to write this last section about finishing and shipping, then hit the publish button"

Yeah, there's some truth to that. There was actually a good article and related tweets by Justin Falcone a few months ago on that topic [0][1][2], which are excellent reading.

That said, I'm always looking for ways we can make it easier to get started with Redux, improve the learning process, and make the ecosystem better. I filed an issue earlier this year to get community feedback and discuss how we can simplify things [3]. Please feel free to add suggestions to that issue. I'm also always open to ways we can improve the docs as well.

[0] https://medium.freecodecamp.org/whats-so-great-about-redux-ac16f1cc0f8b

[1] https://storify.com/acemarke/redux-pros-cons-and-limitations

[2] https://twitter.com/modernserf/status/886426115874717697

[3] https://github.com/reactjs/redux/issues/2295