> show your impressive thing to people as high up as possible
How do you even get access to ' people as high up', most programming jobs make you go though "Standardized screening" programming puzzles before they even look at your github, if at all.
Many high profile sfo tech companies straight up told me that github is merely a formality in the application and that they don't have time to look at it. Many interviewers get you resume like 5 minutes before the interview and start asking you standard interview questions.
I think the takeaway is that he showed them a complete product, rather than a pile of schematics.
Looking through Github accounts is extremely tedious and boring. On most profiles I’ve seen it‘s hard to tell what all the repos are about, and what the important stuff is.
So if you‘ve made something awesome, you need to market it a bit.
Don‘t point people to your Github account.
Point them to the project website, where they see a screenshot or a demo video, a short, easy to grasp description of your thing, and some impressive stats of your choice that convinces everyone that this project is brilliant.
And make sure the project page also prominently credits you as the author!
People complain about the coding tests at interviews. I don't think it's as big of a deal as people say. Treat it like a social skill or any of the myriad other unrelated things you are evaluated for at an interview and spend some time practicing.
I think for a reasonable programmer, yes, you are probably going to have to practice your whiteboard interview.[1] But no, it's not that hard, and it's pretty standardized, so you don't have to practice differently at each company you interview.
I personally think that practicing for the programming test is usually way easier than the social test... and I think the programming test is less biased than the social test.
on the other side of the fence, I think it's a good failsafe. Yes, it will fail many qualified people who don't practice, but it will also fail a lot of people who talk a good game but can't code their way out of a wet paper bag.
Overall, I think it's a great counterbalance to how overvalued confidence is at most interviews.
[1]I personally think that you should use one of the screen share programs designed for this; I like https://codepad.remoteinterview.io/ but anything that reduces the amount of handwriting required is going to vastly reduce your false negative ratio without impacting your false positive ratio (unless you code using whiteboards at your company)
> I think it's a good failsafe. Yes, it will fail many qualified people who don't practice, but it will also fail a lot of people who talk a good game but can't code their way out of a wet paper bag.
I don't. I do R&D for a living and have next to no time to relearn those types of undergrad programming techniques because it doesn't apply to the work I do at all. Ask me to create a model for a system, implement a classifier that hits 90% in a way that no one has ever done before and publish a paper on it, I can do that. Ask me about a breadth first search on some tree and I'll look at you blankly. It seems a bit ridiculous that some of my cookie-cutter engineering colleagues(some that relied on me to help them with homework) can make it into places like Google but I can't make it past the 3rd or 4th interview. I can also assure you that none of my colleagues where I work could make it past that same stage of interviews despite having a PhD and despite them being great researchers.
I think I said that it's turning down a bunch of people who are unwilling to practice.
And yes, turning down people who are unwilling to spend a week practicing is a cost... it could be a very big cost if someone else has a intake filtering procedure that allows them to snatch those people up at a lower cost, but it's also a really effective way of filtering out the people who can't learn those things after a few weeks of practice, which is super important.
Can't. I clearly said can't. It's irrelevant to my work and my work consumes all the time I can give to work before I burnout.
> but it's also a really effective way of filtering out the people who can't learn those things after a few weeks of practice, which is super important.
What's your source on that? Can I see the stats that say neglecting more talented engineers so that you don't have to deal with subpar engineers is better than having a larger amount of more talented engineers while having to intermittently deal with subpar engineers? We have brilliant engineers where I work and the average and subpar engineers are in and out inside of a month or two. Didn't seem to hurt us at all in being the leader in our industry.
"Hire easily, fire easily" is another strategy, it's true! but not one used by most places I've worked. It is a slower strategy when sorting through a pool of mostly not good enough candidates, and often makes employees more nervous (Just like how you "Can't" take three weeks off to practice, other people "Can't" get fired after a few months on a new job.)
Music equipment corporations are pretty small on the whole, and Korg in particular was originally formed by engineering refugees from a larger gear company, so their culture is a bit more open.
Networking. Work with and impress people who know people, then ask for an introduction if need be. My experience has been that "volunteering" (working for free, if you prefer) has helped me make connections I wouldn't otherwise have the skills/experience/connections to get through conventional means.
Granted, I've actively avoided California, so YMMV.
How do you even get access to ' people as high up', most programming jobs make you go though "Standardized screening" programming puzzles before they even look at your github, if at all. Many high profile sfo tech companies straight up told me that github is merely a formality in the application and that they don't have time to look at it. Many interviewers get you resume like 5 minutes before the interview and start asking you standard interview questions.