It's also frustrating for job mobility, as you need to move jobs (or at least have offers) to get employers to pay your market rate. But in order to get offers you need to basically start a part time job studying and interviewing. If you just interview with a company you want to work for with no competing offers you will get lowballed - you might also just get rejected because companies prefer high-false positive rates and most interviewers do not get any sort of continual training, feedback, calibration or standardization. It's also unfortunately standard that your compensation doesn't keep up with your market value as companies would rather hire-in than promote internally.
Code Interviews
31–40 of 98 posts
Re: Code Interviews
#32I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again. I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built…
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience.
I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm.
That is why we need to ascertain coding signal. And that is why we need some contrived problem to provide to ascertain within a reasonable amount of time whether a candidate is a yes/no.
You are a unique data point and hundreds and thousands of other developers just don't have that kind of clout (I didn't look through your resume thing).
Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews.
Re: Code Interviews
#33I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again. I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built…
As an experienced engineer Apple I'm sure that you've noticed a few trends such as. 1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work. 2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very famili…
> 1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work.
That's me! But...wanna see something cool?[0] That's a link to the maintenance manual for my very first engineering project, started in 1986-7 (PDF doc). I wrote it, as well as the project it describes. It contains full source code for the firmware OS, strategic discussions, user guidance, chassis, and electrical diagrams.
My very first project. At the time, I was a high school dropout, with a GED, and some tech training school. I'd never attended one single "core comp sci" class. In fact, I had no idea that "core comp sci" even existed. The engineering team I worked with were all EEs. The firmware team was separate (and a bit arrogant -hard to work with), and my team liked having their own firmware geek, who was quite grateful, for being given the chance.
Not too shabby.
> 2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very familiar with when to use what or how to make something that does one thing do another.
I code every single day. How's that work out for you? In my experience, others have a hard time, keeping up with me.
> 3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.
Define "the basics."
If you mean LeetCode school curriculum algorithms, then, guilty as charged. Also, guilty of not being particularly interested in "a little practice." These represent things that I have seldom encountered, In Real Life. I won't bother wasting time practicing them, if the only place they have utility, is in a conference room that I'll never enter.
If you mean "the basic structure of iOS applications," "device I/O concepts," "Shipping to the App Store," or "idiomatic Swift," then, you're in luck! Since these inform the work that I do every single day, I happen to be pretty up on them. No practice necessary.
Although, TBPH, I frequently google even the most basic stuff. This will continue for the rest of my life. If you can't deal with that, then we're better off not interacting with each other. I forget stuff, all the time. I google it.
This Internets Tubes thing is the pants!
> 4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly
People who solve difficult problems -every single day- can also be pretty fast on the uptake.
Just sayin'...
[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
Re: Code Interviews
#34Earlier quoted context omitted.
> I'm sure most of us would fail high-school trigonometry (or spelling and grammar for that matter) if given one. Not if we had a few weeks of prep time.
Doesn't it seem like an absurd scenario to you though, that you need to prep for an interview by relearning skills that aren't relevant to the job you're interviewing for? I've been in coding interviews that matched the work that the company is doing, and I've found those useful - I get something from taking the interview (an idea of what their codebase is like, working with a partner, maybe some interesting code des…
It is absurd, but is so easy to counteract by just prepping. I’d be a lot more negative about it if it wasn’t so easy to game.
Re: Code Interviews
#35Max Howell's tweet gets pasted on every article talking about code interviews as some kind of exemplification of the problem of whiteboard/algorithmic interviews. What some people might not know is that he reflected on that tweet two years later (3 years ago), in this Quora question: https://www.quora.com/Whats-the-logic-behind-Google-rejectin... He even explains how he actually did well in the software engineering i…
The tweet comes up every so often, but it has two problems:
(1) Most of Google's engineers didn't even know Homebrew - it just wasn't something Google used on its notebooks.
(2) There's no such thing as "inverting a binary tree." At least I haven't heard about it anywhere else.
Maybe Google's interview process is broken, but the tweet isn't really explaining much. It's just a nice soundbite.
Re: Code Interviews
#36I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again. I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built…
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience. I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm. That is why we need to asc…
> Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews.
I was a hiring manager for 25 years. I would have killed for this kind of information.
The people I hired were no slouches. It was a big deal, and not to be taken lightly. I loved multi-page résumés.
Re: Code Interviews
#37I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again. I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built…
As an experienced engineer Apple I'm sure that you've noticed a few trends such as. 1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work. 2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very famili…
1) that is extremely unlikely for any engineer who has produced open source projects or commercial products succesfully
2) again, see 1)
3) they don’t need to remember everything about all algorithms and data structures, just like lawyers don’t remember all details about the law either. that is what books and the internet are for. you just need to know what exists and where to find it, and should have implemented some of it in your career and while in college.
4) i think that that is a typical mistake made by managers and HR. it takes years of work to enter a particular niche and gain experience in it, and it’s unrealistic to think you can just quickly train someone on the job. apple is the example here - most people there are highly specialized in exactly one thing and have long careers related to that.
passing on experienced people because they don’t care about your stupid binary tree trick question or are just tired of going through another leetcode circus act is a costly mistake - there are only a very limited number of highly specialized people available in the market, and it is these people who will make the difference between a “meh” product and something truly incredible.
hiring is broken and will remain so until the coding interview bullshit is replaced with something better.
Re: Code Interviews
#38Earlier quoted context omitted.
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience. I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm. That is why we need to asc…
> Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews. I was a hiring manager for 25 years. I would have killed for this kind of information. The people I hired were no slouches. It was a big deal, and not to be taken lightly. I loved multi-page résumés.
For a long time when looking for work I got absolutely no callbacks. A friend looked at my Resume and said "You have this huge block of skills you say you have but you have no explanation for how you have them." I explained it was because I got most of my experience from working on OSS software or software for myself and if I listed everything my resume would be ~2 pages & ~4 sides. He said to go for it despite everyone else telling me at my age (18 at the time) my resume shouldn't be that long.
As soon as I listed everything I started getting calls back.
Re: Code Interviews
#39I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again. I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built…
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience. I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm. That is why we need to asc…
this is exactly the issue - if you cannot take a moment to look at a candidate’s work but can waste 10 hours in leetcode
zoom bullshit calls your system is broken, sorry
Re: Code Interviews
#40I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again. I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built…
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience. I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm. That is why we need to asc…
also, i would rather share code i wrote and go through it than deal with any standardized coding interview. you can derive a lot more from someone’s work than from coding interviews and it is a much fairer process.