It is certainly very good practice to match data types, but that is not the only way to obtain a seek here (assuming the default collation is a Windows one like Latin1_General_CI_AS rather than a SQL one like SQL_Latin1_General_CP1_CI_AS):

CREATE PROC QOD_Performance_1

@Get NVARCHAR(20)

AS

SELECT ID,Col

FROM FirstTable WITH (FORCESEEK)

WHERE Col = @Get;

GO

EXECUTE dbo.QOD_Performance_1

@Get = N'XYZ'

Wondering how this works, or what the Constant Scan and Compute Scalar are for? I wrote about the hard work put in by the optimizer with these sorts of data type mismatches here:

http://sqlblog.com/blogs/paul_white/archive/2012/01/18/dynamic-seeks-and-hidden-implicit-conversions.aspx