Most companies that people put up as examples of asking "fundamentals" that are unrelated to the job, actually don't at all ask candidates to regurgitate fundamentals. Instead they ask them to solve a programming problem, which commonly requires them to apply their knowledge of some very basic fundamentals. This is very different. "Very basic" is important to note here, because almost no companies nowadays ask anything other than very basic application of common data-structures. If we are sticking to the music analogies - this is closer to asking a musician to perform a well known piece of music from a sheet than regurgitate esoteric music theory.
The performance part might be a problem for some people and I agree - programming is not music, and it's tricky and unnatural to program in front of an audience, but this is a completely learnable skill by practice. That said I agree that it will always penalise a subset of people who will always perform less good under pressure.
There is a flip side to this though which often goes overlooked and author hints at it: programming interviews are a great equaliser - there are no credential checks (or they are getting much less common) for getting into top companies, and you can be based almost anywhere in the world - all you need to do to get in is crush the coding interview which is totally a learnable skill. This has opened many doors and economic opportunities for people that did not have them even a decade ago, and I think we as an industry don't talk enough about the opportunities our attitude to barriers to entry create.
Finally there's the question of whether the skill tested in coding interviews are really unrelated to the job performance. I've seen arguments that state: "some data shows that how a person performed on the interview is unrelated to how they perform as an employee". But this kind of reasoning almost certainly suffers from selection bias, as we'd really need to include how people who did not pass the interviews perform at the job (for obvious reasons companies don't have this data). I would bet that there would be a much stronger link with interview performance in that case.
Overall I think it's more likely that coding interviews are the way they are because they work extremely well in practice, most of the time. They are also on average a massive equaliser and overall a good thing for almost everyone involved provided they are executed well. They do have their problems, but commonly proposed alternatives (like take home tests etc.) have problems too. Coding interviews are not a thing because there is some kind of collective madness in the whole industry, where people in charge of procuring the most expensive resource just can't help themselves succumb to group-think. They are a thing because they work well (but not perfectly).
While this may not be inviting to you, I think there is a flip side to the "wide-net" that big companies cast on LinkedIn and such. Instead of just hiring from a pool of "well-established" candidates, they give a chance to a wide variety of people from different backgrounds - as long as they can pass the interviews.
This may not sound like much to anyone who is established in the industry or happened to be in the right places for a good career head-start, but for people coming from non-traditional backgrounds, industries and especially places where there's no tech - being able to study-up and land a job at some of the most well known names in the industry can be life-changing. I think this is a very under-appreciated side effect of the "recruiter spam" from FAANG that everyone seems to dislike if they can afford to.
Right, but as the article points out - you get compensated (10x) better for it in the management track. There are outliers of course, but they are just that - outliers.
He actually does go into that in the "Some side notes" part. He recommends calling it a monad only when you actually use the monadic interface:
“I have to directly use the result of one IO action in order to decide which IO action should happen next”: Yes, this is a use case for IO’s monadic interface."
Then yes - you need the do-notation.
For simple sequencing he recommends to use it's Applicative instance.
Your overall point is correct though - choosing to avoid the do notation in Haskell will likely limit your ability to read and understand a lot of code just because monads are so commonplace in Haskell.
Nice explanation. I'm surprised that no one so far mentioned a cool trick for getting around this using a different way to define mappend as function composition, to make sure ++ is applied in the right order, since it's from LYAH (scroll to end of the linked chapter):
They may do that - however running tests on every single push is not exactly resource free, and I have a hard time believing Github will offer it for free. And Semaphore's integration/UI seems pretty seamless already.
On a side note - I know some of the guys behind this - solid team that will go above and beyond to make you a happy customer if you sign up. I believe this alone could be a significant competitive advantage.
I interviewed with these guys a while back but ended up doing something else in the end.
I obviously never worked for the company, but the interview process was really interesting (also professional) and it seems like they really care about who they hire. Thumbs up for that.
>I have a colleague that writes firmware on windows XP, which with his various drivers and Eclipse problems causes a BSOD about once a fortnight. I keep offering him to get a new computer, cards, whatever, and he refuses because of the cost to him in terms of getting his environment set up 'just right' again - he's quite picky (at my previous workplace, a digital circuit designer on six figures didn't want to move from his PIII to a Core 2 for the same reason).
I've seen this before (and was guilty of this kind of thinking a few times) and I believe this is simply misguded. No matter how good of an "old-school" developer someone is, she needs to keep her tools fresh. To me this is no different than having a very manual build or deployment process (maybe not as bad but still).
I believe when it comes to HW + toolset for development, you simply must consider:
-Computers break - you need to be able to set up a new one in a matter of hours (or 10s of minutes). Maybe it does not need to be this drastic everywhere, but if your computer breaks and it takes you a few working days to get it just right - something is wrong - you need to automate it or reconsider the tools (which may not be always possible especially in embedded/hardware design world). If you get this right - upgrading will not be (such) a problem.
-You need to keep up with the tools - maybe more than you need to keep up with the libraries. With this I don't mean only the newest versions, but to constantly be on the lookout for the better alternatives - blogs, forums etc. there is simply no excuse for not doing this if you are a developer other than laziness. This will help you get rid of some stuff on your machine you don't actually need because you may end up with better alternatives. I am a firm believer in getting rid of clutter in your life.
Not all devs in all companies can follow these, of course, due to policies, the nature of work, "legacy stuff" and whatnot, but it helps a lot if you can, and point 2 means you are learning - so you are not bored.
I just wanted to reply "20 years?! Realy! Very bold prediction", but then I thught to myself - if someone said in 1991 that the future in the next 20 years would be web... he would have been right... interesting, isn't it.
Sorry to be inquisitive even further, I am not in Poland but my friend is thinking about moving there. Are you talking Warsaw here or a smaller town (Krakow, Wroclaw, Tricity area)?
This is exactly why this thing caught my eye. And this is not just a python project, but an interpreter for the language, so should give you a great experience with the language itself.
Valid points, although I do not have enough experience with p2p networks (and almost no knowledge of skype's particular architecture) to judge but 20% - 30% of SN does seem substantial.
What I would like to see and couldn't find anywhere is more details on the objective impact it had on the users (number of users that had degraded/no service etc.). I think it would give a more complete picture.
The performance part might be a problem for some people and I agree - programming is not music, and it's tricky and unnatural to program in front of an audience, but this is a completely learnable skill by practice. That said I agree that it will always penalise a subset of people who will always perform less good under pressure.
There is a flip side to this though which often goes overlooked and author hints at it: programming interviews are a great equaliser - there are no credential checks (or they are getting much less common) for getting into top companies, and you can be based almost anywhere in the world - all you need to do to get in is crush the coding interview which is totally a learnable skill. This has opened many doors and economic opportunities for people that did not have them even a decade ago, and I think we as an industry don't talk enough about the opportunities our attitude to barriers to entry create.
Finally there's the question of whether the skill tested in coding interviews are really unrelated to the job performance. I've seen arguments that state: "some data shows that how a person performed on the interview is unrelated to how they perform as an employee". But this kind of reasoning almost certainly suffers from selection bias, as we'd really need to include how people who did not pass the interviews perform at the job (for obvious reasons companies don't have this data). I would bet that there would be a much stronger link with interview performance in that case.
Overall I think it's more likely that coding interviews are the way they are because they work extremely well in practice, most of the time. They are also on average a massive equaliser and overall a good thing for almost everyone involved provided they are executed well. They do have their problems, but commonly proposed alternatives (like take home tests etc.) have problems too. Coding interviews are not a thing because there is some kind of collective madness in the whole industry, where people in charge of procuring the most expensive resource just can't help themselves succumb to group-think. They are a thing because they work well (but not perfectly).