This is all well and good...brings back a lot of memories from undergrad school.
But after enduring such an interview from a company, PLEASE PLEASE PLEASE don't forget to then ask your interviewer how they've used/applied said "algorithms, data structures, design, optimization and honestly just an ever growing basket of subjects" in their CURRENT work.
If you get a blank stare back, you'll know that you were just put through an "interview" that was essentially algorithm hazing and nothing more. I'd seriously question whether or not I'd want to work for this company.
@leesmith That's super good advice. I always shout my guts out to people I chat with that this type of convention or practice that is going on in the soft dev world is so useless but more often than not I get that 'stop cribbing' look back or just some ignorant view point back which makes me think that people are just whizzing through life mindlessly, like they don't actually care. Anyways, I am definitely gonna raise this question in my next interview of how they have used what they are asking me in their work on a day to day basis. It'll be super fun (and maybe a little risky) xd
Exactly! I'm disappointed by how many people accept these whiteboarding rituals as a necessary or unavoidable evil. They aren't. There are plenty of companies out there that offer more sane alternatives that mirror day-to-day work.
100% this! Same with not allowing you to use Google as you attempt to formulate a solution. I assume you would be allowed to use Google day-to-day as you perform your job, right?
I’m a recovering social scientist (BA in Econ) who got a lucky break after college. I’ve been a practicing developer for 25 years in private industry and the public sector.
This x 1000. I interviewed with a Big Name Company once, early in my career, and was asked some question about implementing a AVL tree or some such. I asked the guy ( and it was a guy because they all were at Big Name Company, but that's a diff issue ) if he had ever, in his entire working life at that place, ever implemented an AVL tree, or any other primitive data structure from scratch. When he said "no", I asked why they were asking me how to do it. He said because they always asked that question. I said I'd answer when I had my data structures book handy. I got the gig anyway.
These questions are pointless. I'm a hiring manager now. I never ask interviewees questions about how to implement basic structures or algorithms. If someone is rolling their own now, they need to have a damn good reason for it. However, I will ask questions to tease out if they understand WHEN AND HOW TO USE different algorithms, structures, design patterns, etc, and the tradeoffs associates with those choices. I think that is fair game, and also a better indicator of what kind of software engineer you will be.
If you can code up a quick sort, but I don't ask you that kind of sort to use in a given situation , and then don't find out until after I hire you that you use bubble sorts for everything, me knowing you can code a quick sort is not terribly helpful.
I was asked - what is the data structure that databases usually use to store data. I said B trees or B+ trees (we were discussing indexing, fan-out et.. ). Then he said ok now implement a B tree with all the crud operations. I told him I can explain the logic to you, but I don't think i can code that. Maybe I could, but it would take me a log time to convert the logic into code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is all well and good...brings back a lot of memories from undergrad school.
But after enduring such an interview from a company, PLEASE PLEASE PLEASE don't forget to then ask your interviewer how they've used/applied said "algorithms, data structures, design, optimization and honestly just an ever growing basket of subjects" in their CURRENT work.
If you get a blank stare back, you'll know that you were just put through an "interview" that was essentially algorithm hazing and nothing more. I'd seriously question whether or not I'd want to work for this company.
Seconded!!
@leesmith That's super good advice. I always shout my guts out to people I chat with that this type of convention or practice that is going on in the soft dev world is so useless but more often than not I get that 'stop cribbing' look back or just some ignorant view point back which makes me think that people are just whizzing through life mindlessly, like they don't actually care. Anyways, I am definitely gonna raise this question in my next interview of how they have used what they are asking me in their work on a day to day basis. It'll be super fun (and maybe a little risky) xd
Exactly! I'm disappointed by how many people accept these whiteboarding rituals as a necessary or unavoidable evil. They aren't. There are plenty of companies out there that offer more sane alternatives that mirror day-to-day work.
100% this! Same with not allowing you to use Google as you attempt to formulate a solution. I assume you would be allowed to use Google day-to-day as you perform your job, right?
This x 1000. I interviewed with a Big Name Company once, early in my career, and was asked some question about implementing a AVL tree or some such. I asked the guy ( and it was a guy because they all were at Big Name Company, but that's a diff issue ) if he had ever, in his entire working life at that place, ever implemented an AVL tree, or any other primitive data structure from scratch. When he said "no", I asked why they were asking me how to do it. He said because they always asked that question. I said I'd answer when I had my data structures book handy. I got the gig anyway.
These questions are pointless. I'm a hiring manager now. I never ask interviewees questions about how to implement basic structures or algorithms. If someone is rolling their own now, they need to have a damn good reason for it. However, I will ask questions to tease out if they understand WHEN AND HOW TO USE different algorithms, structures, design patterns, etc, and the tradeoffs associates with those choices. I think that is fair game, and also a better indicator of what kind of software engineer you will be.
If you can code up a quick sort, but I don't ask you that kind of sort to use in a given situation , and then don't find out until after I hire you that you use bubble sorts for everything, me knowing you can code a quick sort is not terribly helpful.
Thirthirded
You were asked for AVL tree? Jesus
I was asked - what is the data structure that databases usually use to store data. I said B trees or B+ trees (we were discussing indexing, fan-out et.. ). Then he said ok now implement a B tree with all the crud operations. I told him I can explain the logic to you, but I don't think i can code that. Maybe I could, but it would take me a log time to convert the logic into code.