6 ms·

You laugh at that coding assignment for a senior position but you'd be surprised how many "senior" people interview that would struggle with that and be unable

You laugh at that coding assignment for a senior position but you'd be surprised how many "senior" people interview that would struggle with that and be unable to complete it.

caminante 4y ago
FizzBuzz interview questions are fair game[0] , especially if you're not networking in via referrals and are 1/5000 online applicants like the parent. [0] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
- rjbwork 4y ago
  Pretty much. I hold the record for our coding question in my company - 3 minutes and 54 seconds. Granted, I'm one of the two people that put the question together, but still. We've had candidates with "20 years of experience" completely unable to do what amounts to "call a web service, deserialize some json, write a couple for loops and if statements, and post back some json to a web service" in over an hour, or in a take home scenario. It will never cease to amaze me that there are people employed in this field that just. can. not. program.
  - Cthulhu_ 4y ago
    To be fair: it might be they have never done this before. At my previous company, we had a technical assessment - this was about ten years ago now. It boiled down to: read XML, do some math / business logic, and build a REST API to do so. Interestingly, ten years ago, at least half the applicants said they found it interesting because they had never worked with REST or JSON before. A lot were Java developers, so the XML part wasn't a problem, and they would often add some SQL database as a bonus. But 5-10 years later, as development switched to (Node)JS and web, it became the inverse and people said they had never done anything with XML before.
    - usrusr 4y ago
      And far more likely: done before, but never on anything even remotely close to a blank slate. You can spend years doing X, be very good at doing X, but only ever adapt some pre-existing precedent implementation of doing X to a new use case, or to a new underlying library, but never any green-fielding. That "implement X in a vacuum" test will rate many experienced people lower than some who have never ventured beyond textbook examples. It's not impossible that your real tasks have so much green field work in them that those experienced brown-fielders might actually be bad matches, but I suspect that those situations are much less common than the tests that select for green-fielders.
kamranjon 4y ago
I have a different perspective. I feel that specific coding task tells me absolutely nothing about the seniority of the person performing the task and tells me very little about their qualifications.
- Mistletoe 4y ago
  But shouldn't a blacksmith be able to make a nail before he makes me a suit of armor?
  - nordsieck 4y ago
    > But shouldn't a blacksmith be able to make a nail before he makes me a suit of armor? Yes. But I think there's a reasonable upper limit to the amount of time a company can expect someone to spend on a job opportunity. If they're burning an appreciable amount of that time on a trivial coding exercise, that's not great.
    - joe_guy 4y ago
      It's 60 minutes as a very high estimate. You might spend a life time together.
      - bboygravity 4y ago
        55 minutes to install the tool-chain and libs and 5 minutes to do the coding?
        hackertyper69 4y ago
        give them a machine to ssh into with env setup already. or a docker container to ssh into on a port other than 22
    - caminante 4y ago
      !!! You're missing the point. The premise is that someone capable can blast through trivial assignments in no time. Either this is the final proficiency challenge or there are subsequent, harder questions. In the former case, why not see the salary/offer and then decide?
nindalf 4y ago
No doubt when GP refused to complete the coding assessment the people who designed it thought “aha! Yet another non-coder filtered out by our process!”
- caminante 4y ago
  Why limit it there? Add "This person doesn't know about my firm's hiring process, aren't willing to do basic tasks, doesn't want to work at my firm," etc.
wildzzz 4y ago
It's a great way to weed out the junior devs that cheated their way through school (or are too dumb to figure it out via stackoverflow) and the senior devs that haven't actually done any real programming in a long time. An engineer at our competitor got laid off and my PM found out and hired the guy to do FPGA work. My PM knew the guy through some contracts we had with the competitor and assumed he was an expert in the field. Turns out the guy was more of middleman between program management and the engineers so while he could talk about the work, he hadn't really done it in like 10 years. My PM got the hiring expedited and since we don't really do interview tests in our industry, the guy was now on our team before anyone could ask any pertinent questions. Long story short, the FPGA team starts assigning him work but it's taking way too long and he's asking for more documentation and for help on things that he definitely would have worked on in his supposed previous job. Eventually we all figure out that he kinda overstated how fresh his skills are and we transition him to a sort of documentation role so he wasn't burning hours on things he just couldn't handle. While he was perfectly capable of doing that kind of work, it involved a lot of insight to our design so it took him a while to get onboarded to the system and able to properly describe the design. Eventually he was doing good work and got the project to the point where he wasn't needed but he left a bad taste in everyone's mouth. We could have hired two junior engineers to do the work he was doing for the same price and probably gotten it done much faster. After the guy transfered over to another project, we reamed out our PM about his hiring decision and begged him to give us some input next time. Of course, due to the waste of money from the last guy, the functional managers stopped taking hiring inputs from our project and would just assign whoever the fuck they thought we needed despite the kind of roles we actually needed.
- genewitch 4y ago
  I am one of those people who just won't exaggerate or lie on my CV or during an interview. I say "i'm not sure, i'd google it the first couple times it came up". I'm not a programmer though. I have a weird skillset that doesn't mesh or gel with what recruiters are looking for, so on the rare occasion i get a recruiter on the phone, i tend to get a job offer at the end of the sequence. I've had a few startup jobs, a couple megacorp jobs (not Apple), and a handful of mom and pop and defunct business jobs as well. My least favorite interview questions involve regex or deep internals of BSD or Linux, my favorite interview questions are off the cuff solutions to problems presented, and then backtracking the explanation. I've also been asked to perform job interviews for positions that i probably ought know enough about to interview a candidate for, but I went off my gut feeling about how the person acted in what i consider a stressful situation (a slew of interviewers asking asinine questions). I don't like interviewing, i am not very good at finding candidates that are "in for the long haul" but every time we were tasked with finding someone who can do X before end of Q3, my hired candidate recommendations always nailed it in that time frame. All this is to say, i find the whole process ridiculous. My CV apparently looks like a train wreck. I refuse to wear a tie or get a haircut. I'm eerily relaxed in interview situations. My trick? one time i hung out with a CEO of an IT company from the PNW, and they basically told me everything i thought i knew was trash, my resume was trash, my attitude was trash, and the only thing i was good at was solving problems in a hurry. We did, in fact, get coffee for our meetup. I scrapped every idea of what a resume should look like - what i envisioned a perfect professional resume looked like - and started fresh. I learned to say no to most recruiters in a way that made them ask me about different "opportunities" more aligned with my personal ethics and values in the future. I have 4 FPGAs, and i've never done anything with them, because the bitstream is proprietary on all of them. I wouldn't hesitate to tell an interviewer that i am interested in FPGAs and custom ASICs, because i am. I'm also interested in bacteria, but i won't be applying to a bioscience lab anytime soon. I certainly wouldn't say "yeah i can program an FPGA", or C, or do front end development, or any of that. From my reading of these sorts of comments, in aggregate, most people try to impress the interviewers. I want them to impress me. Does this make me privileged? Probably. <sigh>
cratermoon 4y ago
Especially now that the "senior" titled is handed out to people with 3-5 years of experience.
- selcuka 4y ago
  There was a blog post on HN a few days ago by someone who taught himself programming during covid and landed senior roles (multiple, simultaneously, by lying to the employers).
  - FrenchTouch42 4y ago
    Do you have the link?
    - AkshatJ27 4y ago
      https://overemployed.com/ https://overemployed.com/ Not parent, but i think they are talking about this blog
    - selcuka 4y ago
      It was this story, but the actual post is gone: https://news.ycombinator.com/item?id=33739094 https://news.ycombinator.com/item?id=33739094 It's still archived, though: https://web.archive.org/web/20221119032911/https://overemployee.blog/my-overemployment-story/ https://web.archive.org/web/20221119032911/https://overemplo... and https://web.archive.org/web/20221116023708/https://overemployee.blog/how-much-do-i-make-as-an-overemployee/ https://web.archive.org/web/20221116023708/https://overemplo... Key takeaways: > I started learning to code in 2019 as my new years resolution. > Job #1 Senior front end dev > Job #2 Senior front end engineer > Job #3 Front end engineer (mid-level)
- sodapopcan 4y ago
  Ya, most people who have been in the game for a year ask for "senior" position. I'm pretty sure this is why there is "staff" now. Well, I'm not sure how long "staff" has been a thing as I've never worked at a company that has that title, just interviewed for them (nb: I interviewed for "senior" positions at said companies).
ohdannyboy 4y ago
I'm currently doing interviews for a senior firmware dev position and was stunned by this. Today I talked to a guy who couldn't tell me what an interrupt was in any technical detail. His coding was worse than a first year college students. 5 of the 6 people I've talked to so far bombed the coding portion.
- AlotOfReading 4y ago
  This isn't intended as a rebuttal, but I've learned to stay away from deeply technical questions in embedded. As long as the interviewee is sufficiently paranoid about C, is recognizably experienced via conversation, and knows the basic concepts I don't press too hard on their specific skillset. There are just too many niches where the knowledge we each consider necessary simply isn't. I had one particularly bad interviewer grill me on how the ARM GIC worked in detail (e.g. interconnect details, differences between versions, etc) because they considered it basic knowledge. I've personally never needed to know anything about it that wasn't in a TRM.
  - ohdannyboy 4y ago
    Im pretty new to interviewing so I appreciate the feedback. I think I'm dong OK with respect to that but I'll make sure not to assume my own expertise are trivial.
  - greyhair 4y ago
    I agree. Why memorize something that is well documented? Do you understand basic interrupt management and the existence of interrupt controllers? Good. Understanding basic concepts matter, but silicon implementations of a concept? No. One question I have found useful in embedded development is asking someone to discuss the difference between a thread and a process, and the difference between thread based OSs and process based OSs. It is a general question, not bound by anything like CPU architecture, but just gives an idea into whether the person is comfortable about general memory domains. I have mentored people, bright programmers that never worked in small embedded systems, that initially tripped all over the thread model, but eventually came to understand it.
AlfeG 4y ago
And very low ability to do any improvisation. Without specifying every detail of implementation task will not be completed. Even in areas that don't require very specific solutions, and need to just work.
dcow 4y ago
And if you think a suit extends card then you’ve violated LSP.

You laugh at that coding assignment for a senior position but you'd be surprised how many "senior" people interview that would struggle with that and be unable to complete it.

caminante 4y ago

FizzBuzz interview questions are fair game[0] , especially if you're not networking in via referrals and are 1/5000 online applicants like the parent. [0] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

rjbwork 4y ago
Pretty much. I hold the record for our coding question in my company - 3 minutes and 54 seconds. Granted, I'm one of the two people that put the question together, but still. We've had candidates with "20 years of experience" completely unable to do what amounts to "call a web service, deserialize some json, write a couple for loops and if statements, and post back some json to a web service" in over an hour, or in a take home scenario. It will never cease to amaze me that there are people employed in this field that just. can. not. program.
- Cthulhu_ 4y ago
  To be fair: it might be they have never done this before. At my previous company, we had a technical assessment - this was about ten years ago now. It boiled down to: read XML, do some math / business logic, and build a REST API to do so. Interestingly, ten years ago, at least half the applicants said they found it interesting because they had never worked with REST or JSON before. A lot were Java developers, so the XML part wasn't a problem, and they would often add some SQL database as a bonus. But 5-10 years later, as development switched to (Node)JS and web, it became the inverse and people said they had never done anything with XML before.
  - usrusr 4y ago
    And far more likely: done before, but never on anything even remotely close to a blank slate. You can spend years doing X, be very good at doing X, but only ever adapt some pre-existing precedent implementation of doing X to a new use case, or to a new underlying library, but never any green-fielding. That "implement X in a vacuum" test will rate many experienced people lower than some who have never ventured beyond textbook examples. It's not impossible that your real tasks have so much green field work in them that those experienced brown-fielders might actually be bad matches, but I suspect that those situations are much less common than the tests that select for green-fielders.

kamranjon 4y ago

I have a different perspective. I feel that specific coding task tells me absolutely nothing about the seniority of the person performing the task and tells me very little about their qualifications.

Mistletoe 4y ago
But shouldn't a blacksmith be able to make a nail before he makes me a suit of armor?
- nordsieck 4y ago
  > But shouldn't a blacksmith be able to make a nail before he makes me a suit of armor? Yes. But I think there's a reasonable upper limit to the amount of time a company can expect someone to spend on a job opportunity. If they're burning an appreciable amount of that time on a trivial coding exercise, that's not great.
  - joe_guy 4y ago
    It's 60 minutes as a very high estimate. You might spend a life time together.
    - bboygravity 4y ago
      55 minutes to install the tool-chain and libs and 5 minutes to do the coding?
      - hackertyper69 4y ago
        give them a machine to ssh into with env setup already. or a docker container to ssh into on a port other than 22
  - caminante 4y ago
    !!! You're missing the point. The premise is that someone capable can blast through trivial assignments in no time. Either this is the final proficiency challenge or there are subsequent, harder questions. In the former case, why not see the salary/offer and then decide?

nindalf 4y ago

No doubt when GP refused to complete the coding assessment the people who designed it thought “aha! Yet another non-coder filtered out by our process!”

caminante 4y ago
Why limit it there? Add "This person doesn't know about my firm's hiring process, aren't willing to do basic tasks, doesn't want to work at my firm," etc.

wildzzz 4y ago

It's a great way to weed out the junior devs that cheated their way through school (or are too dumb to figure it out via stackoverflow) and the senior devs that haven't actually done any real programming in a long time. An engineer at our competitor got laid off and my PM found out and hired the guy to do FPGA work. My PM knew the guy through some contracts we had with the competitor and assumed he was an expert in the field. Turns out the guy was more of middleman between program management and the engineers so while he could talk about the work, he hadn't really done it in like 10 years. My PM got the hiring expedited and since we don't really do interview tests in our industry, the guy was now on our team before anyone could ask any pertinent questions. Long story short, the FPGA team starts assigning him work but it's taking way too long and he's asking for more documentation and for help on things that he definitely would have worked on in his supposed previous job. Eventually we all figure out that he kinda overstated how fresh his skills are and we transition him to a sort of documentation role so he wasn't burning hours on things he just couldn't handle. While he was perfectly capable of doing that kind of work, it involved a lot of insight to our design so it took him a while to get onboarded to the system and able to properly describe the design. Eventually he was doing good work and got the project to the point where he wasn't needed but he left a bad taste in everyone's mouth. We could have hired two junior engineers to do the work he was doing for the same price and probably gotten it done much faster. After the guy transfered over to another project, we reamed out our PM about his hiring decision and begged him to give us some input next time. Of course, due to the waste of money from the last guy, the functional managers stopped taking hiring inputs from our project and would just assign whoever the fuck they thought we needed despite the kind of roles we actually needed.

genewitch 4y ago
I am one of those people who just won't exaggerate or lie on my CV or during an interview. I say "i'm not sure, i'd google it the first couple times it came up". I'm not a programmer though. I have a weird skillset that doesn't mesh or gel with what recruiters are looking for, so on the rare occasion i get a recruiter on the phone, i tend to get a job offer at the end of the sequence. I've had a few startup jobs, a couple megacorp jobs (not Apple), and a handful of mom and pop and defunct business jobs as well. My least favorite interview questions involve regex or deep internals of BSD or Linux, my favorite interview questions are off the cuff solutions to problems presented, and then backtracking the explanation. I've also been asked to perform job interviews for positions that i probably ought know enough about to interview a candidate for, but I went off my gut feeling about how the person acted in what i consider a stressful situation (a slew of interviewers asking asinine questions). I don't like interviewing, i am not very good at finding candidates that are "in for the long haul" but every time we were tasked with finding someone who can do X before end of Q3, my hired candidate recommendations always nailed it in that time frame. All this is to say, i find the whole process ridiculous. My CV apparently looks like a train wreck. I refuse to wear a tie or get a haircut. I'm eerily relaxed in interview situations. My trick? one time i hung out with a CEO of an IT company from the PNW, and they basically told me everything i thought i knew was trash, my resume was trash, my attitude was trash, and the only thing i was good at was solving problems in a hurry. We did, in fact, get coffee for our meetup. I scrapped every idea of what a resume should look like - what i envisioned a perfect professional resume looked like - and started fresh. I learned to say no to most recruiters in a way that made them ask me about different "opportunities" more aligned with my personal ethics and values in the future. I have 4 FPGAs, and i've never done anything with them, because the bitstream is proprietary on all of them. I wouldn't hesitate to tell an interviewer that i am interested in FPGAs and custom ASICs, because i am. I'm also interested in bacteria, but i won't be applying to a bioscience lab anytime soon. I certainly wouldn't say "yeah i can program an FPGA", or C, or do front end development, or any of that. From my reading of these sorts of comments, in aggregate, most people try to impress the interviewers. I want them to impress me. Does this make me privileged? Probably. <sigh>

cratermoon 4y ago

Especially now that the "senior" titled is handed out to people with 3-5 years of experience.

selcuka 4y ago
There was a blog post on HN a few days ago by someone who taught himself programming during covid and landed senior roles (multiple, simultaneously, by lying to the employers).
- FrenchTouch42 4y ago
  Do you have the link?
  - AkshatJ27 4y ago
    https://overemployed.com/ https://overemployed.com/ Not parent, but i think they are talking about this blog
  - selcuka 4y ago
    It was this story, but the actual post is gone: https://news.ycombinator.com/item?id=33739094 https://news.ycombinator.com/item?id=33739094 It's still archived, though: https://web.archive.org/web/20221119032911/https://overemployee.blog/my-overemployment-story/ https://web.archive.org/web/20221119032911/https://overemplo... and https://web.archive.org/web/20221116023708/https://overemployee.blog/how-much-do-i-make-as-an-overemployee/ https://web.archive.org/web/20221116023708/https://overemplo... Key takeaways: > I started learning to code in 2019 as my new years resolution. > Job #1 Senior front end dev > Job #2 Senior front end engineer > Job #3 Front end engineer (mid-level)
sodapopcan 4y ago
Ya, most people who have been in the game for a year ask for "senior" position. I'm pretty sure this is why there is "staff" now. Well, I'm not sure how long "staff" has been a thing as I've never worked at a company that has that title, just interviewed for them (nb: I interviewed for "senior" positions at said companies).

ohdannyboy 4y ago

I'm currently doing interviews for a senior firmware dev position and was stunned by this. Today I talked to a guy who couldn't tell me what an interrupt was in any technical detail. His coding was worse than a first year college students. 5 of the 6 people I've talked to so far bombed the coding portion.

AlotOfReading 4y ago
This isn't intended as a rebuttal, but I've learned to stay away from deeply technical questions in embedded. As long as the interviewee is sufficiently paranoid about C, is recognizably experienced via conversation, and knows the basic concepts I don't press too hard on their specific skillset. There are just too many niches where the knowledge we each consider necessary simply isn't. I had one particularly bad interviewer grill me on how the ARM GIC worked in detail (e.g. interconnect details, differences between versions, etc) because they considered it basic knowledge. I've personally never needed to know anything about it that wasn't in a TRM.
- ohdannyboy 4y ago
  Im pretty new to interviewing so I appreciate the feedback. I think I'm dong OK with respect to that but I'll make sure not to assume my own expertise are trivial.
- greyhair 4y ago
  I agree. Why memorize something that is well documented? Do you understand basic interrupt management and the existence of interrupt controllers? Good. Understanding basic concepts matter, but silicon implementations of a concept? No. One question I have found useful in embedded development is asking someone to discuss the difference between a thread and a process, and the difference between thread based OSs and process based OSs. It is a general question, not bound by anything like CPU architecture, but just gives an idea into whether the person is comfortable about general memory domains. I have mentored people, bright programmers that never worked in small embedded systems, that initially tripped all over the thread model, but eventually came to understand it.

AlfeG 4y ago

And very low ability to do any improvisation. Without specifying every detail of implementation task will not be completed. Even in areas that don't require very specific solutions, and need to just work.

dcow 4y ago

And if you think a suit extends card then you’ve violated LSP.