When I interview, I try to find out what the person is good at. Everyone who comes to interview is good at something (even if it's just good at getting interviews). Sometimes their skill-set overlaps with what we need, sometimes it doesn't. But the focus is figuring out what they are good at, rather than an abstract test.
People suck at technical interviews (2014)
171–180 of 315 posts
Re: People suck at technical interviews (2014)
#172A lot of people are saying that technical interviews are not good because some people are not good at them but they are indeed good software developers. Other people are saying that is impossible to judge someone in a few hours of technical interviews/exercises. I agree with both, but what's a better alternative? How to you minimise the risk of taking hiring a bad developer? At least, it is my belief that the technic…
I can get a good idea of the person through those two simple questions. I throw a few simple technical questions like: What is a primary key? What is a foreign key? What is inheritance? What's the difference between a function and a procedure (Delphi days). Questions that anyone should be able to answer just by writing code.
Re: People suck at technical interviews (2014)
#173> Don't hire for a fancy degree. There are some companied coming to my college for hiring. The first criteria they put was 70% aggregate marks (60% for some companies). I have seen people who doesn’t know how to write even a small program getting hired, while people with good programming skills are not even eligible to attend the interview. Going through 200-300 candidates in an interview might be a tedious job, I am…
Re: People suck at technical interviews (2014)
#174the modulo operator was obvious to me and after the interviewer kept adding conditions to the problem, they then asked me why I didn't concatenate strings instead of my approach of returning the string in each conditional statement
so fellow engineers, without having the telepathic skills I possessed that allowed me to know exactly what traits the interviewers were looking for, would you have:
a) erased your entire correct solution to write a more efficient solution, not knowing the time constraints for this problem
b) created the most efficient and scalable fizzbuzz solution known to man at the beginning? in the 15 minutes provided
c) laughed in the interviewer's faces since it was obvious the question was irrelevant to how you would solve problems for the company on a day to day basis?
d) other
Re: People suck at technical interviews (2014)
#175Earlier quoted context omitted.
At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to: - read that file in - store it in some sort of data structure - allow users to run commands to retrieve movie titles based on name, release year, etc. Command-line was totally fine, you had access to the Internet, and as much time as you…
How would you do this without basically writing your own database from scratch?
So it's just a matter of parsing the CSV into some native data structure in your favorite language and then computing sort indices of the columns by which rows might be queried.
Re: People suck at technical interviews (2014)
#176Earlier quoted context omitted.
At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to: - read that file in - store it in some sort of data structure - allow users to run commands to retrieve movie titles based on name, release year, etc. Command-line was totally fine, you had access to the Internet, and as much time as you…
How would you do this without basically writing your own database from scratch?
For example in python: 1. Load the CSV file using the csv lib in a list of dictionary 2. Fill a sqlite database with the list 3. Read wathever the user asked for (ex: movies longer than 100 minutes and release date before 1999) and build a SQL query 4. Display results
Re: People suck at technical interviews (2014)
#177Earlier quoted context omitted.
Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying. The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, don…
5 years of SQL experience and no idea of what a join is? Isn't that like saying 5 years of C/Java/C#/... experience and not knowing what assignment is?
(Not an interview context though; it was a hack night where I was learning ruby and didn't know the right terms to use to look up that question from the docs.)
Re: People suck at technical interviews (2014)
#178There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture,…
Except that the vast majority of programmers essentially say "I'm very good at taking pictures, but I can't actually show you any of them because they're all property of my previous employers, and I never take pictures just for myself". > I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously. 100%…
No problem getting interviews
Still have to do the "brainteaser of the hour" technical interviews. Fortunately it is often the same question I realize, so this gets easier without needing to go through the whole book on this.
Re: People suck at technical interviews (2014)
#179Earlier quoted context omitted.
How would you do this without basically writing your own database from scratch?
By implementing only that 1% of a real database's functionality that this task requires. Consider: you have only one table, no updates or deletes or transactions, fixed schema, and very, very simple queries. So it's just a matter of parsing the CSV into some native data structure in your favorite language and then computing sort indices of the columns by which rows might be queried.
Re: People suck at technical interviews (2014)
#180Earlier quoted context omitted.
At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to: - read that file in - store it in some sort of data structure - allow users to run commands to retrieve movie titles based on name, release year, etc. Command-line was totally fine, you had access to the Internet, and as much time as you…
How would you do this without basically writing your own database from scratch?
It obviously is, for a suitable loose use of the term, "writing your own database from scratch" (unless you are using an existing library, for which many languages have ones that can be leveraged in the stdlib, including often ones that bring in SQLite). But doing a database of this extremely minimal complexity, or leveraging existing libraries to provide the functionality, is a pretty basic task that anyone expecting to get employed to do software development should be able to do with the conditions described.