6 ms·

I looked at the first few Android question lists and the questions were terrible. "What are the four API classes used for sensors?" Are you kidding me?!? I have

I looked at the first few Android question lists and the questions were terrible. "What are the four API classes used for sensors?" Are you kidding me?!? I have over 10 years of experience building Android apps and I have no idea of the answer -- and I've probably used them! Along with the thousand other apps and classes in the framework. If someone asked me that question I'd kindly explain that I'm no trivia master, that's what documentation is for and walk away.

edoceo 8y ago
If you answered like that, I'd ask if you can start tomorrow.
- reificator 8y ago
  Yeah, I don't remember is a perfectly valid answer to a question like that IMO. Especially in any language where you have suggestions in your IDE, just remembering where it is would be fine. "Oh yeah that's in the IO.Sensors namespace" or wherever it is. If there are some incredibly common pitfalls or footguns, those are a better test, especially if you can ask something like what the difference between two methods is. But even that is pushing it. Operators, on the other hand, I think are fair game. If you're doing Javascript you'd better be able to tell the difference between `==` and `===`, even if the answer is "== does magic things that surprise people and I don't remember what they are, so I stick to ===".
- PenguinCoder 8y ago
  You are in the minority. I said something like this, more tactful, in a very recent interview. The question was related to troubleshooting a performance issue on Linux. I answered, with the process and tool I would use and how I thought it would help, what I was looking for etc, high level The interviewer response was along the lines of 'anyone can spout off command names, but what's the flags and parameters, and what do they mean'. I answered I don't know the exact syntax, I'd have to read the man pages or my notes. The interview was cut short and I was removed from consideration. Note, this was not a FANG, was not for SRE or Systems admin type role either. But this was my experience. The majority of interviews want you to repeat trivia bullshit because it makes their job 'easier'.
  - edoceo 8y ago
    I feel like you've dodged a bullet.
    - PenguinCoder 8y ago
      Agreed, but it is still a frustrating experience. Though since this is the experience I have had, I have a i play the game to get a job. I never know if the next interview will ask the same shit but, I expect it at this point and I still hate it.
      - edoceo 8y ago
        From my side (hiring) it's rough too. All candidates seem prepared for this stupid game. Then I'm like, hey, show me some hobby code of some thing you shipped. Let's talk about your bugs, how you ship? Why you pick that stack? Watching a candidate click through their own buggy stuff teaches me so much, so fast about the person. My experience is that candidates are ready for trivia and sample/theory but are not ready to brag about their own cool shit. Talk about how great you are and what you learned, defend your choice, evaluate where to improve. That's what we do every day. we only use the white board for drawing arch-pictures/diagrams, and the occasional dickbutt. In fact, that's my new (and only) whiteboard question.
        PenguinCoder 8y ago
        I have a lot of 'cool stuff' I would love to elaborate on, personal projects and home lab stuff. Though again, in my experience, companies don't want to hear this. They want to see stupid ass 'bubble sort this, merge sort that, fixx buzz without modulus' crap. I can't do that, I don't -want- to do that. I am not a programmer (despite my handle). I can script, I can automate, but I should NOT need to know every damn CS algorithm under the sun for a fucking NON dev, non programmer, role. I'm tired of this interview process. Tech is the only industry I know of, that has multiple interviews of varying nature, including phone, web camera/ doc collab, on site multiple days, etc etc. I once told a non-tech person the type of gauntlet needed to even get an INTERVIEW let alone a JOB in this realm, and their question was aptly "why the hell would you ever put up with that?". Their job interview was: resume -> onsite with manager, hired. I loathe this type of interview bullshit culture, and it more than anything else is driving me out of the industry. Sure I'm not Jon Skeet, but I do my job and I do it well. Continuing with these types of interviews and company shit, makes me want to go be an electrician or mechanic or anything the hell else.
deleted 8y ago
[deleted]
JumpCrisscross 8y ago
When interviewing for senior (read: C-suite) positions, I sometimes try to gauge how someone reacts to dumb questions. Ignoring it is bad. Walking out is bad. Explaining why it’s wrong is good. Trying to get at the intended question is best. Probably not what’s going on here. But human systems require debugging as much as technical ones.
- muse900 8y ago
  Well if thats what you practice on your interviews then you might miss out at some people that might react the way you want them to react and be a good fit. I would personally walk away as well, its not like am some kind of superstar, I just feel that I won't be a good match to a company that asks questions that I feel are not needed. The way I see it an interview is always two ways. The company is interviewing me to see if am a good fit and I am interviewing the company to see if they are a good fit for me since I'll be spending at least 8 hours a day 5 days a week of my time working for that company. Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit.
  - mitchty 8y ago
    > Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit. Bingo. Thats basically our interview process. I could ask stupid technical gotchas but thats idiotic. Better to ask pointed questions like: oh you like to program micros on the side, if you've programmed SPI before tell me what your most fun debug session involving that entailed. These questions tell me more than anything like fizzbuzz can. You dig into details as much/little as you need to based on the replies but I honestly think the people you want shine though with their stories, not their rote knowledge. If someone started spouting off intentionally wrong things in an interview as stated in this comment tree, I would call it a day and say thanks for all the fish, but I'm not starting off having to rebut 2+2=5 for this company. Even if that is a tactic for discussion, lets just have the discussion, as it stands that just makes me not want to work there as now what is the day to day like? Do I have to prove the world isn't flat constantly? Better to not find out and look elsewhere, even the weird cs quizz jobs are better than trying to deal with those kind of dynamics.

edoceo 8y ago

If you answered like that, I'd ask if you can start tomorrow.

reificator 8y ago
Yeah, I don't remember is a perfectly valid answer to a question like that IMO. Especially in any language where you have suggestions in your IDE, just remembering where it is would be fine. "Oh yeah that's in the IO.Sensors namespace" or wherever it is. If there are some incredibly common pitfalls or footguns, those are a better test, especially if you can ask something like what the difference between two methods is. But even that is pushing it. Operators, on the other hand, I think are fair game. If you're doing Javascript you'd better be able to tell the difference between `==` and `===`, even if the answer is "== does magic things that surprise people and I don't remember what they are, so I stick to ===".
PenguinCoder 8y ago
You are in the minority. I said something like this, more tactful, in a very recent interview. The question was related to troubleshooting a performance issue on Linux. I answered, with the process and tool I would use and how I thought it would help, what I was looking for etc, high level The interviewer response was along the lines of 'anyone can spout off command names, but what's the flags and parameters, and what do they mean'. I answered I don't know the exact syntax, I'd have to read the man pages or my notes. The interview was cut short and I was removed from consideration. Note, this was not a FANG, was not for SRE or Systems admin type role either. But this was my experience. The majority of interviews want you to repeat trivia bullshit because it makes their job 'easier'.
- edoceo 8y ago
  I feel like you've dodged a bullet.
  - PenguinCoder 8y ago
    Agreed, but it is still a frustrating experience. Though since this is the experience I have had, I have a i play the game to get a job. I never know if the next interview will ask the same shit but, I expect it at this point and I still hate it.
    - edoceo 8y ago
      From my side (hiring) it's rough too. All candidates seem prepared for this stupid game. Then I'm like, hey, show me some hobby code of some thing you shipped. Let's talk about your bugs, how you ship? Why you pick that stack? Watching a candidate click through their own buggy stuff teaches me so much, so fast about the person. My experience is that candidates are ready for trivia and sample/theory but are not ready to brag about their own cool shit. Talk about how great you are and what you learned, defend your choice, evaluate where to improve. That's what we do every day. we only use the white board for drawing arch-pictures/diagrams, and the occasional dickbutt. In fact, that's my new (and only) whiteboard question.
      - PenguinCoder 8y ago
        I have a lot of 'cool stuff' I would love to elaborate on, personal projects and home lab stuff. Though again, in my experience, companies don't want to hear this. They want to see stupid ass 'bubble sort this, merge sort that, fixx buzz without modulus' crap. I can't do that, I don't -want- to do that. I am not a programmer (despite my handle). I can script, I can automate, but I should NOT need to know every damn CS algorithm under the sun for a fucking NON dev, non programmer, role. I'm tired of this interview process. Tech is the only industry I know of, that has multiple interviews of varying nature, including phone, web camera/ doc collab, on site multiple days, etc etc. I once told a non-tech person the type of gauntlet needed to even get an INTERVIEW let alone a JOB in this realm, and their question was aptly "why the hell would you ever put up with that?". Their job interview was: resume -> onsite with manager, hired. I loathe this type of interview bullshit culture, and it more than anything else is driving me out of the industry. Sure I'm not Jon Skeet, but I do my job and I do it well. Continuing with these types of interviews and company shit, makes me want to go be an electrician or mechanic or anything the hell else.

deleted 8y ago

[deleted]

JumpCrisscross 8y ago

When interviewing for senior (read: C-suite) positions, I sometimes try to gauge how someone reacts to dumb questions. Ignoring it is bad. Walking out is bad. Explaining why it’s wrong is good. Trying to get at the intended question is best. Probably not what’s going on here. But human systems require debugging as much as technical ones.

muse900 8y ago
Well if thats what you practice on your interviews then you might miss out at some people that might react the way you want them to react and be a good fit. I would personally walk away as well, its not like am some kind of superstar, I just feel that I won't be a good match to a company that asks questions that I feel are not needed. The way I see it an interview is always two ways. The company is interviewing me to see if am a good fit and I am interviewing the company to see if they are a good fit for me since I'll be spending at least 8 hours a day 5 days a week of my time working for that company. Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit.
- mitchty 8y ago
  > Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit. Bingo. Thats basically our interview process. I could ask stupid technical gotchas but thats idiotic. Better to ask pointed questions like: oh you like to program micros on the side, if you've programmed SPI before tell me what your most fun debug session involving that entailed. These questions tell me more than anything like fizzbuzz can. You dig into details as much/little as you need to based on the replies but I honestly think the people you want shine though with their stories, not their rote knowledge. If someone started spouting off intentionally wrong things in an interview as stated in this comment tree, I would call it a day and say thanks for all the fish, but I'm not starting off having to rebut 2+2=5 for this company. Even if that is a tactic for discussion, lets just have the discussion, as it stands that just makes me not want to work there as now what is the day to day like? Do I have to prove the world isn't flat constantly? Better to not find out and look elsewhere, even the weird cs quizz jobs are better than trying to deal with those kind of dynamics.