5 ms·

Please everyone keep asking for cs fundamentals questions for interviews. I get to keep picking up great devs that get annoyed at all the weird questions. I as

by kaiju0 6y ago

Please everyone keep asking for cs fundamentals questions for interviews. I get to keep picking up great devs that get annoyed at all the weird questions. I ask about how applicants have implemented things and bang around the edges with questions to gauge the depth of their understanding.

snapetom 6y ago
This. I myself flat out told recruiters I don't do whiteboard coding. If the interview requires that, don't bother putting me up. I'm more than happy to answer architecture questions, deep dive on what I've done, look at my github. However, I refuse to stand there and whiteboard algorithms for employers. I'm not good at coding when people stare at me, so I'm not going to. In turn, I don't do that to candidates. Having a technical dialog is great. You can easily sort of the pretenders and get a real good sense if they are a good team player, which ranks almost as highly as technical chops.
- kjeetgill 6y ago
  This is really interesting. If it's not prying too personally, mind sharing where you're at or some example companies? I've interviewed at maybe 15-20 companies over the years and never not had to whiteboard or live code in some way. The thought of not having to seems so foreign to me.
  - snapetom 6y ago
    I feel like whiteboarding has only gotten popular in the last 10 years, maybe less. I've been at six companies in that span, interviewing at probably 12-14 total. Out of the six, four have been tech startups including the one I am in now. The industries have been cybersecurity (x2), online retail, and online marketing. The two non-startups have been in education and healthcare. 2016 was the last time I didn't have the luxury of looking while jobless, but I was still pretty picky. I already knew I didn't like white boarding, so I started to warn recruiters that I wasn't good at it. Two early interviews, I told recruiters this, and they both urged me to go to their interviews anyway. I went ahead thinking it would be good practice. Not surprisingly, I wasn't offered because I just wasn't that interested, and it showed in the interviews. I remember getting a bit curt in one interview because the last person that I interviewed with (going on 4 hours), asked me the same coding question as the first person. After that experience, I became more inflexible on my no-coding interview requirements. It probably was just dumb luck, but this wasn't a problem, I was told. Two more companies after that were at companies that did architecture interviews centered around data platforms, and I eventually took one offer.
    - collyw 6y ago
      Whiteboard has actually become less common in the last ten years in my opinion (20 years in the industry). It's moved towards take home exercises, which are a more realistic gauge of what you are doing, but are just such a time sink. They take a minimum of half a day, and then you are pushing out fairly rushed code, so not the best.
      - anonyxyz 6y ago
        Half day long take home exercise are a huge red flag and disrespectful of the candidates time. Ours takes at most 1 hr.
        collyw 6y ago
        That's very reasonable. Everyone wants a miniature throwaway app, including project setup and test usually. Then you get a problem when one library you wanted to use doesn't install easily, or you have some random problem that takes an hour to debug. Last time I got failed on a number of things many of which weren't asked for. Linting failed on two whitespaces, as I didn't have pylint set up on my home machine. I should have returned json, rather than html, despite the task asking for a 'page, no need for styling'. And I didn't provide a setup.py, despite it not being asked for. I provided the most difficult integration test to implement, but they complained I didn't add more unit tests, even though they has said to describe what tests you would have implemented if you were short on time, which I did.
fourneau 6y ago
This is, and has been forever, my playbook in an interview. It reveals so much about coding ability, and about communication skills. We don't ask people to spell things out if they claim they speak English on their resume, so why bother with the basics? I'll trust that the schools are doing their job.
nicbou 6y ago
On the other hand, there are some common data structures that are essential in day to day software development. Hash maps are one of them. If you're not aware of their performance benefits, it will probably impact the quality of your work. I think it would be fair to test for that with a scenario where a hash map is required, and see what they do. No coding involved, just "what would you do here".
- collyw 6y ago
  The majority of work these days are web apps, and the bottlenecks are usually database query and IO issues. Many can be solved with an appropriate index. If you have a slow Django app, I would guess than 9 out of 10 times it is someone who is letting the ORM produce far too many queries in loops. Hashmaps are never something I have needed to look into personally, but I guess it depends on exactly what you are coding.
  - nicbou 6y ago
    There's quite a bit of data wrangling happening both in the backend and in the frontend.
    - collyw 6y ago
      Rereading your comment, do you mean just using a hashmap / dictionary, or do you mean writing your own hashing functions? The first is invaluable, but I have never had the need for the second (pretty sure you could define your own hashing functions in Perl, but I never found the need).
dnr 6y ago
Have you made any bad hires that way? I used to think that I could gauge someone's depth of understanding by asking pointed questions about past projects, but after doing that several times and following it up with a simple coding problem that they totally flailed around on, or having a colleague tell me that they failed a simple coding problem in their interview, I realized that some people are just very good at faking understanding at that level (talking about code but not actually coding). Especially if it's on their "own" project that they're familiar with and have practiced responses to.
- kaiju0 6y ago
  So far its been pretty solid. My key approach is to ask about the last task they were working on. Then keep asking further questions on it to gauge their depth of understanding. For someone I want to hire there is almost always a "Beautiful Mind" moment. They stop trying to distill information and start just start talking about all the little details they needed to iron out to get it working right. That when I know they actually did the work and are not just a taking credit for being on a project. Why did you choose that over other approaches? Did you use an ORM or raw queries? What was the O(n) on that operation? What kind of database did you access? How did you add that to the CI/CD pipeline? Just flex the questions for whatever and the people that did not do the work fall apart. Then you have solid devs that show up every day and do the work. You also get the bonus of the dev knowing their new boss knows their shit.

by kaiju0 6y ago

snapetom 6y ago

This. I myself flat out told recruiters I don't do whiteboard coding. If the interview requires that, don't bother putting me up. I'm more than happy to answer architecture questions, deep dive on what I've done, look at my github. However, I refuse to stand there and whiteboard algorithms for employers. I'm not good at coding when people stare at me, so I'm not going to. In turn, I don't do that to candidates. Having a technical dialog is great. You can easily sort of the pretenders and get a real good sense if they are a good team player, which ranks almost as highly as technical chops.

kjeetgill 6y ago
This is really interesting. If it's not prying too personally, mind sharing where you're at or some example companies? I've interviewed at maybe 15-20 companies over the years and never not had to whiteboard or live code in some way. The thought of not having to seems so foreign to me.
- snapetom 6y ago
  I feel like whiteboarding has only gotten popular in the last 10 years, maybe less. I've been at six companies in that span, interviewing at probably 12-14 total. Out of the six, four have been tech startups including the one I am in now. The industries have been cybersecurity (x2), online retail, and online marketing. The two non-startups have been in education and healthcare. 2016 was the last time I didn't have the luxury of looking while jobless, but I was still pretty picky. I already knew I didn't like white boarding, so I started to warn recruiters that I wasn't good at it. Two early interviews, I told recruiters this, and they both urged me to go to their interviews anyway. I went ahead thinking it would be good practice. Not surprisingly, I wasn't offered because I just wasn't that interested, and it showed in the interviews. I remember getting a bit curt in one interview because the last person that I interviewed with (going on 4 hours), asked me the same coding question as the first person. After that experience, I became more inflexible on my no-coding interview requirements. It probably was just dumb luck, but this wasn't a problem, I was told. Two more companies after that were at companies that did architecture interviews centered around data platforms, and I eventually took one offer.
  - collyw 6y ago
    Whiteboard has actually become less common in the last ten years in my opinion (20 years in the industry). It's moved towards take home exercises, which are a more realistic gauge of what you are doing, but are just such a time sink. They take a minimum of half a day, and then you are pushing out fairly rushed code, so not the best.
    - anonyxyz 6y ago
      Half day long take home exercise are a huge red flag and disrespectful of the candidates time. Ours takes at most 1 hr.
      - collyw 6y ago
        That's very reasonable. Everyone wants a miniature throwaway app, including project setup and test usually. Then you get a problem when one library you wanted to use doesn't install easily, or you have some random problem that takes an hour to debug. Last time I got failed on a number of things many of which weren't asked for. Linting failed on two whitespaces, as I didn't have pylint set up on my home machine. I should have returned json, rather than html, despite the task asking for a 'page, no need for styling'. And I didn't provide a setup.py, despite it not being asked for. I provided the most difficult integration test to implement, but they complained I didn't add more unit tests, even though they has said to describe what tests you would have implemented if you were short on time, which I did.

fourneau 6y ago

This is, and has been forever, my playbook in an interview. It reveals so much about coding ability, and about communication skills. We don't ask people to spell things out if they claim they speak English on their resume, so why bother with the basics? I'll trust that the schools are doing their job.

nicbou 6y ago

On the other hand, there are some common data structures that are essential in day to day software development. Hash maps are one of them. If you're not aware of their performance benefits, it will probably impact the quality of your work. I think it would be fair to test for that with a scenario where a hash map is required, and see what they do. No coding involved, just "what would you do here".

collyw 6y ago
The majority of work these days are web apps, and the bottlenecks are usually database query and IO issues. Many can be solved with an appropriate index. If you have a slow Django app, I would guess than 9 out of 10 times it is someone who is letting the ORM produce far too many queries in loops. Hashmaps are never something I have needed to look into personally, but I guess it depends on exactly what you are coding.
- nicbou 6y ago
  There's quite a bit of data wrangling happening both in the backend and in the frontend.
  - collyw 6y ago
    Rereading your comment, do you mean just using a hashmap / dictionary, or do you mean writing your own hashing functions? The first is invaluable, but I have never had the need for the second (pretty sure you could define your own hashing functions in Perl, but I never found the need).

dnr 6y ago

Have you made any bad hires that way? I used to think that I could gauge someone's depth of understanding by asking pointed questions about past projects, but after doing that several times and following it up with a simple coding problem that they totally flailed around on, or having a colleague tell me that they failed a simple coding problem in their interview, I realized that some people are just very good at faking understanding at that level (talking about code but not actually coding). Especially if it's on their "own" project that they're familiar with and have practiced responses to.

kaiju0 6y ago
So far its been pretty solid. My key approach is to ask about the last task they were working on. Then keep asking further questions on it to gauge their depth of understanding. For someone I want to hire there is almost always a "Beautiful Mind" moment. They stop trying to distill information and start just start talking about all the little details they needed to iron out to get it working right. That when I know they actually did the work and are not just a taking credit for being on a project. Why did you choose that over other approaches? Did you use an ORM or raw queries? What was the O(n) on that operation? What kind of database did you access? How did you add that to the CI/CD pipeline? Just flex the questions for whatever and the people that did not do the work fall apart. Then you have solid devs that show up every day and do the work. You also get the bonus of the dev knowing their new boss knows their shit.