I feel your pain. I've got similar amount of experience in my own area, I've been part of several successful software projects, and I have several popular open-source projects that I'm maintaining, but it all seemed to not matter a whole lot as I slogged month after month through interviews with rejection after rejection.
All I can say is that perhaps all those places that reject you are not actually the places where you really would like to work.
At one point I managed to get a job at a company which from the outside looked like a really cool place to work in. However all these interviews painted a very different picture of the work that I was actually assigned to do. I felt like I was being paid a senior engineer salary to do the job of a junior engineer. I was utterly bored and I complained that it's too boring and way below my skill level. This ended up getting me fired. Strangely, I've never had so many work-mates expressing to me how sad they are that I'm leaving. Several of them left the company not long after me.
Currently I'm in a happier place. Not getting as big of a salary but having an opportunity to work on a way more interesting software. And how did I land this job... after a single short interview they told me: would you like to start tomorrow?
I find that take-home assignments are very one-sided form of an interview:
- The candidate needs to do lots of work while the company gets away with little to none.
- The candidate never knows what exactly the other side will be looking for, so the only way is to put in more work. Like when the assignment didn't ask for tests, they might still be expecting them.
- The candidate usually gets no feedback about the work he did. More importantly he usually doesn't get a chance to defend his solution. It's either great or garbage.
- While the company can learn something about the candidate, the candidate will learn nothing about the company by doing the assignment.
I get a feeling that it's more of an art project. The voice-over is over-the-top artificial, reminding Stephen Hawking. The demonstrations of the objects are well executed, but content/education-wise on the level of it's so bad that it might actually be good. And of course, the obsolescence of several of these things is very questionable, let alone being able to accurately identify a year since something became obsolete.
It's like saying you should not need to know about ancient Greece history to participate in marathon running. And the truth is, you don't. You can easily learn the present meaning of a word without fully understanding its etymology.
There are countless words and idioms that will make no sense when you're not familiar with them. You could consider these annoying, or you could consider these the interesting parts of a language.
I for one very much like words with interesting history.
Fair, but marathon doesn't have the additional association of "white = good, black = bad" which is, to say the least, somewhat insensitive given current events.
I'm aware that I'm moving the goalposts a little bit, or at least making them more explicit. Sorry? Just trying to voice explicitly why my (admittedly subjective) stylistic sense is going "Eh, this one is better off replaced by explicit terms".
What's wrong with squash-merges? As long as your merge requests aren't enormous, squash merges keep your commit history clean, instead of being polluted with tons of commits with the comment "fixed typo" when most of the real work is in a single commit or two. When I'm reviewing someone's MR, I do not want to wade through dozens of very minor commits that are probably already fixing the things I would have complained about.
And what's wrong with merge? How do you even use git without merging?
In theory I don't mind them. In practice I've found that I more often encounter a scenario where I wish a change had been split to smaller commits rather than the scenario where there were too many commits to go through.
Anyway... I intended my example as an explicitly anecdotal evidence to counter the seemingly absurd suggestion of using Git without ever using merge. Feels like going back to subversion or CVS.
All companies I worked in for the last 10 years used squash-merges exclusively, combined with trunk-based development and small commits. I don't see anything wrong with that, it's nice to have a history where every other commit is not a merge commit.
Merges make it prohibitively difficult to go back in time because they create alternative versions of history. There are many negative aspects to this, but I will use git-bisect to illustrate the problem.
For more reliable code-bases you want to do the following:
* Run tests on each commit when accepting PRs.
* Be able to remove or edit intermediate commits, if you find that they've created problems afterwards.
* Only have one path from past to the future.
This is so because if want to use git-bisect, and instead of deleting faulty code you reverted it, the command will keep failing on the code that you've already fixed, and there's nothing you can do about it. git-bisect also has to follow one and only path from the past to the future because if you don't, then, at best, you get an combinatorial explosion of possible paths git-bisect may take, and at worst, some of these paths will fail, but others will not.
So, what ends up happening is this: people who use merges are like people who never clean up their apartment. For some it will take longer, than for others, but, inevitably, the apartment will become a filthy mess. But this is just a symptom of people being afraid of not understanding their code, being afraid of making big changes, undoing things committed to long ago.
This fear is usually an indication that people aren't good at the technology they are using. They would be too afraid to delete code because "what if it breaks something?" -- and nobody can tell authoritatively "no it doesn't". In a situation like this any change in technology s.a. using a different version of the same tool, or replacing the tool altogether will be almost impossible to implement because of the fear.
It's also usually very characteristic of places like this to be afraid of knowing / learning the underlying technology, the one that supports the entire company's stack. Eg. if it's a Python shop, then they'd be opposed to writing Python modules in C, even though this is how Python typically works, because they are afraid that they won't understand this code and one day will end up with a "magical" program that sometimes fails, but nobody knows why.
It's also usually the people who won't even try an unpopular technology, even if the benefits were huge, based on their fear of not having expertise to deal with it. Eg. XML schemas are hugely superior to JSON schemas, and if you want to validate your inputs, XML is just a better tool for this, but the company I'm describing will never consider using it because they are afraid of not being able to find people willing to work with DTD / XSL / RNG.
Such a company will never consider self-hosting, and will pay through the nose for the expertise of others, being mortally scared by a prospect of running their own infrastructure.
----
And... this is the majority profile. The problem is, this is not a winner's profile. It's a scrapping-by profile. It puts an individual programmer in the situation where there's no need and no reward for bettering themselves. Where management is antagonistic to programmers because they are in a conflicting situation, where on one hand they want to give customers more stuff, but on the other hand they are too afraid to make more stuff, since it may deprive them of the stuff they already have. So programmers are punished whether they do or whether they don't. It's where cargo cult flourishes. Basically, Dillbert comic before its author went into politics.
> [programming] should be an iterative, interactive process that anyone can do. It should be more like painting...
You mean like taking years of rigurous practice to master, requirering specialized equipment and expensive materials plus an education in color theory, composition and art history :)
Toddlers do not do this in Japan. People deeply misunderstand this show.
It's carefully monitored and setup. The kids don't know it. They are genuinely doing the things on their own. But it's not like the parents then rely on the kids to go do those things independently after the show.
They are more independent at a young age. But you don't see toddlers walking around Japan unattended to shops.
The article says this much too. While I never saw any actual toddlers running errands on their own in Japan, I did see children 5-6 years old doing it.
To be fair, when I send my 4 year old to the closest shop, my concerns have absolutely nothing to do with the safety of the environment (e.g. actions of others), and everything with how much I trust him not to be an idiot.
If we had a shop only two streets over it would be doable at that age.
It's well worth a watch to see how small kids act when they think they're not being observed. And also for the hilarious footage of how oblivious they (mostly) are of the swarms of camera people running in front of and after them...
If you ask for it... I've been hunting for a job for more than a year now. Well, perhaps not hunting as I haven't sent out nearly as much resumes during that time as the author of this story. Though when I do apply, I usually also get to an interview.
The interviewing causes a lot of stress to me. Even though I have never failed a coding interview, I utterly hate doing these. (Thankfully I've never had any hard leetcode problems thrown at me - I would have failed miserably.) I have also been a lot on the other side of the table, though I found even that to be a big source of stress to me. I personally believe these coding tasks are only good for filtering out the bad candidates - you can't use them to find great candidates. The last big company I worked at gradually steered towards harder and harder coding problems, until one day I just pulled out of the interviewing process as I felt that I personally would no more get hired.
I wish more companies would be more flexible in their interviewing process. Like, I have several open source projects which mostly revolve around various forms of static code analysis - why do I need to prove that I can write fizzbuzz?
Recently I had a pretty nice coding interview where the main task was not about me writing code, but instead reading the code that a junior developer had written and helping him sort out why the code doesn't work and how to improve it. This was the most real-work-like task I've experienced, I even found myself enjoying it.
Most of the rejections I've had have been along the lines of: "While we find your technical skills excellent, you don't really look that motivated / we think we might not have the right kind of challenge for you."
So, I'm in a bit of a dilemma. If I would strive to send out more resumes, most of these jobs are likely something that I'm not overly excited about, and so I will get rejected because I don't look committed enough. But if I try to look for a dream job, then that will likely never happen. I feel like I'm doomed either way.
During this whole job search I did get one offer, but I rejected it, as I heard rumors about the owners of the company being complete assholes. (Like monitoring workers through security cameras to make sure they're working at their desks.)
Thankfully I've had enough savings from my previous employments and I tend to live a fairly cheap life. Nevertheless, my savings are starting to run low now, which adds pressure to finally find a job. Well, I still have the option of selling my second house (so I'm still far from being financially ruined).
I think there are pros and cons to both approaches:
- Explicitly spelling out the column names has the advantage that you can search your code base for that name and see where it's used.
- When declaring a view which filters the rows in a table, using SELECT * would simplify maintenance, as you wouldn't need to update the view when new columns get added to the table.
You seem to assume, that one can know what the impact of one's actions will be. That's basically asking for the ability to predict the future.
I don't want to imply that the outcomes don't matter. But at least I prefer living in a justice system where planned murder and fatal accident are not considered as equal offences, although outcomes might be the same.
All I can say is that perhaps all those places that reject you are not actually the places where you really would like to work.
At one point I managed to get a job at a company which from the outside looked like a really cool place to work in. However all these interviews painted a very different picture of the work that I was actually assigned to do. I felt like I was being paid a senior engineer salary to do the job of a junior engineer. I was utterly bored and I complained that it's too boring and way below my skill level. This ended up getting me fired. Strangely, I've never had so many work-mates expressing to me how sad they are that I'm leaving. Several of them left the company not long after me.
Currently I'm in a happier place. Not getting as big of a salary but having an opportunity to work on a way more interesting software. And how did I land this job... after a single short interview they told me: would you like to start tomorrow?