Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

171–180 of 315 posts

Re: People suck at technical interviews (2014)

#171

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.

Are you hiring? I've had a pretty miserable week of interviewing. Either I'm not the right fit or the potential employer is less than ideal.

Re: People suck at technical interviews (2014)

#172
post #127

A 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…

What I do is ask them about previous projects. 1. What was your favorite project and why? Explain. 2. What was your least favorite project and why? Explain.

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…

I think the idea is that the "smart" person will be able to learn what they need to on the job quicker. The person with lower grades may be a better developer but right now of school I think most employees are hiring based on potential and culture fit vs actually development ability.

Re: People suck at technical interviews (2014)

#174
lol I had to do the fizzbuzz test a few weeks ago

the 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)

#175
post #167

Earlier 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?

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)

#176
post #167

Earlier 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?

You don't have to, you can use sqlite for that.

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)

#177

Earlier 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?

I met a professional, working Rails dev who didn't know how to expose a class's instance variables for read access in Ruby. (i.e. write getters)

(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)

#178

There 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%…

I have all that stuff

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)

#179
post #167

Earlier 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.

And sadly you don't even need to create sort indices. Just reading the data into a list of tuples and a few list comprehensions would provide all the querying needed (it wouldn't be efficient but most candidates can't even get that far)

Re: People suck at technical interviews (2014)

#180
post #167

Earlier 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?

> 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.

Post reply on HN