6 ms·

One of the top comments in the video: > If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree The industry's hi

One of the top comments in the video: > If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree The industry's hiring process is so messed up that this is completely believable. "We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for."

brap 2y ago
I’m 100% sure that if he was being considered for a domain expert role in some domain related to this (e.g. TypeScript) his score in a typical whiteboard interview wouldn’t have been a deciding factor whatsoever. This is a standard hiring track even in big tech. Sometimes you’ll even be exempt from these interviews altogether. But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?
- turnsout 2y ago
  > But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it? As someone who has been on the hiring manager side, I'll state the obvious: because it demonstrates insanely good problem-solving skills that would transfer to nearly any challenge.
  - jf 2y ago
    Would he have made it past your recruiter screen though?
    - SXX 2y ago
      A lot of people who have a gap between jobs for 1-2 years because they worked on their insane projects certainly wouldn't.
      - soulofmischief 2y ago
        People are allowed to not work when they please, and you should avoid any employer who perceives self-indulgence and self-sufficiency as a red flag.
        SXX 2y ago
        Unfortunately I feel like recruiters at larger companies are squinting at CVs and think like: "Open source? Entrepreneur? Eh, oh. Smell of despair and discarded pizza boxes.". Of course unless your passion project is very successful one, but majority of them are not.
        zelon88 2y ago
        While I agree with the sentiment you are delivering, I think successful is probably the wrong word here. I worked on a repo for several years with many tens of thousands of lines of code and attempted to promote it heavily with little success. At some point I chopped out about 2,500 lines of code from that repo and packaged just one feature as a standalone product. Years later the child repo has thousands of users and the parent has barely any. While I consider both projects to be successful by definition, if I'm going to briefly showcase one over the other I'll showcase the smaller project that received more engagement. Because the engagement metrics do indeed matter. It lends credence and legitimacy to a project.
    - turnsout 2y ago
      And would he have even bothered to apply, given the boring-sounding, narrowly worded JDs that get posted?
  - mgfist 2y ago
    Seriously lol. Someone who can figure this out can figure anything else out.
gspencley 2y ago
> "We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for." I have a nuanced view of your particular example. I've been in this industry for almost 30 years. I cut my teeth writing C/C++, had an interest in language theory and frameworks and was brought up to care about portability. I always wanted to be able to easily transition from one language to another, or one framework to another. And I always assumed this was the case for other engineers in our field as well. However, I have worked for startups that like to move really fast, and hired talented developers who passed our technical screenings (read: "had the fundamentals down") under a "framework agnostic" hiring policy ... only to see them display stunning degrees of incompetence trying to learn our tooling. The problems that compound this are: - When you enter a new company with a large codebase that you have to ramp up on, you're not only required to learn the language or 3rd party frameworks and libraries that they use ... you need to ramp up on THEIR "framework." Depending on the complexity of the system, there is a lot of domain specific knowledge and custom supporting code that will have been written. Try to learn the ins and outs of Angular change detection, for example, while also ramping up on a massive codebase that does things in weird ways for legacy and historic reasons. - Every business, but some more so than others, has time pressure. You need to be able to write functional, easy to maintain code but also get it shipped yesterday. If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped. Expectations that you can deliver are very high, despite the time that you need to ramp up. Maybe you're one of those 10x'ers who can learn all the ins and outs of a new tool in a week or two before starting your position and then apply that knowledge at the level of someone whose been working with the tool for years and has learned all of the hidden footguns ... but if so, you are a rare specimen indeed. The industry can save itself a ton of inefficiency if it takes a "better not take a chance" attitude. - All problems are people problems. It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it. Because THIS company will for sure have years of active development behind it by developers of all sorts of different experience levels ... and some of those developers did it the right way while others found creative solutions and did things weird. The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.
Jasper_ 2y ago
Has anybody ever figured out what "invert a binary tree" means? That came from Max Howell, and nobody else seems to have ever received that question. The best anyone can figure out is that it's reversing the left and right branches, which seems like it's ten lines of code, at most?
- Liquix 2y ago
  leetcode seems to agree with your definition [0]. the meme isn't to say that inverting a binary tree is particularly difficult - anyone familiar with coding challenges and trees could trivially produce a solution. the meme is more pointing out how ludicrous it is that senior/staff/principal interviews can hinge on these types of problems, despite the engineer proving their proficiency by doing something like running DOOM in typescript types or writing homebrew [1]. [0] https://leetcode.com/problems/invert-binary-tree/description/ https://leetcode.com/problems/invert-binary-tree/description... [1] https://x.com/mxcl/status/608682016205344768 https://x.com/mxcl/status/608682016205344768
  - devmor 2y ago
    I think those challenges (especially leetcode) are heavily misused. When my team conducts technical interviews, we are asking for a couple simple programming solutions - but we're asking because we want to hear the candidate talk through it and see what their problem solving process is like. If you aren't evaluating based on conditions like those, I don't really see the value of coding questions.
    - josephg 2y ago
      > If you aren't evaluating based on conditions like those, I don't really see the value of coding questions. The way I think about it, you're really trying to evaluate a candidate on about 10 different metrics all at once. Metrics like programming skill (writing & debugging), communication skills (listening and explaining), capacity to learn, domain knowledge (eg if you're hiring a react dev, do they know HTML & react?), likeability, and so on. A good interview gives the candidate the chance to show their worth in all of those different areas. But time is limited - so you want some different challenges which will show many capabilities at once. Asking a candidate to talk through how they'd solve a "leetcode problem" sort of does that - you can see their CS knowledge and their communication skills. But if thats all you ask, you end up overemphasising the candidate's CS knowledge. Most people aren't very good at thinking and talking at the same time. And you don't learn about other stuff. How good are they at debugging? At reading code? Do they have domain knowledge? Can they talk to clients? Are they good at design? Its also quite easy for the interviewer to be distracted by the question of whether or not the candidate solved the problem you gave them. - Which isn't really what anyone is there for. As part of a larger interview, and especially for systems engineering roles, I think they're still fine questions to ask. But if thats the entire job interview, its a bad interview - because it won't let you evaluate a candidate properly. Especially in product roles where CS knowledge isn't very relevant anyway.
SXX 2y ago
By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.
- callalex 2y ago
  I go back and forth on my opinion for this one. You wouldn’t necessarily want a mechanic or engineer to drive a race car, for example.
  - deleted 2y ago
    [deleted]
  - magicpin 2y ago
    Yes, but having a mechanic or engineer who's worked on the racecar your driver is in would be very helpful on your team.
    - adamtaylor_13 2y ago
      And we're also not driving race cars, we're the pit crew... So you kinda do want mechanics... Like, literally, we build and fix the thing you're selling. We do not USE the thing we're building by and large.
      - josephg 2y ago
        > We do not USE the thing we're building by and large. Yes, thankyou, that's quite obvious judging by the quality of most software. It really is amazing how bad most software made for non-developers is. Like, as software engineers, we understand how essential version control is. We made git and github for ourselves. But nobody has bothered building that functionality for people who edit word documents all day. Or people who edit video, or animators, or 3d modellers, or 100 different jobs. Word and google docs have track changes. But they don't let you bounce between branches or make pull requests. You usually can't time travel, or bisect, or git blame, or any of the other things we take for granted. My partner works in a CMS all day at work. Every change she makes is pushed directly to production. There's no review process. No staging. No testing. No change control or rollback. If anyone messes something up, they get blamed for "taking down the app". As a software engineer, I look on in horror. I believe the more cognitive distance there is between 20-something silicon valley tech bros and your particular use case, the worse your software is going to be. If you're a manchild living in san francisco who can't be bothered driving, doing your laundry or shopping for groceries, you're in good hands. There is a startup that will solve your problem! But the further from that "ideal" you get, the worse. Here in Melbourne, I can't use my iphone to pay for public transit. Google maps couldn't really handle roundabouts (traffic circles) for a decade and change. (I guess they don't have those in California). Unicode support was only added recently because of Emoji. Until then, a huge amount of software butchered non-english text. I shudder to think how badly most software probably handles right to left languages. And the list goes on and on.
renewiltord 2y ago
Yeah that’s obvious and probably good. You’re trying to make a machine that reliably adds employees to your company in a way that minimizes nepotism or corruption. Faced with the immutable fact that the chief executive cannot watch everything, that there will be pockets within the organization where people will sell access to a $300k job, and where others will hire from their family, their tribe, or so on: you make a system that is meant to prove some minimum standard while constraining your interviewers. One thing that is not immediately obvious is that the Big Tech hiring process is to constrain your hiring team in who they bring on. Startup executives are close to the road so they can tell if the rubber’s good much more easily. The hiring process is designed around the constraint of executive attention. As are most things in firms.
garaetjjte 2y ago
Reminds me of https://aphyr.com/posts/342-typing-the-technical-interview https://aphyr.com/posts/342-typing-the-technical-interview
deleted 2y ago
[deleted]
butterisgood 2y ago
I think, nowadays, I can get a generative AI to tell anyone how the process of inverting a binary tree works, and perhaps even give sample code for it. So that's not interesting to me at all as a person hiring engineers. What I want to know is "how have you solved bigger design problems" or "what's your approach to keeping code maintainable and reducing cost of ownership" I've also hired people who 3 other managers have passed on and those people have gone on to amazing things at the company in which I work. So the process is horribly broken... it doesn't successfully weed out anyone, and we've also hired really toxic individuals also with the same processes.
stjo 2y ago
Why do you think person capable of making doom run in such an environment is incapable of basic tree operations?
- deleted 2y ago
  [deleted]
- mattgreenrocks 2y ago
  I suspect the technical interview devolves into an act of shunting the blame of potential bad hires away at some places. Elite credentials and leetcode shibboleths serve the same purpose: this person has checked the boxes we've agreed upon as important in the hiring process, regardless of the job duties. If they turn out to be a bad hire, who could've known, esp. with that Ivy League bachelor's degree? It's less the tree operations themselves and more that this candidate just didn't know the shibboleth, so they shouldn't be allowed in. Cue the vague feeling of disgust on the interviewer's part that the interviewee didn't know something "so simple" in a tense environment with lopsided power dynamics.
  - GinsengJar 2y ago
    >shibboleth Fantastic word right there, had to look it up. That's exactly how I'd describe the hiring process these days. Relevant expertise seems like its only seen as a bonus. That or I'm interviewing at some terrible companies.
  - yodsanklai 2y ago
    The role of such standardized coding interviews is to ensure consistency when hiring at very large scale. Some big tech companies hire thousands of people a year, and interview ten times that. Candidates have a very diverse set of backgrounds, age, experience, culture, education, interests, experience. The coding interview is a common denominator: undergrad algorithmic knowledge, being able to solve problems which are application of classic algorithms. This is something that a decent coder should be able to prepare for within a few months of regular practice. In my case, I can tell that these months of practice were the best investment in my life. And honestly, I feel I'm a better programmer after this preparation. > Cue the vague feeling of disgust on the interviewer's part that the interviewee didn't know something "so simple" in a tense environment with lopsided power dynamics. This is your interpretation of the situation. As an interviewer, I want the interviewee to succeed, I understand it's stressful for them as I've been in their shoes before. Ultimately, there are more candidates than positions, so whatever the interview is, people will complain about it. I think leetcode is a decent interview technique. I wish we would give more time to candidates though.
guelo 2y ago
The justification is that it's almost impossible to get "good employee" signal any other way. If you tell people upfront that you're testing them on leetcode you at least get some signal that 1) they're willing to put in time and follow through on studying for something 2) they have some base level of programming skill and intelligence Companies optimize hiring for avoiding false positives (bad hire) over false negatives (bad rejection), especially in this job market.
yodsanklai 2y ago
Given his skills, he'll be able to pass the usual coding interviews with some preparation. In most companies, the bar isn't that high, they're just there to ensure that candidates have some minimal (usually undergraduate) algorithmic knowledge, and is able to interact with the interviewer (communicate their ideas, act on hints and so on...).
legutierr 2y ago
Event better is his response to the comment. > I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well.

brap 2y ago

I’m 100% sure that if he was being considered for a domain expert role in some domain related to this (e.g. TypeScript) his score in a typical whiteboard interview wouldn’t have been a deciding factor whatsoever. This is a standard hiring track even in big tech. Sometimes you’ll even be exempt from these interviews altogether. But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?

turnsout 2y ago
> But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it? As someone who has been on the hiring manager side, I'll state the obvious: because it demonstrates insanely good problem-solving skills that would transfer to nearly any challenge.
- jf 2y ago
  Would he have made it past your recruiter screen though?
  - SXX 2y ago
    A lot of people who have a gap between jobs for 1-2 years because they worked on their insane projects certainly wouldn't.
    - soulofmischief 2y ago
      People are allowed to not work when they please, and you should avoid any employer who perceives self-indulgence and self-sufficiency as a red flag.
      - SXX 2y ago
        Unfortunately I feel like recruiters at larger companies are squinting at CVs and think like: "Open source? Entrepreneur? Eh, oh. Smell of despair and discarded pizza boxes.". Of course unless your passion project is very successful one, but majority of them are not.
        zelon88 2y ago
        While I agree with the sentiment you are delivering, I think successful is probably the wrong word here. I worked on a repo for several years with many tens of thousands of lines of code and attempted to promote it heavily with little success. At some point I chopped out about 2,500 lines of code from that repo and packaged just one feature as a standalone product. Years later the child repo has thousands of users and the parent has barely any. While I consider both projects to be successful by definition, if I'm going to briefly showcase one over the other I'll showcase the smaller project that received more engagement. Because the engagement metrics do indeed matter. It lends credence and legitimacy to a project.
  - turnsout 2y ago
    And would he have even bothered to apply, given the boring-sounding, narrowly worded JDs that get posted?
- mgfist 2y ago
  Seriously lol. Someone who can figure this out can figure anything else out.

gspencley 2y ago

> "We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for." I have a nuanced view of your particular example. I've been in this industry for almost 30 years. I cut my teeth writing C/C++, had an interest in language theory and frameworks and was brought up to care about portability. I always wanted to be able to easily transition from one language to another, or one framework to another. And I always assumed this was the case for other engineers in our field as well. However, I have worked for startups that like to move really fast, and hired talented developers who passed our technical screenings (read: "had the fundamentals down") under a "framework agnostic" hiring policy ... only to see them display stunning degrees of incompetence trying to learn our tooling. The problems that compound this are: - When you enter a new company with a large codebase that you have to ramp up on, you're not only required to learn the language or 3rd party frameworks and libraries that they use ... you need to ramp up on THEIR "framework." Depending on the complexity of the system, there is a lot of domain specific knowledge and custom supporting code that will have been written. Try to learn the ins and outs of Angular change detection, for example, while also ramping up on a massive codebase that does things in weird ways for legacy and historic reasons. - Every business, but some more so than others, has time pressure. You need to be able to write functional, easy to maintain code but also get it shipped yesterday. If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped. Expectations that you can deliver are very high, despite the time that you need to ramp up. Maybe you're one of those 10x'ers who can learn all the ins and outs of a new tool in a week or two before starting your position and then apply that knowledge at the level of someone whose been working with the tool for years and has learned all of the hidden footguns ... but if so, you are a rare specimen indeed. The industry can save itself a ton of inefficiency if it takes a "better not take a chance" attitude. - All problems are people problems. It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it. Because THIS company will for sure have years of active development behind it by developers of all sorts of different experience levels ... and some of those developers did it the right way while others found creative solutions and did things weird. The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.

Jasper_ 2y ago

Has anybody ever figured out what "invert a binary tree" means? That came from Max Howell, and nobody else seems to have ever received that question. The best anyone can figure out is that it's reversing the left and right branches, which seems like it's ten lines of code, at most?

Liquix 2y ago
leetcode seems to agree with your definition [0]. the meme isn't to say that inverting a binary tree is particularly difficult - anyone familiar with coding challenges and trees could trivially produce a solution. the meme is more pointing out how ludicrous it is that senior/staff/principal interviews can hinge on these types of problems, despite the engineer proving their proficiency by doing something like running DOOM in typescript types or writing homebrew [1]. [0] https://leetcode.com/problems/invert-binary-tree/description/ https://leetcode.com/problems/invert-binary-tree/description... [1] https://x.com/mxcl/status/608682016205344768 https://x.com/mxcl/status/608682016205344768
- devmor 2y ago
  I think those challenges (especially leetcode) are heavily misused. When my team conducts technical interviews, we are asking for a couple simple programming solutions - but we're asking because we want to hear the candidate talk through it and see what their problem solving process is like. If you aren't evaluating based on conditions like those, I don't really see the value of coding questions.
  - josephg 2y ago
    > If you aren't evaluating based on conditions like those, I don't really see the value of coding questions. The way I think about it, you're really trying to evaluate a candidate on about 10 different metrics all at once. Metrics like programming skill (writing & debugging), communication skills (listening and explaining), capacity to learn, domain knowledge (eg if you're hiring a react dev, do they know HTML & react?), likeability, and so on. A good interview gives the candidate the chance to show their worth in all of those different areas. But time is limited - so you want some different challenges which will show many capabilities at once. Asking a candidate to talk through how they'd solve a "leetcode problem" sort of does that - you can see their CS knowledge and their communication skills. But if thats all you ask, you end up overemphasising the candidate's CS knowledge. Most people aren't very good at thinking and talking at the same time. And you don't learn about other stuff. How good are they at debugging? At reading code? Do they have domain knowledge? Can they talk to clients? Are they good at design? Its also quite easy for the interviewer to be distracted by the question of whether or not the candidate solved the problem you gave them. - Which isn't really what anyone is there for. As part of a larger interview, and especially for systems engineering roles, I think they're still fine questions to ask. But if thats the entire job interview, its a bad interview - because it won't let you evaluate a candidate properly. Especially in product roles where CS knowledge isn't very relevant anyway.

SXX 2y ago

By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.

callalex 2y ago
I go back and forth on my opinion for this one. You wouldn’t necessarily want a mechanic or engineer to drive a race car, for example.
- deleted 2y ago
  [deleted]
- magicpin 2y ago
  Yes, but having a mechanic or engineer who's worked on the racecar your driver is in would be very helpful on your team.
  - adamtaylor_13 2y ago
    And we're also not driving race cars, we're the pit crew... So you kinda do want mechanics... Like, literally, we build and fix the thing you're selling. We do not USE the thing we're building by and large.
    - josephg 2y ago
      > We do not USE the thing we're building by and large. Yes, thankyou, that's quite obvious judging by the quality of most software. It really is amazing how bad most software made for non-developers is. Like, as software engineers, we understand how essential version control is. We made git and github for ourselves. But nobody has bothered building that functionality for people who edit word documents all day. Or people who edit video, or animators, or 3d modellers, or 100 different jobs. Word and google docs have track changes. But they don't let you bounce between branches or make pull requests. You usually can't time travel, or bisect, or git blame, or any of the other things we take for granted. My partner works in a CMS all day at work. Every change she makes is pushed directly to production. There's no review process. No staging. No testing. No change control or rollback. If anyone messes something up, they get blamed for "taking down the app". As a software engineer, I look on in horror. I believe the more cognitive distance there is between 20-something silicon valley tech bros and your particular use case, the worse your software is going to be. If you're a manchild living in san francisco who can't be bothered driving, doing your laundry or shopping for groceries, you're in good hands. There is a startup that will solve your problem! But the further from that "ideal" you get, the worse. Here in Melbourne, I can't use my iphone to pay for public transit. Google maps couldn't really handle roundabouts (traffic circles) for a decade and change. (I guess they don't have those in California). Unicode support was only added recently because of Emoji. Until then, a huge amount of software butchered non-english text. I shudder to think how badly most software probably handles right to left languages. And the list goes on and on.

renewiltord 2y ago

Yeah that’s obvious and probably good. You’re trying to make a machine that reliably adds employees to your company in a way that minimizes nepotism or corruption. Faced with the immutable fact that the chief executive cannot watch everything, that there will be pockets within the organization where people will sell access to a $300k job, and where others will hire from their family, their tribe, or so on: you make a system that is meant to prove some minimum standard while constraining your interviewers. One thing that is not immediately obvious is that the Big Tech hiring process is to constrain your hiring team in who they bring on. Startup executives are close to the road so they can tell if the rubber’s good much more easily. The hiring process is designed around the constraint of executive attention. As are most things in firms.

garaetjjte 2y ago

Reminds me of https://aphyr.com/posts/342-typing-the-technical-interview https://aphyr.com/posts/342-typing-the-technical-interview

deleted 2y ago

[deleted]

butterisgood 2y ago

I think, nowadays, I can get a generative AI to tell anyone how the process of inverting a binary tree works, and perhaps even give sample code for it. So that's not interesting to me at all as a person hiring engineers. What I want to know is "how have you solved bigger design problems" or "what's your approach to keeping code maintainable and reducing cost of ownership" I've also hired people who 3 other managers have passed on and those people have gone on to amazing things at the company in which I work. So the process is horribly broken... it doesn't successfully weed out anyone, and we've also hired really toxic individuals also with the same processes.

stjo 2y ago

Why do you think person capable of making doom run in such an environment is incapable of basic tree operations?

deleted 2y ago
[deleted]
mattgreenrocks 2y ago
I suspect the technical interview devolves into an act of shunting the blame of potential bad hires away at some places. Elite credentials and leetcode shibboleths serve the same purpose: this person has checked the boxes we've agreed upon as important in the hiring process, regardless of the job duties. If they turn out to be a bad hire, who could've known, esp. with that Ivy League bachelor's degree? It's less the tree operations themselves and more that this candidate just didn't know the shibboleth, so they shouldn't be allowed in. Cue the vague feeling of disgust on the interviewer's part that the interviewee didn't know something "so simple" in a tense environment with lopsided power dynamics.
- GinsengJar 2y ago
  >shibboleth Fantastic word right there, had to look it up. That's exactly how I'd describe the hiring process these days. Relevant expertise seems like its only seen as a bonus. That or I'm interviewing at some terrible companies.
- yodsanklai 2y ago
  The role of such standardized coding interviews is to ensure consistency when hiring at very large scale. Some big tech companies hire thousands of people a year, and interview ten times that. Candidates have a very diverse set of backgrounds, age, experience, culture, education, interests, experience. The coding interview is a common denominator: undergrad algorithmic knowledge, being able to solve problems which are application of classic algorithms. This is something that a decent coder should be able to prepare for within a few months of regular practice. In my case, I can tell that these months of practice were the best investment in my life. And honestly, I feel I'm a better programmer after this preparation. > Cue the vague feeling of disgust on the interviewer's part that the interviewee didn't know something "so simple" in a tense environment with lopsided power dynamics. This is your interpretation of the situation. As an interviewer, I want the interviewee to succeed, I understand it's stressful for them as I've been in their shoes before. Ultimately, there are more candidates than positions, so whatever the interview is, people will complain about it. I think leetcode is a decent interview technique. I wish we would give more time to candidates though.

guelo 2y ago

The justification is that it's almost impossible to get "good employee" signal any other way. If you tell people upfront that you're testing them on leetcode you at least get some signal that 1) they're willing to put in time and follow through on studying for something 2) they have some base level of programming skill and intelligence Companies optimize hiring for avoiding false positives (bad hire) over false negatives (bad rejection), especially in this job market.

yodsanklai 2y ago

Given his skills, he'll be able to pass the usual coding interviews with some preparation. In most companies, the bar isn't that high, they're just there to ensure that candidates have some minimal (usually undergraduate) algorithmic knowledge, and is able to interact with the interviewer (communicate their ideas, act on hints and so on...).

legutierr 2y ago

Event better is his response to the comment. > I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well.