4 ms·

For my current job I got grilled with leetcode style questions. Lucky I'd done a few before so knew the tricks. Now I work there the job is basic crud style wor

by rr808 3y ago

For my current job I got grilled with leetcode style questions. Lucky I'd done a few before so knew the tricks. Now I work there the job is basic crud style work, nothing fancy required. Employer also hires grads almost exclusively from Ivy League universities and they mostly suck. Makes me look good. :)

mewpmewp2 3y ago
I think most work is CRUD related, and I also think that it's actually counter productive to hire leetcode or university crowd for these jobs, as they will naturally try to treat CRUD problems as the problems they have been studying and practising, which would mostly yield something that could be done in a few lines of code as something that is really over engineered. They will start trying to figure out problems that have been solved already for them with countless of libraries and tools, because that's what they have been learning. Either following certain design principles, and over engineering, causing massive amounts of boilerplate code, or spending way too much time on trying to consider and optimise for certain types of edge cases, which libraries would handle for them anyway.
- specialist 3y ago
  Yes and: CRUD (and ETL) is just data processing. Find something, copy some strings, munge, paste some strings. ADTs, IDLs, validation goo, logging, tests, etc can help. But also can get in the way. Sometimes, if we're really lucky, we get to mix in some indexes, caching, parsing, undo/redo, and release notes.
deleted 3y ago
[deleted]
logicalmonster 3y ago
> For my current job I got grilled with leetcode style questions. I don't mind being asked a leetcode style question or two in an interview. Even if somebody struggles with solving an unfamiliar problem off the cuff, you can see if they they take some logical problem solving approaches. But it's frustrating that no practical web-development questions are ever asked for those kinds of jobs. For instance, security is really important to the survival of any company. An insecure system that has a data leak could literally destroy a company overnight. Having a secure system is far more important than knowing a more efficient algorithm for sorting some data or whatever. But I've never been asked 1 practical question about security in a technical job interview. It's so painfully stupid it hurts.
- eterm 3y ago
  > a data leak could literally destroy a company overnight Source? I'm sure we "wish" that were true, but data leaks haven't even destroyed companies whose entire existence is predicated on storing data such as Equifax.
  - francoisdevlin 3y ago
    A data point - the capital one AWS breach ended up costing $270M[1]. While they weren't destroyed, it wasn't cheap either. 1. https://techmonitor.ai/technology/cybersecurity/capital-one-hack-aws-paige-thompson https://techmonitor.ai/technology/cybersecurity/capital-one-...
    - izacus 3y ago
      That is peanuts for AWS. The OPs point stands: pretty much no engineer or software company suffered serious consequences over their security practices. The worst was some internet drama and slightly lower *profit*.
      - nemo 3y ago
        Ashley Madison tanked from a data break, and there's an ever growing list of cryptocurrency exchanges that were hacked and ended. It may be that for some businesses a data breach is manageable, but that's not always the case, though more importantly that kind of attitude towards the seriousness of data breaches and vulnerabilities is not wise.
      - sokoloff 3y ago
        It’s CapitalOne, not AWS, who had the flaw and suffered the loss. (And survived it, as is the main point of the thread.)
    - commandersaki 3y ago
      probably a fraction of a percent of their net worth
  - 3y ago
whywhywhydude 3y ago
Writing correct distributed CRUD is hard. I have interviewed quite a few people who didn’t have a clue about how to insert into a table without creating data races.
hahamrfunnyguy 3y ago
I did recruiting for Full Stack developers for a number of years. I only gave two programming problems, one to be completed before an initial phone screen and one to be completed in the first part of the interview. Myself and another team member worked on the questions, and we gave them to the team. Everyone was able to complete the exercises in a reasonable period of time, so we knew they weren't going to be too challenging. Pre-screen question: For the numbers 1 to 99, print the number if its digits do not add up to ten. Otherwise, print the number and its digits 91 (9,1) if it adds up to ten. Download the file quiz.txt and use it a starting point for your program, keep it simple and make sure your output matches sampleoutput.txt exactly. When you've completed it, rename it to yourname.txt and email it to quiz@company.com with the subject of "Your Name: Completed Exercise". A lot of people would just use convert the strings to numbers and then do the test to see if it adds up to ten, in this case I would kick it back to them and ask it to be solved mathematically. Usually, we'd get a response back right away with the "best" solution. Candidates that completed the exercise correctly and followed the directions got 15 minute phone screen to see if they had the technical background required. For the in-person (or Zoom) interview question, we had a problem that required modifying HTML, CSS and JavaScript to come up with a solution. We stated this up front, and tell the candidates to use web resources to look up anything they need to. It also requires using modulus which they should already know (or figured out how to use!) in the screener exercise. If someone got stuck on something we felt they probably knew we'd give them some hints and they'd relax a bit. Most people solved it within 5-15 minutes, but there have been people that couldn't do it at all event with lots of hints. In that case, we'd usually just end the interview and thank the candidate for their time. From here we'd do some database exercises if their role called for database, and move onto an deeper assessment of technical background. That process worked well, and they're still following it today.
- harshalizee 3y ago
  Looks like I'd fail your pre-screen test. What's the "mathematical" solution if you're not allowed to convert strings to ints? Ascii math?
  - m3047 3y ago
ProZsolt 3y ago
The funny thing I joined a company where we building a database from the ground up. Regularly implementing algorithms and data structures from white papers. So it is as far from the crud style work as possible. The interview was just talking to different engineers about interesting problems, like you would do at a conference or at a meetup. No leetcode, no whiteboard, no take home or resembling a technical interview. But somehow they managed to build a top notch team, one of the best I ever worked with.

by rr808 3y ago

mewpmewp2 3y ago

I think most work is CRUD related, and I also think that it's actually counter productive to hire leetcode or university crowd for these jobs, as they will naturally try to treat CRUD problems as the problems they have been studying and practising, which would mostly yield something that could be done in a few lines of code as something that is really over engineered. They will start trying to figure out problems that have been solved already for them with countless of libraries and tools, because that's what they have been learning. Either following certain design principles, and over engineering, causing massive amounts of boilerplate code, or spending way too much time on trying to consider and optimise for certain types of edge cases, which libraries would handle for them anyway.

specialist 3y ago
Yes and: CRUD (and ETL) is just data processing. Find something, copy some strings, munge, paste some strings. ADTs, IDLs, validation goo, logging, tests, etc can help. But also can get in the way. Sometimes, if we're really lucky, we get to mix in some indexes, caching, parsing, undo/redo, and release notes.

deleted 3y ago

[deleted]

logicalmonster 3y ago

> For my current job I got grilled with leetcode style questions. I don't mind being asked a leetcode style question or two in an interview. Even if somebody struggles with solving an unfamiliar problem off the cuff, you can see if they they take some logical problem solving approaches. But it's frustrating that no practical web-development questions are ever asked for those kinds of jobs. For instance, security is really important to the survival of any company. An insecure system that has a data leak could literally destroy a company overnight. Having a secure system is far more important than knowing a more efficient algorithm for sorting some data or whatever. But I've never been asked 1 practical question about security in a technical job interview. It's so painfully stupid it hurts.

eterm 3y ago
> a data leak could literally destroy a company overnight Source? I'm sure we "wish" that were true, but data leaks haven't even destroyed companies whose entire existence is predicated on storing data such as Equifax.
- francoisdevlin 3y ago
  A data point - the capital one AWS breach ended up costing $270M[1]. While they weren't destroyed, it wasn't cheap either. 1. https://techmonitor.ai/technology/cybersecurity/capital-one-hack-aws-paige-thompson https://techmonitor.ai/technology/cybersecurity/capital-one-...
  - izacus 3y ago
    That is peanuts for AWS. The OPs point stands: pretty much no engineer or software company suffered serious consequences over their security practices. The worst was some internet drama and slightly lower *profit*.
    - nemo 3y ago
      Ashley Madison tanked from a data break, and there's an ever growing list of cryptocurrency exchanges that were hacked and ended. It may be that for some businesses a data breach is manageable, but that's not always the case, though more importantly that kind of attitude towards the seriousness of data breaches and vulnerabilities is not wise.
    - sokoloff 3y ago
      It’s CapitalOne, not AWS, who had the flaw and suffered the loss. (And survived it, as is the main point of the thread.)
  - commandersaki 3y ago
    probably a fraction of a percent of their net worth
- 3y ago

whywhywhydude 3y ago

Writing correct distributed CRUD is hard. I have interviewed quite a few people who didn’t have a clue about how to insert into a table without creating data races.

hahamrfunnyguy 3y ago

I did recruiting for Full Stack developers for a number of years. I only gave two programming problems, one to be completed before an initial phone screen and one to be completed in the first part of the interview. Myself and another team member worked on the questions, and we gave them to the team. Everyone was able to complete the exercises in a reasonable period of time, so we knew they weren't going to be too challenging. Pre-screen question: For the numbers 1 to 99, print the number if its digits do not add up to ten. Otherwise, print the number and its digits 91 (9,1) if it adds up to ten. Download the file quiz.txt and use it a starting point for your program, keep it simple and make sure your output matches sampleoutput.txt exactly. When you've completed it, rename it to yourname.txt and email it to quiz@company.com with the subject of "Your Name: Completed Exercise". A lot of people would just use convert the strings to numbers and then do the test to see if it adds up to ten, in this case I would kick it back to them and ask it to be solved mathematically. Usually, we'd get a response back right away with the "best" solution. Candidates that completed the exercise correctly and followed the directions got 15 minute phone screen to see if they had the technical background required. For the in-person (or Zoom) interview question, we had a problem that required modifying HTML, CSS and JavaScript to come up with a solution. We stated this up front, and tell the candidates to use web resources to look up anything they need to. It also requires using modulus which they should already know (or figured out how to use!) in the screener exercise. If someone got stuck on something we felt they probably knew we'd give them some hints and they'd relax a bit. Most people solved it within 5-15 minutes, but there have been people that couldn't do it at all event with lots of hints. In that case, we'd usually just end the interview and thank the candidate for their time. From here we'd do some database exercises if their role called for database, and move onto an deeper assessment of technical background. That process worked well, and they're still following it today.

harshalizee 3y ago
Looks like I'd fail your pre-screen test. What's the "mathematical" solution if you're not allowed to convert strings to ints? Ascii math?
- m3047 3y ago

ProZsolt 3y ago

The funny thing I joined a company where we building a database from the ground up. Regularly implementing algorithms and data structures from white papers. So it is as far from the crud style work as possible. The interview was just talking to different engineers about interesting problems, like you would do at a conference or at a meetup. No leetcode, no whiteboard, no take home or resembling a technical interview. But somehow they managed to build a top notch team, one of the best I ever worked with.