91–100 of 336 posts
I'm a good programmer, but not a good interviewer. That makes me pretty typical.
I could spend a lot of time getting better at it, but I would only marginally improve, and it would take time out of the work I'm actually good at.
This feels like a typical problem for division of labor to solve.
Maybe it's already done in done form?
Tech interview discussions always seem to run the same course and hit the same points, so I'll repeat one of mine: What's wrong with the idea of turning the standard Leetcode algorithms interview into a license that only needs to be completed once, or maybe once every 5-8 years, similar to what physicians must undergo? Much more efficient than having to retake it with every single company during an interview cycle.
Reminder, our field isn't regulated. Anyone can go online and learn enough to be useful at a high paying entry level job. At some point there has to be a filter and that's what these interviews are for.
Earlier quoted context omitted.
The problem with looking at OSS and publications is that this penalizes a lot of people with real lives outside of work. Especially problematic if you’re into equitable hiring processes aiming to hire people who aren’t in their 20’s anymore. Looking at past work penalizes people who primarily have experience in large systems where their work is NDA’d, impossible to understand without a loooot of background, or simply…
> The “do smol thing together so we can talk about it” interview penalizes people with performance anxiety. Does this apply to the Leetcode style interviews?
But really, it depends what people think of when they say “Leetcode style interview”. There’s a lot of coding interviews that superficially look like stupid leetcode, but the job really does benefit from that.
A basic example: I ask you to model some toy problem as a state machine. Is that a stupid leetcode challenge? Maybe. But many if not most complex UI interactions really are state machines and if you’re the kind of person who intuitively thinks in state machines, you’re going to write more maintainable code.
My personal blind spot is that thinking in graphs is difficult for me. I just fail to see ”Oh, this is a graph problem!”. A lot of times the code I write would be much easier to maintain and write had I realized I’m solving a graph problem. Better performance too.
edit: if you mean the performance anxiety party, yes. Several research papers have shown that anxiety induced by the interview context impacts people’s performance.
So wait you are smart enough to get into caltech, smart enough to graduate with a degree in CS. And yet the curriculum on its own does not do a good job enough on its own to prepare you for getting a job? Very hard to graduate with a decent GPA in CS at caltech and not be able to thrive as an entry level engineer. If you got B’s in caltech CS I’d make you an offer for 200k+ without blinking or even asking you anythin…
Here we see what the alternative to whiteboard interviews: credentialism. Get into the right school and muddle through and get a guaranteed 200k! Is there more to you than your high school performance? Push back against this if so! (Calling the interview Leetcode is misleading IME, since I've rarely been asked something that would be near the upper tiers of that site's difficulty). Top-tier tech companies face a LOT…
I don't know the US education system enough, but there are some schools out there which are much more selective than any SWE interview process. You can be guaranteed that the worst student from these top schools could nail any algorithm interview with minimal preparation.
But these big companies hire many more people than these few schools can provide, and they do so globally, from countries that may not have such elite schools.
Idea: Professional CS interviewers! I'm a good programmer, but not a good interviewer. That makes me pretty typical. I could spend a lot of time getting better at it, but I would only marginally improve, and it would take time out of the work I'm actually good at. This feels like a typical problem for division of labor to solve. Maybe it's already done in done form?
I am willing to bet that spending an hour every day on leetcode you can probably be good enough to pass interviews at most companies in a month or two (assuming you had exposure to DS and Algorithms in college, if not add more time but the general idea applies). Maybe not Google but I would bet you'd be good enough to see double digit increasing in your onsite -> offer conversion percentage. Whether that would be worth it is a different question, the answer for many people who already have good jobs is no.
My career path in tech so far has been junior engineer -> mid level -> senior -> tech lead. As I've progressed through that path, I have had literally no opportunities of applying the stuff I've learnt on HackerRank, save for a couple of interviews. At this point I'm convinced that the focus of those interviews was entirely wrong. Once you pass those tests and get hired, you will be dealing with tons of legacy code r…
What’s your suggested alternative? Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly. Take home tests penalizes people with families and other responsibilities and probably has a racial bias as well in countries where different races have different societal loads. In the end, even if these…
I generally give (mostly) simple questions where I explain how to solve them. Assuming you're a competent programmer in the language we're dealing with, you should be able to figure out how to solve the problem in your head in a minute or two. The trick is that I'm gauging accumulated skill, not memorized algorithms.
For example, I'll explain how to use a data reader, explain the constructor for a simple object, and provide a SQL statement. Then you need to write the code that reads a few values from the data reader and constructs and object. After that we discuss edge cases and error handling, and if you should throw an exception or return null. Easy-peasy! (And if it's not easy-peasy, you really shouldn't be here.)
Another example: I'll explain an older API for running a lambda in a background thread, and then an API for running a lambda in the main (UI) thread. (Mac, Windows, iOS, and Android all have the same threading model for their UI.) Easy-peasy if you understand basic scoping and threading. (And if it's not easy-peasy, you shouldn't be working in any job where you have to deal with threads.)
In both cases, the candidate can ask any many questions as they want, and I'll happily steer a candidate.
The point is, I'm not relying on memorized algorithms, or requiring prep. What I'm doing is relying on, and judging accumulated skill. Only a novice will have trouble with my questions; and I wouldn't use these questions when hiring interns or entry-level engineers. If you've programmed with a database before, you should understand the basic concept of a data reader. If you've programmed for awhile, you should understand scope. And, if you've programmed with threads, you should understand running a lambda on another thread. (You probably should understand lambdas, too.)
Earlier quoted context omitted.
What’s your suggested alternative? Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly. Take home tests penalizes people with families and other responsibilities and probably has a racial bias as well in countries where different races have different societal loads. In the end, even if these…
Take home OR coding challenges is a false dichotomy. > In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job They are snake oil. You cannot predict success at some job by asking candidates to prove their ability at something that is only tangentially related to the actual job.
> The Validity and Utility of Selection Methods in Personnel Psychology: Practical and Theoretical Implications of 100 Years of Research Findings
> On the basis of meta-analytic findings, this paper presents the validity of 31 procedures for predicting job performance and the validity of paired combinations of general mental ability (GMA) and the 29 other selection procedures. Similar analyses are presented for 16 predictors of performance in job training programs. Overall, the two combinations with the highest multivariate validity and utility for predicting job performance were GMA plus an integrity test (mean validity of .78) and GMA plus a structured interview (mean validity of .76). Similar results were obtained for these two combinations in the prediction of performance in job training programs. A further advantage of these two combinations is that they can be used for both entry level hiring and selection of experienced job applicants. The practical utility implications of these summary findings are substantial. The implications of these research findings for the development of theories of job performance are discussed.
This is absolutely embarrassing for the industry.
Why is it not embarrassing for Caltech’s admission department and algorithms courses?
Sometime around my Junior year of college my goals shifted from "I'm here because I want to learn" to "I'm here because I want a job". I was surprised to find that doing well at learning (getting As) not only wasn't good enough for an entry level job, it wasn't even really correlated. The more time I spent on coursework the less time I had to grind through interview questions. I wonder if there are any other industri…
While, if i was going for grad school instead, then i'd need a 4.0, start taking grad school classes, start talking with professors, try to get a job as a research assistant, try to find a professor that i could latch onto and start working with. And that was a path i had considered at some point, when i really did enjoy taking hard classes, going in deep, and pushing the edges of my learning.
Earlier quoted context omitted.
“The standard” belies a lot of variation. Some interviewers want perfect code the first time on a whiteboard, some let you go back and forth with a compiler as much as you wish. Some interviews stick to relatively shallow algorithms knowledge like DFS, others will ask you two LC Hard questions in an hour. Sometimes it’s about whether you solved the problem, sometimes it’s about your thinking and collaboration during…
You're completely right, and this actually is another layer to the whiteboarding technical interviews are broken narrative: there are no objective standards, even if there is huge overlap in the content being interviewed from company to company (or even team to team). A very discouraging aspect about these interviews is that the rubric is completely hidden away from candidates and feedback is almost never provided. A…
So until that's changed, I find it hard to see how we could standardize developer hiring. My coworkers and I all wear a different amount of hats with varying competence. The number and variation of certs required would be rough! "I'm level 4 backend engineer with level 3 data design [streaming level 1, traditional ETL level 7], level 1 hacky frontend dev, and level 2 devops" - sheesh, now I'm spending my whole time keeping those up to date.