You're not alone. The more experience I get, the more I feel that specifics in a language are a commodity, but what you do with that language is what matters.
Those abstractions, identifying problems, talking with peers, deciding the next step, etc. The language is not the problem, you will learn it.
With time I got to know more core concepts but I don't know the syntax of whatever language the interviewer's company is using. It is nice to find people interviewing you who care more about what you're trying to say than the syntax.
That's a problem with... "people looking for shiny things". There are many shiny things, and they loose their shine quite fast.
It is true that many managers, recruiting agencies (almost 100%), and HR, will look for the keywords of the technologies the company is using. So if they use the new Angular 4, they will look for that.
But there are companies that look for the basics: do you know javascript? Have you worked with SPAs? And these are the ones that IMHO deserve your time to apply.
Because tomorrow, today's current trends will be tomorrow's trends. Companies looking for people that can adapt say a lot about what kind of work place will you find there.
They're not particularly difficult. You usually take the algorithm definition and implement one, as you did in the university or in the Coursera algorithms course. Fun, you might learn a thing or two about the language you're using.
If the point of the exercise is a TRIVIA question, leave the interview. On the other hand, if the point of the exercise is not to get the right solution but see how you think and how you use basic programming blocks, then you're in the right place.
I've used the linked list question. And the goal is not for me to check if it is "not difficult" for you. Because I might not be able to teach you what a linked list is in 5 minutes while you're nervous in a technical interview. But to work on technical problems and see the following:
- Can you speak your mind so your peers know what are you doing?
- Will you ask for help?
- Will you accept help and feedback?
- Can we have a discussion about something that there are many "right answers"?
- Do you know the basic building blocks of the language you decided to use? <-- This plus javascript plus references is very funny.
"Whether passing an algorithmic technical phone screen means you’re a great engineer is another matter entirely and hopefully the subject of a future post."
This sentence plus the inverse correlation between experience and "interview performance" shown there. Makes a big smell about how biased are those interviews to themselves and not to real technical interviews.
From the data it looks like the questions asked using that service are the ones you might learn in university and after many years not using them, that knowledge fades away because you're not using it.
This is reinforced by MOOCs being the 101 of the subject they're dealing with. It would be interesting to see if there are trivia questions from 101 courses.
The most obvious bias is in the clickbait title. Those 3K interviews are in a specific platform, meaning they're done in a specific way.
So after checking their results it seems that interviews done using that service benefit people with fresh university or 101 lessons knowledge.
What worries me more is the lack of improvement and perhaps the moral superiority of ending the article with a "these findings have done nothing to change interviewing.io’s core mission". It feels like the entire statistics game shown there was to feed back what they already knew.
Wow, that was a nice piece of rhetoric. Mixing race problems, employer/employee power imbalances and gender issues. So you manipulate the feelings of reader while putting gender issues inside. Good appeal to emotion.
Sexism is still an issue. When decisions are justified because penis or vagina.... it smells sexism and not equality or rational thinking or science. Politically correct speech dominates the media and makes you feel that you're doing the right thing while you're at being a bigot. Power protects bigots too.
Allow me to remove capitalism and racism to focus a bit more in the agency issue.
Shanley is more privileged that the person that was fired. She runs a media outlet (Kudos! good for her), and a lot of people know her and read her. She influences people, she has power.
She used her power to defend herself about a tiny speck on the internet that called her names, and even understood that it wasn't right. I cannot find anything more abusing than being in power and inflicting pain. That is not even justice, it is hatred.
I would say that defending that hatred is chauvinism.
When that offended woman calls names and other bullshit to other people, she is fighting oppression. When it is another person calling her names, she is the oppressed and more than that... she will create a pogrom against that guy.
A pogrom is not basic human rights. Calling names is just an ad hominem and swearing an appeal to emotion. Both seem to enjoy it.
I totally agree with you it is a class issue. May I put it in other words? an asshole issue. How to behave around other "human beings" has been forgotten and a culture of attacking the different has evolved.
Why? Perhaps to protect the individual ideas and create echo chambers where people feel "safe" from criticism. Although without criticism (critical thinking), and without dealing with real world evidences... I fear we're getting nowhere.
It is a pity that something as MRAs exist: why should anyone need a specific gender movement to protect its rights. It is a failure that MGTOWs exist: why should anyone hate the environment created around its gender.
I recommend you to take a look to the "Growing object oriented software guided by tests" book.
The first assumption you made is about TDD being only unit tests. What if TDD is not only unit tests? It could be that TDD is used in many levels, therefore when you do a more high level test, like an end to end/functional/system test, and there should be at least the idea of that system to start with. It doesn't appear suddenly.
The previous book applies TDD in that way: You get what the system has to do, prepare an idea/design of how the system has to do it and validate it through code. Of course that code is written test first.
Thus experts do not promote TDD only on units, thus "no design at all". You will find the no "BIG design upfront" though, but this is a different matter.
I would prefer this post stays as an example of how not to do a post about the testing pyramid. Martin Fowler post/article is better IMHO, and I'm sure there are much better posts.
There are some good ideas mixed with fallacies and disdain/contempt. These are not good in any discussion.
In a positive way I miss some examples of "hurting my designs" and "what that approach is doing to the integrity of your system design". Why TDD is doing that? Could you show me where do you have problems? That would be a nice piece of feedback to learn.
The post feels like a rant mixed with fallacies and a salt of contempt. I'd expect it from Zed Shaw. I'm sure Zed could do it much better.
TDD is dead and the third word in the post is "fundamentalism". Yes, nobody can say that fundamentalisms in tools are good. Every tool has its use cases. Although it doesn't justify the "TDD is dead" motto. Correct me if I'm wrong but it looks like a "Straw man" fallacy. Half of the post is dedicated to build a straw man of fundamentalism nobody can deny.
The other second half is focused in unit tests. While he talks about "Test-first units", all unit tests (written before or after) have the aforementioned issues. Unless they're not unit . Thus we're introduced to other tests types that are not unit.
@programminggeek in a previous comment talked about this, is the test pyramid (http://martinfowler.com/bliki/TestPyramid.html). In this moment the conversation is outside the TDD scope, but discussing about how good or bad are different kind of tests.
Again, nobody can deny the benefits of having different test types and not only unit. IMHO is a another red herring fallacy.
So what did I get from it?
- Fundamentalisms in tools/paradigms are bad.
- DHH has some problems in his designs he cannot unit test.
- Using only unit tests is bad, you need more high level tests.
- Try capybara.
Those abstractions, identifying problems, talking with peers, deciding the next step, etc. The language is not the problem, you will learn it.
With time I got to know more core concepts but I don't know the syntax of whatever language the interviewer's company is using. It is nice to find people interviewing you who care more about what you're trying to say than the syntax.